
Don't Use REST for Your Micro-Services - mswehli
https://blog.moodio.co.uk/dont-use-rest-for-microservices/
======
chupa-chups
IMHO if you deem REST to expensive for your microservice, your microservice
shouldn't be a microservice.

A microservice should be a self-contained, understandable and on-its-own
usable component.

For example, a service which resolves zip codes to cities is a microservice by
this definition.

Another example: a service which generates PDFs from URLs by rendering them in
a browser like chrome-headless.

Another example: a service which gathers statistics from a git repository.

A microservice, from my POV, is _not_ :

\- something you use in tight loops

\- something which provides only an abstract value, like for example a
aggregation of min/max/avg/median values of a list

\- something which either doesn't deliver a value of non-trivial complexity
nor is useful to the general public on its own

In other words, if the choice of protocol (in this case REST) matters in terms
of speed, you shouldn't talk about a microservice but more of a component.
This may be a component communicating using TCP, or whatever protocol you
choose. But I'd call something like that not a microservice, but a
_component_. In most languages you'd use a "library", a "jar" or something of
this scale.

Terminology matters (at least to me in this regard :) )

~~~
mswehli
I think the issue is the definition of a microservice isn't really set, while
those are good candidates for microservices, you can even design them for core
functionalities, such as for example in some challenger banks, i've seen the
architecture of one or two who would have a service for different
functionalities,such as one for card transactions, one for dealing with the
account balances, etc.

But in my experience atleast, one of the biggest issues with microservices is
the speed impact. Even a difference of 100ms on a consumer facing application
can be an issue. 200ms is a noticable delay, and if something is 1 second
slower users will actually get pretty frustrated. As for speed, the difference
in speed can be massive, and JSON serialization/deserialization (the way it is
commonly implemented atleast) is very compute heavy especially if it relies on
reflection. So the speed difference can sometimes be 5-10x and in
microservices is a bigger concern then network latency. When you're dealing
with larger dataset this becomes even more obvious.

Using gRPC for example, instead of JSON, the difference can be a couple of
hundred milliseconds, which changes the conversation entirely on whether or
not splitting it into a microservice is worth while and if the end user will
notice the impact.

~~~
chupa-chups
I agree, but gRPC has its own set of issues.

It all boils down to the boring, but real dilemma of finding the least bad
solution ;-)

See also:
[https://www.google.com/search?rls=en&q=cap%27n+proto+vs+grpc...](https://www.google.com/search?rls=en&q=cap%27n+proto+vs+grpc&ie=UTF-8&oe=UTF-8)

