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
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
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,
Hi.
About the documentation - at least ring-swagger[1] doesn't force you to use
Schema as the runtime validation library, it just expects the route (and
parameter) definitions to be presented to it as Schemas. So, you could
validate the routes using bouncer and extract the ring-swagger schemas
On Wednesday, June 24, 2015 at 4:03:39 PM UTC-4, Mike Grabowski wrote:
Thanks for the reference, I've seen it before and it looks interesting,
especially thanks to the failover built-in. It also greatly shows how
Clojure can reduce the `Java boilerplate`.
Speaking on the performance note,
On Wednesday, June 24, 2015 at 6:37:14 PM UTC-4, raould wrote:
350ms sounds fast enough for a low-frequency user interaction. In fact,
once
login is fast enough not to annoy your users, you don't *want* any more
speed from it, as further speedup then only benefits blackhats trying to
That would apply to common actions like typing and entering. Login being
slower than that isn't likely to be as much of a bother as you likely only
do it infrequently, maybe as much as once a day if you're paranoid and clear
cookies nightly.
Yeah, to me that is the sort of reasoning that
350ms sounds fast enough for a low-frequency user interaction. In fact, once
login is fast enough not to annoy your users, you don't *want* any more
speed from it, as further speedup then only benefits blackhats trying to
brute-force one of your users' accounts. So, it might be a feature, not
Mike,
I think you might be better off keeping as much as you can the same between
the two test scenarios so that you are only comparing the differences
between nodejs and clojure -- and not all kinds of other variables like
co-located services/cpu-load on your various hosts, network latency
On Tuesday, June 23, 2015, Mike Grabowski wrote:
... 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
Thanks for the reference, I've seen it before and it looks interesting,
especially thanks to the failover built-in. It also greatly shows how
Clojure can reduce the `Java boilerplate`.
Speaking on the performance note, I am not entirely sure what's causing my
REST API to be slower than
On Tue, Jun 23, 2015 at 11:19 AM, Mike Grabowski grab...@gmail.com 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
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
13 matches
Mail list logo
