Twirp: A new RPC framework for Go

#1

Post by spenczar5 » Tue, Jan 16, 2018, 8:25 PM UTC

Twirp: A new RPC framework for Go
blog.twitch.tv

Re: Twirp: A new RPC framework for Go

#2

Post by rguzman » Tue, Jan 16, 2018, 8:52 PM UTC

this looks really sweet. i've never understood why gRPC limits itself to protobufs only when the protobufs have a canonical json representation. i'm glad that twirp is fixing that piece.

Re: Twirp: A new RPC framework for Go

#3

Post by tothemario » Tue, Jan 16, 2018, 9:01 PM UTC

awesome! a lot easier to integrate than gRPC. It will be way more useful after other languages are supported

Re: Twirp: A new RPC framework for Go

#4

Post by spenczar5 » Tue, Jan 16, 2018, 9:01 PM UTC

rguzman wrote: post #2

this looks really sweet. i've never understood why gRPC limits itself to protobufs only when the protobufs have a canonical json representation. i'm glad that twirp is fixing that piece.

Yes! In theory, gRPC has a way to pick custom serializers... but in practice, they are pretty clumsy to use and don't seem very well supported. There's a lot more benefit when you can guarantee that all servers will support JSON, too.

Re: Twirp: A new RPC framework for Go

#5

Post by cyrusaf » Tue, Jan 16, 2018, 9:01 PM UTC

rguzman wrote: post #2

this looks really sweet. i've never understood why gRPC limits itself to protobufs only when the protobufs have a canonical json representation. i'm glad that twirp is fixing that piece.

HTTP 1.1 + json support for twirp opens up a lot of doors too. It's easy for the browser to natively hit a twirp service without the need for large packages such as https://github.com/improbable-eng/grpc-web.

Re: Twirp: A new RPC framework for Go

#6

Post by gipp » Tue, Jan 16, 2018, 9:56 PM UTC

rguzman wrote: post #2

this looks really sweet. i've never understood why gRPC limits itself to protobufs only when the protobufs have a canonical json representation. i'm glad that twirp is fixing that piece.

On GCP, Cloud Endpoints proxies will transparently translate back and forth between protobufs and the canonical JSON, allowing either representation to be used. So if you're on GCP and don't care about vendor lock-in, that's a solution.

Re: Twirp: A new RPC framework for Go

#7

Post by ghayes » Tue, Jan 16, 2018, 9:57 PM UTC

I wrote a similar library to this called Hyperbuffs[0] in Elixir. The goal of the project is to document and build your endpoints using protobufs, but to allow the caller to choose either protobuf or JSON encoding for content and accept types.

[0] https://github.com/hayesgm/hyperbuffs

Re: Twirp: A new RPC framework for Go

#8

Post by sliken » Tue, Jan 16, 2018, 10:04 PM UTC

Looks nice. Can anyone comment on how auth works with Twirp? I was trying to get GRPC working to authenticate with unsigned ssl certs (much like using SSH) and was rather disappointed how awkward it was. Basically two completely different methods requiring hiding session ID in two unrelated places just to allow a SSL cert to control authentication.

Anyone done similar with Twirp?

Re: Twirp: A new RPC framework for Go

#9

Post by buckhx » Tue, Jan 16, 2018, 10:09 PM UTC

gipp wrote: post #6

rguzman wrote: post #2

this looks really sweet. i've never understood why gRPC limits itself to protobufs only when the protobufs have a canonical json representation. i'm glad that twirp is fixing that piece.

On GCP, Cloud Endpoints proxies will transparently translate back and forth between protobufs and the canonical JSON, allowing either representation to be used. So if you're on GCP and don't care about vendor lock-in, that's a solution.

There is also the grpc-gateway project for JSON transcoding https://github.com/grpc-ecosystem/grpc-gateway

Re: Twirp: A new RPC framework for Go

#10

Post by spenczar5 » Tue, Jan 16, 2018, 10:13 PM UTC

sliken wrote: post #8

Looks nice. Can anyone comment on how auth works with Twirp? I was trying to get GRPC working to authenticate with unsigned ssl certs (much like using SSH) and was rather disappointed how awkward it was. Basically two completely different methods requiring hiding session ID in two unrelated places just to allow a SSL cert to control authentication. Anyone done similar with Twirp?

Yep, you can do this pretty easily because Twirp's generated objects plug in nicely to the normal `net/http` tools. The server is a `http.Handler`, and the client constructor takes a `http.Client`. So if you're familiar with how to use SSL certs for authentication with a vanilla Go HTTP client and server, Twirp would work in exactly the same way.

When you create a Twirp server, you get a `net/http.Handler`. You can mount it on a `http.Server` with its `TLSConfig` field set to the right policy.

The client constructor similarly takes a `*net/http.Client`. You could provide a Client that uses a `http.Transport` with its `TLSClientConfig` field set to something using the right value (like in https://gist.github.com/michaljemala/d6f4e01c4834bf47a9c4, say).