Discussion on "gRPC - the new REST!"

Ankeet Maini · 2021-06-28T06:07:13.808Z

REST is the ubiquitous way of writing APIs for as long as I can remember. Today I want to introduce you to a new way of writing APIs. Have you met gRPC? gRPC is a relatively new way to write APIs and consume them as if you're just calling a functio...

you're saying REST is only http/1 ? That's not true, the plain text REST protocol is the most futuristic, and no problem working over HTTP/2 or HTTP/3

gRPC is only good use as protocols within datacenter between micro-services, never meant to be called in browser to server and is probably never going to gain support in browsers

so gRPC has benefits from performance level due to protobuf encoding; smaller payloads as well as a clear contract which is tangible and not like REST where things are tied together manually (creation of payload, correct URL, query param vs request body)

Cognitive complexity is a thing. gRPC is nice and all, but how many engineers out there actually fluent in it just like in REST? And remember that this number won't grow unless REST is deprecated which is not going to happen.

Though, gRPC is nice for microservices communication.

I'll reply with a follow up on how to integrate it with web, and try to drive the point home that with generated stubs, maintenance becomes so much easier! Stay tuned :)

gRPC is just too complex.

isn't it easier, as you have now auto-generated stubs for all the available service methods?

this will make the integration between backend and frontend super tight - same contract is used to generate the code on both ends, no more searching the correct payload or api endpoint :)

Ankeet Maini yeah it may sounds easy, but the complexity is on the generation of stubs. For examples:

Whether commit stubs to source code or not
When to regenerate when protobuf change
Dealing with protobuf import paths hell
How to version correctly

etc etc...

what happens if they add support for http3 in the future BOOM, bye bye REST but still it will take time to adapt in the ecosystem

This is pretty good. I think as a technology, we should focus on the pros and cons, and why was it introduced. I think it was introduced to keep a single library for each client and server, so the changes are centralized, unlike REST.

Pros:

It is fast
It uses http2 under the hood
Single library for each client and server maintained by google

Cons

Protobuf makes the client bulky
No direct use of JSON, it won't make sense for the client to know the schema
No browser support YET
It is new and growing
Proxy Support, as any application deployed is not just simple client and server so, the proxy or gateway layer should understand the protocol as well

I believe this is a pretty good piece of technology for microservices intercommunication as it is fast and can reduce the latency in communication.

Haha, yes I agree there's a bit of ceremony. Generate code and use a grpc-web proxy for the protocol conversions, but overall maintenance wise it will make a lot easier.

No browser support ~~YET~~

there is with a proxy to patch over the differences and even http1 to http2Tomas Y.

github.com/improbable-eng/grpc-web/tree/master/go…

Discussion

gRPC - the new REST!

Responses(5)

Recent in Forum

Search Hashnode

gRPC - the new REST!

Responses(5)

Recent in Forum