Relying on :erpc for networked nodes

With several Phoenix apps clustered with libcluster, it’s easy to make calls to remote nodes via :erpc.

Say I have two different public-facing apps, and one needs to fetch data from the other to serve requests. Is it a reliable pattern to use :erpc for this relationship? Are there known limitations or performance hits for concurrent requests over :erpc?

To be fair I’m not a big fan of doing rpc calls without a predefined contract, that can be enforced on both ends, it is just too easy to break the contract by accident.

IMO a monolith that has good separation of code will be times more easier to manage than those 2 separate services trying to communicate via rpc.

1 Like

it is just too easy to break the contract by accident

The plan is to define a tested and documented API for use by :erpc calls for exactly that reason. We have domain reasons for maintaining separate apps.

Architectural concerns aside, are there known limitations or performance hits for concurrent requests over :erpc?

Have you read the introduction paragraph for erpc? I guess this is an important pointer that is presented there: Erlang -- Processes

1 Like

I’ve only used :rpc (or software that used rpc, erpc looks like a newer version) and I’ve never really hit limits on this. The situation was:

  1. Everything was in same dc(no wan)
  2. Everything was trusted.
  3. Less than 15 nodes connected (other network topologies exist that can connect more, but it was unnecessary as boxes wese beefy).

I don’t think there’s any reason not to use it? The alteratives aren’t that great either. Spending cpu serializing/deserializing json over http? After seeing 25% of the cpu going to parsing, deciding to go to a binary format like messagepack? As long as everything is trusted, single datacenter, and no reason to talk to non-BEAM languages, why not use the standard protocol? For instance, I never had any issues with riak clusters and I can’t think of any application that would be more chatty.

Then on modern hardware, I don’t think it will be very easy to hit the limits. Anyway, for further information:

http://erlang.org/pipermail/erlang-questions/2016-February/087698.html

Personally, I would be more concerned about security and the introduction of other languages than the scale in most situations.

3 Likes

@D4no0 I have read the introduction paragraph. I have also read the note about blocking signals, although I can’t say I totally understand it.

@tj0 there is a line in the introduction to :erpc that says it “has better performance and scalability than the original rpc implementation” but with no implementation details. Based on the paper you linked, it appears even the original :rpc would be scalable enough for our current needs. It’s good to know that Node.spawn/4 is there if we do hit some of those bottlenecks.

1 Like