1

This is a hypothetical scenario with some concrete parts.

Say that I have built a system that allows users to interactively arrange living room layout. The result of this arrangement is presented to user in a form of a RENDERED preview image.

The system is built using best practices, SOLID principles, and taking the Uncle Bob's Clean Architecture as one main of the guidelines - one of the reasons - to be prepared for the scaling.

The system is deployed as a web application monolith on the company's web server. After a while, due to a high load, I realize that RENDER component is a bottleneck and it is using a lot of system resources and needs to scale somehow.

The decision is made to move the rendering operation to the external service (different server, cloud, or something)

The existing components that are using render feature need to communicate with external render service somehow. Render service accepts the living room layout model as an input and provides output in form of the raster image, nothing needs to be mutated, persisted, no anything like this - just a simple function that accepts input and produces output.

Now, everybody are screaming REST and I also like some of the generalizations employed in there, but I don't see the REST like approach in here - It just does not align to the resources in any way, just seems to me like a wrong fit.

In other way, it appears to me that communication totally aligns with the RPC (over http of course) style.

So, which approach should I take on this scenario, REST or RPC?

If REST, how that should be realized in a detail?

  • 5
    You know what's totally frustrating? Trying to force a naturally round RPC peg into a square REST hole. There's nothing wrong with RPC, and REST (while getting most of the attention lately) is no universal solution. Go with what works best in your situation. – Eric King Oct 9 '18 at 20:16
  • 2
    Or is it a square peg in a round whole? I forget. :) – Eric King Oct 9 '18 at 20:17
  • I honestly don't see much of a difference. The process accepts input and produces output. The request/response format is a minor implementation detail. – Dan Wilson Oct 9 '18 at 22:07
  • Contentious opinion: RPC and REST are basically the same thing. REST just has zealots that have convinced themselves there's a huge difference. There isn't. – whatsisname Oct 10 '18 at 0:14
  • Could you clarify how the living room layout looks like (and on how many parameters it depends), and how you pass it today to the renderer ? – Christophe Oct 10 '18 at 11:21
2

So, which approach should I take on this scenario, REST or RPC?

"It depends." I'm sure you are shocked.

The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction. Roy Fielding

REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them. Roy Fielding.

The first thing that leaps out at me is the question: multiple organizations. You aren't trying to create some world wide standard protocol for offloading living room rendering onto a server. This changes the calculus for long term compatibility quite a bit.

The second thought is caching; HTTP has really good caching support. If your use cases have significant re-use of rendered images, then having the caching done for you could be a good win.

So if the number of combinations is small (a billion? 10 billion?), and especially if a small set of them tend to be interesting at any given time, then caching might well pay off.

If REST, how that should be realized in a detail?

Well, it probably looks like a web form that allows the client to specify the living room layout model.

If the information fits into a query string, great! the calculation of the URI occurs on the client, which can then check to see if it already has a valid copy in the cache.

If the information doesn't fit into a query string, then you are probably looking at a POST to the server, which can calculate the URI and send it back to the client, and then protocol looks the same from there.

  • It's nice to know there's someone else out there who hasn't drunk the entire jug of REST Kool-Aid. – Robert Harvey Oct 11 '18 at 21:04
  • Thank you for the answer, that aligns to my understandings and opinion (not so much experience, that is why the question was asked in first place) – Dusan Oct 13 '18 at 19:52
1

RPC over HTTP and REST will have similar performance since both will have to send the parameters and receive the result using the same protocol. The only difference could be caused by the encoding, but you could opt for JSON in both cases.

So the main criteria for choice is the API philosophy which best fits to your use case:

  • The RPC API philosophy is to provide services that correspond to methods, e.g. renderLayout(). There is a natural fit with your use case, since you just want to distribute existing methods of your current processing across several nodes. But on the other side, there are quite a few variants of RPC around there, so you'll create some interoperability constraints.

  • The REST API philosophy is resource oriented and uses a well known uniform interface. The endpoint would in principle be named according to a resource and a unique ID, e.g. /rendered-layout/2567. So you could create a rendering with a POST (parameters in the body), and later reuse this rendering with a GET for the same ID, and get the whole thing accelerated thanks to caching. The resource oriented paradigm would require a change in your design. On the other side, the benefit is that it decouples more the components and reduce interoperability constraints since REST is quite universal.

  • Thank you for your answer and pointing out some things. – Dusan Oct 13 '18 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.