I am developing an application which include P2P services. Each service is using tcp server/client . And I am interested to use GraphQL specially Absinthe for the inter service or inter node communication . Many of P2P are using RPC but I want to leverage the concept of graphql around the query aggregation and field projection to reduce bandwidth and increase throughput.
My first idea was to use ETF with field projection but it seems a bit verbose, non standardised.
Exemple: {:my_method, [param1: val], [:field1, field2: [:field3]]).
So graphql seems good for that.
Unfortunately often services communicate over rest or rpc but graphql endpoints are often on the external client side but not really inside.
Do you have ant thoughts about using GraphQl as internal 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.
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.
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.
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.
Cookies aren’t security feature, you can use distribution over SSL and you do not need to use EPMD if you do not want. Additionally you can always use solutions like Linkerd, Envoy, or Consul Connect for creating secure service mesh.
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:
Thanks for the video. Really interesting.
Asynchronous mechanisms in distributed system or microservices it’s a good way.
But I’m trying again to understand the concept and how it could be managed over a network.
If you have some examples or code using this concept I would be interested.
And I’m struggled why some many big companies Google, Facebook, etc… are using a lot of RPC’s style internally while message passing seems better .
Because at the end recent RPC solution such as gRPC, Thrift, Avro, etc… are kind of RPC over messaging. Code does not call remote method as local method but kind of wrapper around a use case. But publishing as method over an IDL RPC interface.
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)
From the benchmarks I have done with protobuf, flat buffer, avro, msgpack, thrift, cbor and etf, for encoding/decoding, Etf is really fast , I think this is due to the free serialization of erlang term in the BEAM. But for the size of the binary data, protobuf seems to be the best.
