Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC: 5 Years Later, Is It Still Worth It?

kostyay.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: gRPC: 5 Years Later, Is It Still Worth It?

#31

Post by kostyay »

danans wrote: post #19

> We wanted to eliminate the need for each engineer to individually install protoc and multiple plugins and to make generating Go or TypeScript assets a single command a developer could execute. Couldn't you just make protoc part of your project's git repo? > This approach ensured that everyone on the team was using identical versions of these tools throughout their development process. While this does enforce using…

We usually commit the generated clients/servers to the repo and expect developers to run the code generation on their machines.

Re: gRPC: 5 Years Later, Is It Still Worth It?

#32

Post by kostyay »

skrtskrt wrote: post #6

In years of developing pretty complex products with gRPC I don't think we've ever run into an issue or sharp corner. Having the libraries generating relatively optimized message parsers and server implementations and just throwing middlewares around them, with easy support for deprecating fields, enums, and a bunch of other goodies - all been a huge help and productivity gain. So much can be done by just understandin…

Same experience for me as well. It does what it should well, the clients and servers it generates in Go are pretty good.

Re: gRPC: 5 Years Later, Is It Still Worth It?

#33

Post by kostyay »

jrockway wrote: post #7

Things I've learned using gRPC for ~10 years: 1. I really like gRPC and protos for the codegen capabilities. APIs I've worked on that use gRPC have always been really easy to extend. I am always tempted to hand-roll http.Handle("/foo", func(w http.ResponseWriter, req *http.Request) { ... }), but gRPC is even easier than this. 2. grpc-web never worked well for me. It's hard to debug; in the browser's inspector you jus…

Thanks for the write up.

> grpc-web never worked well for me. connectrpc is good alternative for the client side libraries. The code it generates is much better than the one produced by grpc-web (and the 3-4 different plugins on the market for it). it also supports grpc-web encoding out of the box. we are still using grpc-web internally just with connectrpc generated clients. The frontend engineers were extremely happy when we moved from the grpc-web clients to but ones. The DX is much better.

> grpc-gateway works pretty well, though. I think grpc-gateway is a decent choice if you are building REST api for internal use. It does feel like an unfinished product (well.. it is a community effort). Specifically if you decide to follow Google's AIPs guidelines (https://google.aip.dev/general) you may find that some things are not implemented. Another downside of it is that it can't produce OpenAPI v3.

Re: gRPC: 5 Years Later, Is It Still Worth It?

#34

Post by kostyay »

Groxx wrote: post #14
jameskilton wrote: post #4

I love protobufs as a type-safe way of defining messages and providing auto-generated clients across languages. I can't stand gRPC. It's such a Google-developed product and protocol that trying to use it in a simpler system (e.g. everyone else) is frustrating at best, and infuriating at worst. Everything is custom and different than what you're expecting to deal with when at its core, it is still just HTTP. Something…

Yea, and the code gen (for Go at least) very clearly assumes you're using a monorepo and how dare you think of doing anything else you monster. E.g. there's a type registry, which means you can't ever have the same proto type compiled by two different configs (it'll panic at import time). In a monorepo that's (potentially) fine, but for the rest of the world it means libraries can't embed the generated code that they…

> E.g. there's a type registry, which means you can't ever have the same proto type compiled by two different configs (it'll panic at import time). In a monorepo that's (potentially) fine, but for the rest of the world it means libraries can't embed the generated code that they rely on (if the spec is shared), which means they can't customize it (no perf/size/etc tradeoff possible), can't depend on different versions of codegen or .proto files (despite code clearly needing specific versions, and breaking changes to the generated code are somewhat common), can't have convenience plugins for things that would benefit from it, etc.

I actually forgot about this when writing the article. This is a major pain in the ass both in Go and Python and basically forces you to ensure than no 2 services have the same file called "api/users/service.proto". There have been multiple instances where we literally had to rename a proto file to something like reponame_service.proto to avoid this limitation.

Re: gRPC: 5 Years Later, Is It Still Worth It?

#35

Post by kostyay »

jameskilton wrote: post #4

I love protobufs as a type-safe way of defining messages and providing auto-generated clients across languages. I can't stand gRPC. It's such a Google-developed product and protocol that trying to use it in a simpler system (e.g. everyone else) is frustrating at best, and infuriating at worst. Everything is custom and different than what you're expecting to deal with when at its core, it is still just HTTP. Something…

Twirp looks cool. Is it still being maintained? Would you choose it over connectrpc?

Re: gRPC: 5 Years Later, Is It Still Worth It?

#36

Post by danans »

kostyay wrote: post #31
danans wrote: post #19

> We wanted to eliminate the need for each engineer to individually install protoc and multiple plugins and to make generating Go or TypeScript assets a single command a developer could execute. Couldn't you just make protoc part of your project's git repo? > This approach ensured that everyone on the team was using identical versions of these tools throughout their development process. While this does enforce using…

We usually commit the generated clients/servers to the repo and expect developers to run the code generation on their machines.

What's the advantage of calling a locally running server vs running the codegen directly on the command line?

Re: gRPC: 5 Years Later, Is It Still Worth It?

#37

Post by bediger4000 »

atombender wrote: post #29
andrewl-hn wrote: post #20

I haven't done any gRPC programming, but from what I understand it's a modern re-imagining of XML Web Services: you describe the contract and can generate client and server code based on it for different programming languages. Early on in my career I worked on several projects that used WS-* "stack", and generally it was a very good experience. Once we had a project that was split between two subcontractor teams and…

Sun RPC — the official name was ONC RPC — was probably the first modern RPC. It's an Internet standard. You've probably used it without realizing it; it's the protocol that NFS uses. If you've ever had to deal with the NFS "portmapper", then that's because of Sun RPC. Some other protocols use it. It uses XDR as the schema definition language. XDR is basically analogous to Protobuf files. It has structs and tagged uni…

DCE RPC was the old Apollo Computer Inc RPC system probably with big fixes and support for 64-bit CPUs. I'm not sure what relationship it has to ONC RPC, peer, ancestor or descendant.

See: https://jim.rees.org/apollo-archive/papers/ncs.pdf

Post reply on HN