128 likes
·
1.6K reads
14 comments
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.
It has browser support since 2016, if you check the code link mentioned at the end of the page. You can find the web integrated with gRPC service.
bulky-client
- it doesn't right? It makes you free from manually hand-crafting the http request
- it generates the stubs only, which know how to connect to the remote service
json
- there's no json, as the client can directly use the response objects created and use it in app
- no need to know the format of the serialzed data sent over the wire
it's just my opinion when I think of grpc, I really appreciate your article.
I just compared with the following scenario of the rest
- you don't need any schema
- you don't have to stay fixed with a schema from the client side.
- any HTTP request you send does not need to have a prevalidated schema
In the case of grpc, you will need a proto file for each grpc service you want to call to the backend. I meant this when I said bulky.
From Browser support I mean, there is no direct web API that can call the grpc. To call the grpc you will have to follow something like the following
client -> rest endpoint -> grpc endpoint
This was the state when I read about this technology and explored it. I will appreciate it if you can add some resources which can contradict the web API issue.
Thanks for a great article. Happy Coding
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.
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...
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 :)
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
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)