Would you recommend using this library in production?

[ncthbrt]

Hi there. I'm building a library called nact. The design goal behind it is to make actor systems and the abstractions one can build atop them more accessible to JavaScript developers.

With this goal, I decided to start out by iterating on user facing APIs rather than immediately working on clustering, service discovery and other more technical aspects of distributed actor systems.

While it is a tiny data point, my team was able to grasp the concept of how actor systems work far more easily than I've experienced with other teams when introducing Akka.Net. I'm sure there is a lot of ways to increase usability and reduce boilerplate, but I feel the project is now at a stage where I want to start looking at ways to enable cluster sharding and service discovery.

Would you say clsuterluck is robust enough for production use? I would love to use something like this in nact.

[aembke]

Hi @ncthbrt, that's very interesting and we'll definitely be following along with that library.

To answer your question: yes I think this is production ready. We've been using it in production for about 6-8 months on an application that uses it for sharding stateful network connections across a cluster, and it's worked well so far. Granted, that application doesn't see a ton of traffic yet, but on our deployments of 3-6 nodes it hasn't shown any problems.

That being said, before using anything in production it's best to know what its problems are, and this is still JavaScript and the library does have its limitations and caveats. For good measure I'll list out some of those now, that way if you do hit any of these hopefully this list will help.

• All ring additions are eventually consistent (from gossip protocol). No transactions exist for these changes yet, so if there's a long lasting network partition between two large enough sectors of the cluster, two different ideas about the ring will persist for the entirety of that partition; this can lead to strange behavior if doing large volume stateful storage that requires high consistency (even high quorum) or low replication factor.
• Changes are LWW for gossip server; if 'insert A' is issued on B and 'insert C' is issued on D without D knowing about insertion on B, whichever command was issued last will resolve the inevitable vector clock conflict.
• The only way to do transitive changes of ring is through 'meet' command (listed in documentation, but good to keep in mind).
• Transfer protocol is JSON, not binary (due to use of node-ipc), so any serialization outside of JSON needs to go to strings and will be deserialized from that format into JSON (since it's javascript). On that note, if you see performance issues it's most likely that a JSON.parse or JSON.stringify is the culprit.
• Native dependencies; if any native module fails to build on an architecture then the library won't work. See the docs for which versions of gcc/clang have been tested.
• Vector clock conflict resolution strategy (outside of gossip server) is left to the user of the library. An LWW function is included by default on the gossip server, but could move to utils for more accessible use if anybody needs it.
• No promise support for asynchronous actor calls (open for PRs though), which would open up use of async/await syntax.
• No supervision trees (this isn't Erlang), so error/exception handling is a whole ball of wax and is left to the user.

[ncthbrt]

Thanks for the detailed answer, @aembke. None of the caveats seem like huge deal breakers. I think I'll create a prototype implementation when space on our road-map opens up.

Hope this isn't too much to ask, but wouldn't mind a review when that happens; you know your lib the best after all. :)

[aembke]

Yeah absolutely, feel free to ping myself or @kevinwilson541 whenever you'd like.