[mvitorino]

I think I like gRPC, but have several reservations regarding replacing REST with it. REST web services often return multiple mime formats, not just pure structured data. Some services return images, others return HTML, and then you also have cache... Maybe I just don't know enough about gRPC, but I can already imagine many people passing images around as byte arrays inside protocol buffers and when we look back, we have reinvented SOAP, which reinvented Corba.

[mwitkow]

Totally agreed. There are cases where you basically want to deal with well structured web resources: HTML, images etc. For these, HTTP is a perfect fit.

What we're replacing with gRPC is usage of REST (URL-encoded resources) + JSON for application APIs, not really Web-resources.

What we found is that gRPC is really good at capturing both a resource-oriented API (we use similar conventions to Google's excellent API Design handbook https://cloud.google.com/apis/design/resource_names#resource...) and imperative ones. The major difference we no longer have a weird POST method with `/books/do_recalculation` that breaks the RESTfulness of the API.

[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.