yada exploits aleph's async model of returning futures and leverages manifold's ability to chain together futures and promises. This means you can effectively use a Java synchronous API by wrapping it in a future, or exploit an asynchronous Java API by returning a promise which is delivered in the callback. This programming model will give you a lot of options on the JVM.
I'm sorry that yada is still in alpha, but I've been working hard on it recently and taking on the feedback of a number of early adopters. I hope to get to beta in a matter of weeks. HTTP is a big feature set and rushing things will lead to migration churn later on. On Thursday, 25 June 2015 21:20:05 UTC+1, Mike Grabowski wrote: > > Yeah, looks interesting, but unfortunately still in alpha, so I can't > profit from it at this stage. But will check later! > > Thank you all for your responses! It's been really great source of new > ideas and thoughts about API benchmarking and blocking/non-blocking > approaches :) > > On Thursday, 25 June 2015 16:45:45 UTC+2, Dylan Butman wrote: >> >> Have you looked at yada http://yada.juxt.pro/user-guide.html ? >> >> It's an aleph compatible alternative to liberator that is swagger >> compatible with swagger out of the box. >> >> On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote: >>> >>> Hey guys, >>> >>> I am so excited to join Clojure bandwagon, last weeks have been super >>> exciting, pretty much in love with Clojure syntax. As we are currently >>> building an application broken into smaller micro services, I thought I am >>> gonna make one or two Clojure based modules. Although the initial purpose >>> of picking the language was to do some CPU demand calculations and data >>> processing, I found it really simple yet enjoyable to write REST api as >>> well (we also use Node.js and Elixir for that purpose and it works pretty >>> well - especially with Elixir thanks to awesome yet simple Erlang model >>> where you can `spawn&block` and be happy). >>> >>> I've seen lots of benchmarks already featuring Aleph, Jetty, Vert.x and >>> other HTTP servers and I am currently with `Aleph` thanks to its ability to >>> handle channels and futures out of the box. Unfortunately, because I spent >>> so many years with Node.js and stopped using Java ages ago, I just can't >>> stop thinking about non-blocking evented IO interactions. It just does not >>> feel right to me to block the thread when e.g. logging in an user. >>> Unfortunately, there are no NIO drivers for the database engines I am >>> interested in (Neo4J, Mongo) so async channels are not the way to go. >>> >>> Any advices or interesting thoughts? Maybe I am missing something as I >>> am not entirely sure if evented IO is always speeding up the overall >>> performance. Any performance optimisations are welcome. I am especially >>> unhappy with one Neo4J request that takes 1.5 second to finish (it's only >>> because the database is hosted on free Heroku plan and this is not going to >>> happen in production but I find it quite a good place to tweak the >>> optimisations and concurrency). >>> >>> Another question is - is there any documentation generator that can >>> parse your comments, take keywords like `:params` or `:returns` (just the >>> idea) and generate beautiful API docs out of the box? Swagger is not a way >>> to go as it requires me to use `Schema` plugin - I am currently with >>> `bouncer` thanks to more real-life validators as well as user friendly >>> messages that I can just print to users out of the box (maybe it's worth >>> building as an open source module then) >>> >>> Thanks >>> >>> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
