[alfalfasprout]

Having just looked into this recently, I can also safely say that moving to REST HTTP/2 on its own already provides a significant speed benefit. Closing the gap to GRPC (or even substantially beating it) is possible by switching to a fast serialization format (eg; flatbuffers, msgpack, capnproto).

While GRPC has its place it also comes with headaches like pretty lousy generated interfaces, horrible debuggability, and unpredictable scaling.

[gravypod]

Came here to say something similar. The interfaces and tooling around gRPC in the public sphere is pretty bad. If you maintain a code base with multiple languages and want to compile gRPC for it you can choose between:

1. Having a complex build system that is aware of gRPC

2. Massive migraines

Unfortunately build systems integrations, IDE integrations, and generated code is unanimously awful for gRPC.

Every company I've seen use grpc has unfortunately adopted the practice of basically manually running protoc and committing the generated code into repo - sometimes modifying the code manually to make it import successfully (Python).

I hope Bazel evolves into a state where it's usable by the average engineer and has first class support for gRPC.

[pjc50]

Not really - we have a product that builds C#/Java/Python/C++ versions of a grpc API, and we just do it by invoking 'protoc' at the relevant point?

[treve]

It's kinda weird to compare REST to RPC protocols though. It's a completely different paradigm. Maybe you're just building a HTTP API without the REST part? (JSON-RPC is a thing)

[e12e]

Actually traditional RPC is one of the paradigms considered in Fielding's thesis coining the term. I don't know why people seem to insist there are no other models than REST if you happen to have browser on one end. Sending Javascript down the asynchronous pipe designed for XML was at the very least a step back away from REST toward something more traditional (moving code, not data).

Section 3.5 "Moving code styles" (and 3.4 for RPC):

https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...

[hhas01]

Indeed; true REST interactions tend to be quite coarse-grained; essentially requests to update a remote state machine to match the described state. Most of what gets called “REST” isn’t; it’s just ad-hoc RPC sent over HTTP with arguments encoded as XML/JSON, which is probably what parent really means. Take casual claims of RESTfulness with the requisite bucket of salt. (If the term “REST API” is used, you can toss the bucket entirely as the very phrase is itself an oxymoron.)

[pdpi]

HTTP is a reasonable enough transport layer for RPC frameworks (e.g. gRPC is built on top of HTTP/2)