Microservice node communication with Phoenix

Could you elaborate a bit on why you want it this way? It sounds like you are adding a lot of complexity for gains I don’t see.

To use built in node communication in a somewhat easy manner you need codebases that are either the same or very aware of eachother, which sort of brings you back to a monorepo just split across more servers.

Why not use a http layer for the synchronous parts? Build a authority of sorts on the web node and pass it along with each request to keep the microservice acl etc.

In microservices architecture, the microservices share “raw data”, i.e the interfaces can expose maps, not struct. Each microservice must have its “view” of the model. For instance, a product in microservice A may have some different attributes from a product in microservice B. The output of microservice A will be a map, and microservice B will receive this map and convert it to its struct or schema.
Phoenix offers a backend-template application, so you don’t need microservices and you can use the schema along all your application but if you really need microservices, it’s a good way to use Erlang node communication and to apply decoupling between them.

Option 4: follow the first rule of distributed objects and don’t divide the system up this way.

AFAIK there aren’t any common patterns that would recommend turning context or view functions into remote procedure calls. Code in the “frontend” should interact with the “backend” via a clearly-defined API.

One other thing worth thinking about: the remote Task.Supervisor is single-threaded, so unless you add a lot of complexity that can be a bottleneck at high concurrency.

I have seen this solved before in a Java microservice cluster and it might work well for your case. Services that communicate had a shared library of DTO class definitions. They weren’t the entire schema, but it was more of a request level object. The same could work for your schema definitions for task spawning. Two services could share a hex package (or even a git submodule) that has the shared definitions. That might not be a very ‘erlangy’ way of solving things, however it seemed clean enough in the Java environment. The downside was that both services needed a redeploy for schema changes, and the receiving serviced needed code around to handle the previous ‘version’ of message format that could be cut away after a full deploy.

The idea is that each service will likely be split across multiple servers with some extra instances of some whereas others may only have a few instances. Having the services split allows for teams to work on them individually and operate on their own and merely interface with other services. Using a HTTP layer is no different than using node communication, just the node communication is a bit more of a robust thing that will not require as much extra development effort as an entire HTTP API.

I understand what you are saying, so basically each instance has no knowledge of the source or, in a way, meaning of data, hence why structs will not work.

That is quite helpful thank you.

That is a good point, either will need multiple task supervisors or use an alternative for spawning tasks.

Yes, this is a significant downside as it doesn’t isolate the services entirely.

I would recommend you to read the @PragDave Programming 1.6 Elixir book or his video course to see how he suggests to tackle what you are trying to do. Basically you will work with what the Nerves team coined of Poncho projects in terms of folder structure, but with a very nice and clean separation as you want, were teams can work independently and code can live in separated repos, but are deployed in the same server until the day it is necessary to scale it to multiple servers.

The phrasing is a little flippant, but the message is serious. Imposing a network boundary where there was only a module boundary before has significant costs:

• duplication (for things like data definitions)
• latency (network calls take time)
• fallibility (network calls can fail)
• deploy complexity (network calls may interact with servers that are a different version)

The biggest hazard in building a distributed system is that you get all of those headaches automatically, but you only get the good stuff (independent scaling, independent deploy, etc) with the right implementation.

For instance, an Elixir novice who confuses GenServer with “a server” and makes each piece of their application a single GenServer will produce a single-threaded performance tarpit.

The “rule” is a reminder to carefully consider the consequences of your decisions - what are you getting in exchange for all the additional complexity?

I read this a long time ago, will give it a re-read with this project in mind, thanks.

This is a good point, but the idea of separating services is that this communication between them should be minimal. I see the error I made in having a separate service for the frontend, it does not seperate them correctly as it must know the context behind all the data, which breaks the rule.