[cshenton]

gRPC generates rpc server and client stubs based off a protocol buffer definition. Saying it's a replacement for REST makes little sense since it's possible to define a REST API within it. It's also possible to write a totally not RESTful API in a modern http api framework.

In fact that's what Google's API design guide does. Encourages RESTful API design then describes how to implement them using proto and gRPC.

The more interesting tradeoffs are proto vs json or other and how this restricts message patterns to request/response (rather than pub/sub or push/pull)

[mvitorino]

Interesting! When I first looked at gRPC I missed the option(google.api.http). Are you aware of the reason why REST mapped gRPC is not possible in GAE (http 1 only on the server end of our code)?

[mwitkow]

There's actually a stand-alone proxy that translates the REST mappings of `google.api.http` into gRPC requests. It relies on code-generation: https://github.com/grpc-ecosystem/grpc-gateway

This has been the way we've been shipping our REST services until now, but the need to recompile the proxy was a major hinderence to our development speed. Hence gRPC-Web implementation.

[cshenton]

Probably because it's pretty bleeding edge.

Google Cloud Endpoints, which released earlier in the year, allows you to write a gRPC server, and offers the HTTP proxy as part of the service.

The ecosystem still isn't quite there though. It could be easier to just write a thin webserver that just points at services over tcp (using something like ZeroMQ) rather than writing a service with gRPC from the ground up.