GraphQL for inter-service communication

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.

Thanks for your reply @dimitarvp.

For me the keypoint of GraphQL is really to be able to choose which fields of the resource I want to retrieve.
In my case the inter-communication is through binary protocol using TCP. So GraphQL was a nice approach since it’s transport agnostic . Because as many binary inter-communication services are based on RPC mostly, the data retrieved is everytime the entire set or per use case.

For the caching purpose, in my use case this does not really matter, because the data requested may change and the node involving into a specific shard of the data will change also quite often.

Otherwise I can use a custom RPC mechanism with ETF to filter fields but it will really custom handmade solution and not really so nice to write. I know than many people think RPC calls are faster than REST /GraphQL approach must I wondering if it’s really the case if the data is overloaded the bandwidth will be impacted.

If your microservices are written in Elixir/Erlang, and you want them to talk with each other, you can use the baked-in distributed features

I was thinking so, but the communication will be in a untrusted network(public internet) as P2P decentralized system so some malicious could try to attemp to kill nodes , execute malicious function calls, etc.
So unless recreate a create custom erlang distribution driver, the best may remains the classical endpoint communication.

Maybe FlatBuffers on top of HTTPS, then? Or you said you don’t want to be dependent on HTTP?

This is not ETF, this is Elixir representation of decoded ETF. I have created subset of ETF (no support for atoms and improper lists) named Ernie with example implementation in Rust.

I would tell you to use either:

• C Nodes (despite the name, it can be implemented in any language)
• Any binary format (FlatBuffers, ProtoBufs, Cap’n’proto, custom one) with message passing in any form (HTTP, RabbitMQ, ZMQ, whatever you like)

Indeed I’m not using the BERT or Ernie specification but using ETF with :erlang.term_to_binary to encode freely any term in a binary format without involving any dependencies which come almost for free.
Even if protobuf or Cap’nProto produces a smaller encoded data, Erlang Term Format is definitevely the fastest data encoding on Erlang/Elixir and do not require to generate code.

Does the C nodes helps to avoid the erlang distribution via cookie and capable to be in an unsafe network support ?

Yes I do want to be dependant of the transport, because this layer may evolve for example: TCP,UDP, QUIC,SCPT, WebRTC,etc.. And the data and format exchanged should remains the same to ensure compatiblity.

I’d still recommend FlatBuffers, check it out. There’s a really good Elixir library, too.

The transport could be anything. I’d choose QUIC but there are still no Erlang/Elixir libraries. HTTP/2 or gRPC should be more than adequate for a while.

If you are looking for something P2P-like, I recommend checking out Phoenix.Presence.

Is it better to use distribution, or to send a erlang term over ssl using term_to_binary?