Hey developers :D, what you think about gRPC it can replace REST?

#discuss #grpc

Top comments (4)

I'm not sure if you mean "can [gRPC] be replaced by REST" or "can [gRPC] replace REST", but my answer in both cases is no. The philosophy of gRPC, or any other RPC protocol, by the way, is to trigger actions on a remote machine, while the philosophy of REST is to access resources in a remote machine.

Some times your domain can be modelled better by resources that are accessed and modified, and some times it works better with actions that are triggered.

The thing is, both RPC and REST have their merits, are useful in different circumstances, and neither is going away anytime soon.

rhymes • Jul 20 '18 • Edited

Hi Heithem, I wouldn't call REST off. Most APIs are still REST based.

What I see now are three main approaches in API development:

REST (or RESTish, because most public APIs I work with don't have the hypermedia part of REST)
GraphQL
gRPC

I've never tried gRPC so I can't provide an opinion but I hear is very efficient. AFAIK it requires HTTP/2 by default, so this might slow down its adoption on public APIs. I would definitely consider it if I controlled both ends of the application though (and when not using Heroku).

I think, for now, GraphQL has made more a splash in term of adoption than gRPC.

Nicola Apicella • Jul 20 '18

I think gRPC is something to seriously consider when developing a service which is gonna be called by other services (service to service communication ) instead of users.
Reason being the fact that gRPC allows to establish a contract between services.
Although rest api are really powerful, you have a higher risk of breaking service consumers because of its unstructured nature.
Contract Driven contracts can help with that, but you still have risks.
I have actually wrote an article about Contract Driven contracts and I wanted to write another one about service to service communication in which I wanted to describes the trade off of those solutions.
-Nicola