And if you have a lot of GRPC internally between microservices (90% of our code is Go/Python GRPC linked) it can be a natural extension. I personally find streaming requests a bit more intuitive than the invalidation logic in GraphQL. It's easier to deal with binary blobs (uploads etc). ![]() That being said, GRPC does have some advantages (and for us they were important, so we are very happy with our choice). The GraphQL ecosystem is amazing, especially if you stay in Typescript land. It's only just become a "GA" feature but there is still a ton of bugs and documentation missing. I wouldn't say grpc-web is mature at this point. In fact it would probably be a bit easier since grpc-web needs to handle HTTP2 push over 1.1 connections using some envoy filters. There's also nothing preventing you from running GraphQL over http2. You could do the same thing in GRPC.but you'd be on your own. There is a significant overhead with the proxy, and depending on how you write resolves it could be really beneficial to only compute/cache the data that is needed. Maybe it's a good idea for the team to put up a very clear "how does GPRC compare to." page.įirst, grpc-web Won't magically improve performance, you need to benchmark for your specific application to make sure it does. ![]() Ok, love the enthusiasm but I think it's important to place things in perspective here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |