specs VS Moleculer

The question arises from seeing a plethora of projects using ECS: hecs , Bevy , specs, legion

Instead, I'm using now the specs Library. It's a pure ECS library and much less powerful, without any visualization capabilities, but its works for me :)

writing an ECS is defined a challenging project, no matter the language or if you're a beginner. although it is entirely possible to write one in Rust, check out specs and bevy_ecs for examples.

specs

The official 3d rendering client uses a custom engine called Voxygen. They use Specs for logic.

Rust has a delightful ECS library, specs, that I absolutely love. It has safe multi-threaded execution built right in, which is fantastic for the pretty parallelizable work I was doing. Concurrency in C++ is nasty business on the best of days, and I've run into so many nasty bugs with the custom system I've had to build out to fit the web's weird threading model.

Man, this Specs [0] library is so strange to me, coming from a Unity background. Is there some sort of comparison as to why one way is better than the other?

[0] https://specs.amethyst.rs/

Hi everyone - I just picked up one of my long-unfinished side project built with Rust and would like to show it to you here. It's a clone of the famous(?) Winterbells game. It's written entirely in Rust and uses OpenGL and an entity-component-system architecture ([the `specs` crate](https://crates.io/crates/specs)) (still learning), no game engine.

Wait did the person at your company write specs or something else because they weren't pleased with it? I don't know much about amethyst and vaguely know about entity component systems but I watched a talk on someone making a game with amethyst and was pretty impressed -- it looked thoroughly approachable and I do not doubt the performance is there (since the whole reason you do ECS is performance).

My goto for this kind of task is moleculer: https://moleculer.services/

Fast, battle tested, vue2-like approach, great documentation, good community. The automatic indipendent-scalability as an option is usually the main selling point of these solutions, but honestly I think the real pro is the "composition" approach, which is essential if you want to keep a clean and well-organized codebase. On this regard, I found moleculer pretty great even for large teams.

If you’re using k8s, check out https://moleculer.services and this would likely solve what you’re looking for.

Molecular – Progressive Microservices Framework for Node.js

While you’re delving into microservices, check out Moleculer https://moleculer.services

I almost can’t believe I haven’t seen it mentioned here before, but adding Moleculer into your node project (if it’s clustered/k8s’d) will literally solve many single threaded problems, not to mention tons of other scalability issues. https://moleculer.services/

You could use a framework for this. Have a look at moleculer

I haven't used this, but it seems neat: https://moleculer.services/

Look into Moleculer.

Moleculer already provides an in-house http gateway, but what if you want to use an existing API, and how to maintain decoupled code when creating your gateway? This package solves both. You can create your API, passing in any services you require as dependencies. You can then bind your API to moleculer using the moleculer-universal-gateway.

But there's more to the topic of microservices. Seems like all the conversation focuses on deployment pain. You can build a service with something like Akka or Moleculer where the modules act independently and have some message passing and resilience from each other, but they can still all live in one codebase, one process, and deployed as one unit. It works fine and isn't painful at all. And maybe down the line you decide to split the thing up into multiple processes and multiple deployment units, and that's an easy refactor because the modules are already somewhat separated.