> However, it's important to note that browser support wasn't a primary focus in gRPC's design. This oversight necessitates an additional component, grpc-web, for browser accessibility. Furthermore, external services often have specific needs like caching and load balancing, which are not directly catered to by gRPC. Adopting gRPC for external services might require bespoke solutions to support these features.<p>The article should mention the Connect protocol for web-based Protobuf messaging and is compatible with gRPC, so it can be used for service-to-service and service-to-web communication:<p><a href="https://connectrpc.com/" rel="nofollow noreferrer">https://connectrpc.com/</a>
> gRPC is immature<p>Seven years (the time since Google made it open source) is immature? Plus however long Google used it internally? Berners-Lee invented HTTP and the web in 1989. By 1996 we had Yahoo!, Altavista, Netscape, and the NY Times had a website.
I used to use it a lot but in time it becomes more of an obstacle than a net positive. http and websockets with json(front end), cbor(back end) or pb(back end) is the way to go. it gives you exactly the same features but zero restrictions. it is nice to have pb schema that is transferable into other languages but you can define schema in anything and port it to anything, it just takes time to initially write it instead of using pb as intermediary. the little layers of code it autogenerates is not worth the limitations you might be needing to overcome in the future with a larger project. also there is massive issue with no value provided vs null or empty or zero value. pb tries to solve this by using wrappers but in code that is massive pain to work with all the nesting. that was actually what broke the camel's back for me.<p>i just want to mention that i do not use rest, at all. i do use http methods and url routes but i never accept any rest rules for design or behavior. i am using something like json rpc but i am not using a single route to handle all communication. i still use the same approach as grpc does - route per method, but i keep the flexibility of naming and http methods. people seem to be very much stuck with rest and its limitations/rules for some weird reason.
Is there any reason grpc isn't more popular for the public API of stuff? I'd rather work with grpc than ad-hoc "REST" API's 9/10.
The next time I want to build an API, I will probably make use of <a href="https://github.com/twitchtv/twirp">https://github.com/twitchtv/twirp</a>. I like working with Protobuf and having strongly-typed and well-defined messages, but gRPC is way, way too much. It's obviously a Google product, built for what Google needs.<p>Use Protobuf for messages, but just use HTTP for transport.
REST is such a poorly understood term.<p>gRPC services are by design client-server likely built in a stateless way. It uses HTTP and exploit the same tools that REST would use for layering such as proxies, etc.<p>Not sure which parts make it more complex.<p>gRPC is still over HTTP right?<p>Most of the other arguments are weak too. I'm not convinced gRPC is any better understood.