Why gRPC is Popular 🚀 gRPC is gaining popularity for service-to-service communication. Here's why: - Speed - gRPC is built on HTTP/2 and Protobufs for maximum throughput and minimal latency. Much faster than JSON over HTTP. - Efficiency - The compact Protobuf binary format means smaller payloads than JSON. Less data sent = better performance. - Type Safety - Protobufs are strongly typed, eliminating many bugs. - Polyglot - Write services in many popular languages, the IDL works across them all. - Streaming - gRPC supports bidirectional streaming for real-time data transmission. - Great Ecosystem - Tons of tools exist for code gen, load balancing, monitoring, and more. Of course, gRPC has some drawbacks: - More Complex - Defining Protobuf schemas and setting up gRPC can have a learning curve. - Not Human Readable - Protobufs are binary, so not as easy to troubleshoot as JSON. Tools like grpcurl help a little bit. - Limited Browser Support - gRPC works best for backend microservices, not front-end apps. For most backend use cases, gRPC delivers an efficient, robust and high-performance communication framework perfect for modern microservices. – Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages): https://bit.ly/496keA7
As a developer who has used grpc a lot, these points don't matter much, the biggest advantage is ease of use and developer productivity, you can easily have well defined type safe protobuf schema files, and generate stubs, the whole process has improved a lot and is a breeze. If you have troubles with grpc communication due to native AWS LBs not supporting http2 communication, you can generate general api endpoints on top of your grpc server (a grpc gateway). TLDR: developer productivity and definite type safe compiled schema are the key features, just imagine maintaining openapi specs with multiple nested indentations for every microservice, everything else was working before too !!
drawbacks; using oneof's wildly and ending up with tons of type assertions and thinking type assertions won't hurt the performance having to use "optional" even though that property is not optional in logical sense, having to deal with generated code that obfuscates everything you have with nested with pointers (using pointers for everything is bad data structures design) sure, format is efficient but is it really worth it for everything really? I believe the biggest evil that is created in programming is reckless/fearless code generation and relying on code generation in big software
Not sure we should really jumi to gRPC and go with it for long like it happened to the great free CentOS Operating system. CentOS is being closed for updates by Red Hat shortly and users/customers have to pay to get new updates, especially security updates are essential. Recall the great website Slideshare which was free. Now it has been taken over by Scribd and need to pay to download anything from Slideshare. Who knows,one day, Google will follow suit and updates to gRPC might be available on payment basis. Lincesing models especially free ones we need to be careful before jumping into it. PostgreSQL is a great free database. Not sure if curtains could be down for its free updates in future. A quick Google search gave this result on gRPC on the Github: https://github.com/grpc/grpc/issues/32719
as much strong points it has, also some drawbacks - difficult to build a load balancing infrastructure for grpc based services - strong coupling between services compared to event based systems - more infra investment as a result for systems that need to handle high scale throughput
I feel "popular" isn't a quite the right word ) it's used by giants but overall it's marginal compared to regular JSON rest APIs usage across industry
Protobuf is just a serde format, and is layer 7 agnostic, can be served over http1.1 as well. So json over http analogy for comparison won’t fit imho.
gRPC is great. Another reason is that generated client and server codes allow static checking / analysis of both sides. But grpc-gateway is terrible. The generated code is barely readable. So you better pray it has no bugs! I actually went out of my way to write a replacement for grpc-gateway tool!
I used protobuf in Android Native. And migrating it to Flutter. And I guess it's hard to migrate them seamlessly. Is that possible?
Not all companies are like Google (most companies aren't :)), so there's a good chance you don't need most of the Google tech either... For most the complexity you get isn't worth it and the performance you think you need isn't needed because there's a 99% chance that you will never have the number of customers Google has and their scale. Something to keep in mind :)