feat(): message passing between domain lines

[scott-wyatt]

Languages like Erlang/Elixir are super solid because of the way they use mailboxes (among other things). Fabrix is already just extending the base "Emitter" class to give it most of its functionality. There's something to be said about giving each spool and each thread/spool it's own mailbox and in turn it's own address for the spool and the threads that it's using. This will helps fabrix distribute better and opens opportunity for a new class of spools, ones that allow connections between different instances of the core.

Example:

<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>
<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>
<App Address:uuid> -> <Spool Address:uuid> -> <Method Thread Address:uuid>

doing app.spools or app.models could resolve where those things actually live and mailbox the requests etc,

Many of these types of small enhancements came up while constructing spool-broadcast, and honestly, it makes sense for a fabrix app to not have to reside on a single machine as a micro service, when it's already so close to being distributed with some slight but significant enhancements.

Using proxies, generators, and async/await, we could also keep everything compatible with the existing ecosystem, but also get the huge benefit of fully distributed applications (that still have perks like using other frameworks inside fabrix).

This could be a v2.0 or a v1.7 feature.

[jaumard]

Very curious and existed about this :) I don't know shit about distributed system, but one question that popup in my mind is how spool will start ? after that I can imagine with some pub sub they can send/receive message and interact with each others.

But when fabrix app is started how spool will be started (and monitored) ?

[scott-wyatt]

I’ve been thinking this through a lot. It’s a given that we’ll use node’s built in dgrams for communication, so UDP sockets. It also makes sense to use a SWIM protocol for spool discovery. The last part, starting a remote spool is interesting, but my current plan is a micro-version of fabrix attached to the spool that’s listening for the real fabrix app messages. similar to how Elixir’s Genserver works. I think the real tricky part will be remote configuration. There will have to be a new stage in the lifecycle that does spool discovery and when a spool is discovered it sends back it’s config and a manifest of it’s worker threads. When fabrix does something like app.model.User, that could be proxied to the spool that is in charge of the model and let it’s machine thread handle it.

…

On Oct 23, 2019, at 5:57 AM, Jaumard ***@***.***> wrote:  Very curious and existed about this :) I don't know shit about distributed system, but one question that popup in my mind is how spool will start ? after that I can imagine with some pub sub they can send/receive message and interact with each others. But when fabrix app is started how spool will be started (and monitored) ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.