4 ms·

There seems to be two groups of protobuf libraries for HTTP 1.1, the ones that want to make it look like binary+HTTP/2 grpc (grpc-web, grpc-gateway), and the on

by fizx 4y ago

There seems to be two groups of protobuf libraries for HTTP 1.1, the ones that want to make it look like binary+HTTP/2 grpc (grpc-web, grpc-gateway), and the ones that make it look like idiomatic web tech (twirp). I'm excited to see more ideas in the second category.

mf192 4y ago
Curious, do you see connect-web falling into the former or the latter group?
jrockway 4y ago
grpc-gateway is actually in the second class. It allows you to annotate your protobuf so as to create a JSON + HTTP method based API (people call this "REST") that is translated to gRPC for your actual backend. (gRPC/Web is protobufs over HTTP/1.1. Different than strict HTTP/1.1 transcoding, though, which is also possible for gRPC to do.) I think grpc-gateway is absolutely what 99% of users want to do. You can generate client stubs (it will even output an OpenAPI spec) like you can do for gRPC + protos, but it's all HTTP/1.1 + JSON over the wire, so if you really want to hand craft curl requests, you can. (But with an OpenAPI spec, you'll really like just plugging it into some GUI tool to make these one-off requests. Even curl diehards like myself.) grpc-gateway is also up front about not supporting things browsers can't do, like bidirectional streaming. gRPC/Web always disappointed me on that front; "coming soon" for years. In the past, I used grpc-gateway (in process, some minor downsides compared to running the gateway as a separate process) + gRPC for my service's internal admin API. It was very few lines of code whenever you wanted to add a new endpoint, and because of the OpenAPI spec, it became available for use in our admin GUI as soon as you pushed the new server code. If someone wanted to add a new endpoint, there was basically no tedium, edit the proto, "go generate ...", implement the generated interface with your actual functionality, push to production. We embedded the generated OpenAPI spec in the doc, so you could just point at app.example.com/OpenAPI.json and clients would auto-update to see your new endpoint.) I actually converted in-place a hand-coded REST API; all the requests and responses and endpoints stayed the same (thanks to the power of the grpc-gateway annotations), but I deleted all the code in every handler that did the marshaling and unmarshaling. The result was something that was very easy to add to and maintain. I liked it a lot and would do it again without hesitation. (We used Retool as the GUI. Not sure I'd recommend it, but it worked fine. I've seen some HN posts about open source alternatives, those look awesome.) I have also written several apps that use gRPC/Web. I didn't find the experience bad, but the Javascript bundle size is huge, so I never felt great about it. grpc-gateway should be the first thing you look at, your server code will be simple, and your client code will be small. And hey, if you have non-web clients, plain gRPC is great too.

by fizx 4y ago

mf192 4y ago

Curious, do you see connect-web falling into the former or the latter group?

jrockway 4y ago

grpc-gateway is actually in the second class. It allows you to annotate your protobuf so as to create a JSON + HTTP method based API (people call this "REST") that is translated to gRPC for your actual backend. (gRPC/Web is protobufs over HTTP/1.1. Different than strict HTTP/1.1 transcoding, though, which is also possible for gRPC to do.) I think grpc-gateway is absolutely what 99% of users want to do. You can generate client stubs (it will even output an OpenAPI spec) like you can do for gRPC + protos, but it's all HTTP/1.1 + JSON over the wire, so if you really want to hand craft curl requests, you can. (But with an OpenAPI spec, you'll really like just plugging it into some GUI tool to make these one-off requests. Even curl diehards like myself.) grpc-gateway is also up front about not supporting things browsers can't do, like bidirectional streaming. gRPC/Web always disappointed me on that front; "coming soon" for years. In the past, I used grpc-gateway (in process, some minor downsides compared to running the gateway as a separate process) + gRPC for my service's internal admin API. It was very few lines of code whenever you wanted to add a new endpoint, and because of the OpenAPI spec, it became available for use in our admin GUI as soon as you pushed the new server code. If someone wanted to add a new endpoint, there was basically no tedium, edit the proto, "go generate ...", implement the generated interface with your actual functionality, push to production. We embedded the generated OpenAPI spec in the doc, so you could just point at app.example.com/OpenAPI.json and clients would auto-update to see your new endpoint.) I actually converted in-place a hand-coded REST API; all the requests and responses and endpoints stayed the same (thanks to the power of the grpc-gateway annotations), but I deleted all the code in every handler that did the marshaling and unmarshaling. The result was something that was very easy to add to and maintain. I liked it a lot and would do it again without hesitation. (We used Retool as the GUI. Not sure I'd recommend it, but it worked fine. I've seen some HN posts about open source alternatives, those look awesome.) I have also written several apps that use gRPC/Web. I didn't find the experience bad, but the Javascript bundle size is huge, so I never felt great about it. grpc-gateway should be the first thing you look at, your server code will be simple, and your client code will be small. And hey, if you have non-web clients, plain gRPC is great too.