GraphQL is, in my eyes, good for everything else except internal communication. You also don’t get any field protection; in your normal Absinthe configuration (and I suspect that of many other libraries) you can poll whichever field as long as it’s actually a part of your persistence schema (the DB).

GraphQL is also notoriously bad when it comes to caching endpoints. It’s doable but plain old REST endpoints are times easier to cache by proxies, relieving stress off of your servers (if you put them behind something like Cloudflare or dedicated Squid/Varnish proxy machines).

An argument can be made that GraphQL is more ergonomic and intuitive than many others and I’ll immediately agree if you raise that point. But in terms of technical complexity to integrate + maintain + the cost-benefit in your intended use-case… I’d say it’s a fairly risky choice.

Use message passing, like Erlang does instead of RPC systems that try to simulate that calling external function is the same as local call. Just watch this:

That’s not always the case, term_to_binary and vice-versa are not made for speed, consequently there are a number of encoders for the BEAM that are actually quite a bit faster than it (although it’s all so fast anyway that it doesn’t really matter in most cases)