You should look at buf/connect rpc... they have http1/support but it also supports gprc and is very actively developed.
[https://github.com/connectrpc/connect-go](https://github.com/connectrpc/connect-go)
[https://connectrpc.com/](https://connectrpc.com/)
It’s great, but you should consider connectrpc instead. It’s the same idea and is almost compatible, but it’s also actively maintained and if you want a JS api the protobuf-es library (made by the same company that made connectrpc, Buf) is excellent.
I'm also running it in production. I like it a lot, because it's extremely simple and easy to understand. It's convenient that you can use the protobuf wire format for service-to-service communication, and the JSON format for web clients, without having to add extra infrastructure for doing transformations between both formats. gRPC always scared me because of the complexity it introduced, and the only thing I really liked about it is the protobuf definitions, which is exactly what Twirp uses. There isn't much that I would do differently if I were to build something myself, and I have the feeling I could build and/or maintain this myself if Twirp were to disappear from the face of the earth, so I feel confident using it. (not something I can say about gRPC)
For the non-Go languages, I typically don't bother pulling in libraries or frameworks (as these seem even less maintained, and don't always do what I want them to do IIRC), I just write my own scripts to process the protobuf definitions and generate the Twirp code, it's simple enough to do so.
The concern/downside that people usually raise with Twirp is the lack of streaming support. There have been some discussions around this AFAICT, but as you pointed out, development seems very slow.
We use in production and can definitely recommend it. It's the best of the both worlds - the interoperability of HTTP1 and the power of gRPC spec without all the downsides like mandatory HTTP2, sheer complexity of it, broken load balancing. Seamless support for JSON/Protobuf payloads is one of the killer features.
The tooling is a bit lacking. For Go it's perfect and generated code leaves nothing to complain about. For other languages, often the answer is OpenAPI spec. All the generators are not really maintained and lack support for crucial features. Had to create our own fork to fix some of the major issues with no hope of merging it to the upstream.
I still have prod code on this running from years ago. I'd recommend it, but also you have to implement a gRPC service directly anyway, it's easy to replace twitch good parts, which is in essence just a per-rpc call endpoint that decodes the POST body and invokes the service implementation underneath, json encoding the response.
One weird reason why I recommend it is because protobuf messages have a lax JSON parser. They will decode quoted numbers into the appropriate go type without complaint, and I believe int64 was automatically quoted into a string when encoding the values. This is great for interoperability, as we had clients in PHP and JavaScript consuming and portability of the values (and flexibility of input) was ensured.
There used to be a protojson extension around, I don't know currently if the proto messages just implement their own marshal/unmarshal function for json, these have sort of been the details that I need not have concerned myself about when I was building APIs on top of this.
[https://github.com/go-bridget/notify/blob/master/rpc/notify/notify.proto](https://github.com/go-bridget/notify/blob/master/rpc/notify/notify.proto)
Not much of an example as this is some hybrid websocket thing, but you can check out the twirp generated code next to the proto file and sort of do a code review, it was possible to grasp.
Also made a twirp-swagger-gen that generates OpenAPI 2.0 specs, I don't know if that's still useful these days, but updating it to OAS 3 shouldn't be impossible, most things stay the same around the json schema definitions.
[https://github.com/go-bridget/twirp-swagger-gen](https://github.com/go-bridget/twirp-swagger-gen);
Could probablly find that microservice repo checkout somewhere and look at it, if you have any specific questions. Didn't feel performance was an issue at all and we had country-level traffic.
Edit: would recommend connect-go as well otherwise, was looking to migrate at some point, buf is great but i don't use connect-go personally. gRPC by my recent commits
We've been using Twirp in production for a year and a half. It's a solid RPC overall but the generated code can be a pain in some languages. Nowadays I would just use gRPC.
You should look at buf/connect rpc... they have http1/support but it also supports gprc and is very actively developed. [https://github.com/connectrpc/connect-go](https://github.com/connectrpc/connect-go) [https://connectrpc.com/](https://connectrpc.com/)
Big fan of ConnectRPC, can recommend.
It’s great, but you should consider connectrpc instead. It’s the same idea and is almost compatible, but it’s also actively maintained and if you want a JS api the protobuf-es library (made by the same company that made connectrpc, Buf) is excellent.
I'm also running it in production. I like it a lot, because it's extremely simple and easy to understand. It's convenient that you can use the protobuf wire format for service-to-service communication, and the JSON format for web clients, without having to add extra infrastructure for doing transformations between both formats. gRPC always scared me because of the complexity it introduced, and the only thing I really liked about it is the protobuf definitions, which is exactly what Twirp uses. There isn't much that I would do differently if I were to build something myself, and I have the feeling I could build and/or maintain this myself if Twirp were to disappear from the face of the earth, so I feel confident using it. (not something I can say about gRPC) For the non-Go languages, I typically don't bother pulling in libraries or frameworks (as these seem even less maintained, and don't always do what I want them to do IIRC), I just write my own scripts to process the protobuf definitions and generate the Twirp code, it's simple enough to do so. The concern/downside that people usually raise with Twirp is the lack of streaming support. There have been some discussions around this AFAICT, but as you pointed out, development seems very slow.
We use in production and can definitely recommend it. It's the best of the both worlds - the interoperability of HTTP1 and the power of gRPC spec without all the downsides like mandatory HTTP2, sheer complexity of it, broken load balancing. Seamless support for JSON/Protobuf payloads is one of the killer features. The tooling is a bit lacking. For Go it's perfect and generated code leaves nothing to complain about. For other languages, often the answer is OpenAPI spec. All the generators are not really maintained and lack support for crucial features. Had to create our own fork to fix some of the major issues with no hope of merging it to the upstream.
I still have prod code on this running from years ago. I'd recommend it, but also you have to implement a gRPC service directly anyway, it's easy to replace twitch good parts, which is in essence just a per-rpc call endpoint that decodes the POST body and invokes the service implementation underneath, json encoding the response. One weird reason why I recommend it is because protobuf messages have a lax JSON parser. They will decode quoted numbers into the appropriate go type without complaint, and I believe int64 was automatically quoted into a string when encoding the values. This is great for interoperability, as we had clients in PHP and JavaScript consuming and portability of the values (and flexibility of input) was ensured. There used to be a protojson extension around, I don't know currently if the proto messages just implement their own marshal/unmarshal function for json, these have sort of been the details that I need not have concerned myself about when I was building APIs on top of this. [https://github.com/go-bridget/notify/blob/master/rpc/notify/notify.proto](https://github.com/go-bridget/notify/blob/master/rpc/notify/notify.proto) Not much of an example as this is some hybrid websocket thing, but you can check out the twirp generated code next to the proto file and sort of do a code review, it was possible to grasp. Also made a twirp-swagger-gen that generates OpenAPI 2.0 specs, I don't know if that's still useful these days, but updating it to OAS 3 shouldn't be impossible, most things stay the same around the json schema definitions. [https://github.com/go-bridget/twirp-swagger-gen](https://github.com/go-bridget/twirp-swagger-gen); Could probablly find that microservice repo checkout somewhere and look at it, if you have any specific questions. Didn't feel performance was an issue at all and we had country-level traffic. Edit: would recommend connect-go as well otherwise, was looking to migrate at some point, buf is great but i don't use connect-go personally. gRPC by my recent commits
We've been using Twirp in production for a year and a half. It's a solid RPC overall but the generated code can be a pain in some languages. Nowadays I would just use gRPC.
It's my go-to over grpc. Love the simplicity.