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.

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?

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.

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.