[chrisweekly]

Apples and oranges? gRPC might sometimes fit the bill for server-to-server use cases, but it's completely unsuitable for integration with SPAs; grpc-web was never well-supported, and is now dead. I don't understand the "want to vomit" perspective. That implies that adding protoc to your build toolchain and using an opaque binary format/protocol is somehow much more palatable than well-documented JSON / REST over HTTP. What am I missing?

[cdelsolar]

ConnectRPC works over the web and I've built several web apps (SPAs) with it. It works with JSON by just setting the Content-Type header to `application/json`. You can add compression easily on the backend with a single option. Generating typed stub code is one line (`buf generate`). Connect-ES is awesome - it's a Typescript-first protobuf library for the web.

Interacting with the API is very simple, for example:

        const resp = await gameEventClient.getRecentAnnotatedGames({
          limit: annotatedPageSize,
          offset: recentAnnotatedGamesOffset,
        }); 
        setRecentAnnotatedGames(resp.games); 

These function calls are typed and a lot of the code is auto-generated from the .proto spec (i.e. above the gameEventClient and getRecentAnnotatedGames are auto-generated code). On the server side the code is also obviously auto-generated. It all works seamlessly. Even the documentation for the API can be auto-generated. See for example:

https://buf.build/domino14/liwords

The above documentation was auto-generated from my protobuf files. This project uses ConnectRPC on the backend and on the front-end SPA. To me it seems so much simpler and better than the way I've seen people use OpenAPI - where many people seem to create the code _before_ creating the spec. I actually haven't found a good Go generator of stub code from an OpenAPI spec. With ConnectRPC it just works, it's simple, easy, fast, etc. It's easy to add interceptors to do things like parse the http request for an Auth or Cookie header and then insert the user ID etc back into the context for the different service functions to handle whatever needs to be done with the authenticated user.

I could ask the same question - what am I missing?

[chrisweekly]

Thanks for the thoughtful reply. Glad you found something you like that's solving your problems! The docs you linked do look nice. Ironically, I noticed this quote there:

> "It's much easier to use the API with JSON + a web browser, but the protobuf option is still available..."

... which sort of underscores my perspective (which is admittedly strongly biased towards / empathetic with the API consumer side).

[cdelsolar]

Yep, but the awesomeness of ConnectRPC is that you can use the JSON api in the web browser, and indeed I do that in this project. We don't have to, and as a matter of fact it's a little less performant, but it's easier to debug and hack.

[chrisweekly]

Cool beans. Thanks for the response -- TIL!

[meta: IMHO this is an exemplary HN interaction; instead of shouting past each other, we shared very different points of view, and one of us learned something potentially useful.]

Any idea how monstrous migrating from gRPC to ConnectRPC might be, on the backend?

[cdelsolar]

I've never used gRPC before, but from what I can tell, ConnectRPC tries to be compatible with it.

https://connectrpc.com/docs/go/grpc-compatibility/

It might not be super simple. Good interaction, I agree :)

[bufbuild]

Connect libraries are 100% compatible with gRPC - in many cases, they implement the gRPC spec more faithfully than the core libraries themselves: https://buf.build/blog/grpc-conformance-deep-dive

TLDR: there should be no migration cost.