What's the best option similar to Vert.x, Reactor, Nodejs for use with Clojure?

[adrians]

It used to be that Vert.x 2.x had integration for Clojure, but version 3.x hasn't added it yet. Has anyone used this version through the Java API and if so, how painful was it? Is Reactor any better in that respect? What are people using when they want this kind of back end?

[Timothy Baldridge]

I've done some evaluations of Vert.x in the past and was rather underwhelmed. What is it that you are trying to accomplish? Stuff like Pedestal offers async web services, but without the complexity of an traditional evented server. So perhaps if we had a better idea of your requirements we could be a bit more helpful.

So I'd say, look into Pedestal and then define what you need that it cannot do. Same for other toolkits like ring and httpkit. 

Timothy

On Sun, Jan 3, 2016 at 12:59 PM, adrians <nma...@gmail.com> wrote:

It used to be that Vert.x 2.x had integration for Clojure, but version 3.x hasn't added it yet. Has anyone used this version through the Java API and if so, how painful was it? Is Reactor any better in that respect? What are people using when they want this kind of back end?

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[kovas boguta]

I would also look at https://github.com/ztellman/aleph and https://github.com/ztellman/manifold, but like Timothy says its hard to judge without more details. 

[Andrey Antukh]

Also, you can take a look to https://github.com/funcool/catacumba

Andrey Antukh - Андрей Антух - <ni...@niwi.nz>

http://www.niwi.nz

https://github.com/niwinz

[René Groß]

Maybe https://github.com/ptaoussanis/sente could be of interest for you.

Client library is included, which runs on websockets (if available), otherwise it will fallback to ajax.

[qsys]

Depends on what you want... what I really like is the easy modularity: deploy new 'verticles' somewhere in your network, and they're just all connected through a the eventbus. I make a 'new' module, I put it somewhere and it's automatically picked up by the appication and I can communicate with it using that event bus. Is there something similar in clojure, or can I achieve something similar in clojure? I checked
- catacumba: web toolkit, not what I'm after
- sente: is about the web
- aleph: comes closer: does have tcp-servers, but no autodiscovery, and well, no 'event bus' (a kind of wrapper around netty etc).
- manifold: I don't really see the added value, having core.async - but I may fail to see something important here
- pomegranate: is possibly very interesting in adding new modules... not for removing 'old versions' of a module.
- pedestal: have to have a deeper look into it, but so far, I have a feeling it's more about web than 'intra-program' communication

So, so far, I don't see how to implement something like the vert.x event bus, with autodiscovery, in clojure (although I would love to see something like it), expanding to the browser. I don't mind (and prefer) composing it using different libraries, but I feel to see how to have this functionality in clojure (now, I wrap the vertx eventbus in my clojure programs), and since I already load vertx for the eventbus, I use it as web server as well, if I need one... So well, if someone has an idea, it might be a nice project I'd love to work on :).

thx, qsys

Op zondag 3 januari 2016 22:25:04 UTC+1 schreef tbc++:

[Andrey Antukh]

The eventbus of vert.x as far as I know is implemented on top of hazelcast[1] that you already can use from clojure. 

Make a eventbus like concept on top of hazelcast is pretty easy and it already gives you the autodiscovery and all the "clustering" stuff for free.

[1]; http://hazelcast.org/use-cases/messaging/

Andrey

[Mark Mandel]

+1 to what Andrey said.

You could also run Redis as a backend and use it's pubsub service [1], if being more language agnostic is more your thing.

Depending on where you are hosting, you could also use a hosted pubsub mechanism, such as Google Cloud PubSub[2] or AWS SNS[3].

There are definitely lots of ways to solve this particular problem outside of vert.x

[1]: http://redis.io/topics/pubsub

[2]: https://cloud.google.com/pubsub/docs

[3]: https://aws.amazon.com/sns/faqs/

E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast

http://www.2ddu.com/

[qsys]

True, hazelcast, or JGroups, in vertx 3 for clustering/autodiscovery. It may be 'easy' to implement, but it has been quite nicely wrapped, together with netty messaging (not only pub-sub) in vert.x, having connectors to 'pure TCP', websockets etc. I have been thinking of doing something similar in clojure, but never got to it...
Anyway, I'd love to see some kind of 'runtime modularity', on one machine or even one JVM would do as a start (no autodiscovery/clustering necessary).  That's the thing that makes vertx, to me, useful. I'm pretty sure it's possible with the existing clojure libraries etc, but I don't see it yet. That's another thread, though.

thx, qsys


Op zaterdag 23 januari 2016 17:21:03 UTC+1 schreef Andrey Antukh:

[Timur]

Yes +1 to qsys, such a library would be quite useful and enable using Clojure in additional enterprise settings.

Regards,

Timur

[Fabio T.]

Hi,

I agree it really depends what you're looking for. If you're especially looking for async performance then I think you can't go wrong with Pulsar which is a Clojure language integration module + a thin, idiomatic wrapper around Quasar (which supports Java and Kotlin for now, in future any JVM language). Quasar/Pulsar give you fibers (so no need for async APIs and related complications), Go-like channels, Erlang-like actors and dataflow. You can also mix threads and fibers freely (there's an integration of java.util.concurrent as well, should you be interested).

With Pulsar you can have automatic instrumentation and there are some useful Clojure/Pulsar-specific integrations in Comsat already, like a jetty-fiber ring adapter and a fiber HTTP client based on httpkit. There's also a full-blown core.async implentation based on fibers, so you don't need to use "go" block to have async-like performance.

vert.x itself now has an integration with Quasar called vertx-sync but for the moment is Java-only.

-- Fabio

[qsys]

Now, Pulsar looks something more like it: messaging, clustering between machines. It even feels a bit like what vertx is doing, at first glance. Having a kind of 'inter-machine core.async channels' is awesome. This can easily replace the 'vertx eventbus'. Really cool!

Thanks a lot, Fabio!
qsys

Op maandag 25 januari 2016 14:12:42 UTC+1 schreef Fabio T.:

[Fabio T.]

My pleasure!

Please consider that the Galaxy memory grid project, which provides integration out-of-the-box with Quasar/Pulsar actors for networking, distribution and even migration (but is not by any means the only possible one), is not considered production-ready yet at this stage even though a lot of work is going into it at present for it to become so. On the other hand Quasar/Pulsar are production-ready instead and are used by e.g. Pinterest and BrainTree.

Notice: I'm part of the Parallel Universe team.

-- Fabio

[Zach Tellman]

This is incidental to the topic of the thread, but to address why Manifold exists when there's already core.async, there's a write-up of the rationale linked in the readme: http://aleph.io/manifold/rationale.html.