5 ms·
What RPC mechanisms, in your opinion, are the most ergonomic and why? (I have been offering REST’ish and gRPC in software I write for many years now. With the
by bborud 1y ago
What RPC mechanisms, in your opinion, are the most ergonomic and why?
(I have been offering REST’ish and gRPC in software I write for many years now. With the REST’ish api generated from the gRPC APIs. I’m leaning towards dropping REST and only offering gRPC. Mostly because the generated clients are so ugly)
- cyberax 1y agoJust use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid. REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.
- PaulHoule 1y agoPeople get stuff done despite at all that.
- cyberax 1y agoI mean... I used to get stuff done with CORBA and DCOM. It's the question of long-term consequences for supportability and product evolution. Will the next person supporting the API know all the hidden gotchas?
- jerf 1y agoI'd agree with your great-grandparent post... people get stuff done because of that. There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards that sloppyREST has casually dispatched (pun fully intended) in the real world. After some 30+ years of highly prescriptive RPC mechanisms, at some point it becomes time to stop waiting for those things to unseat "sloppy" mechanisms and it's time to simply take it as a brute fact and start examining why that's the case. Fortunately, in 2025, if you have a use case for such a system, and there are many many such valid use cases, you have a number of solid options to choose from. Fortunately sloppyREST hasn't truly killed them. But the fact that it empirically dominates it in the wild even so is now a fact older than many people reading this, and bears examination in that light rather than casual dismissals. It's easy to list the negatives, but there must be some positives that make it so popular with so many.
- cyberax 1y ago> There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards Care to list them? REST mania started around early 2000-s, and at that time there was only CORBA available as a cross-language portable RPC. Microsoft had DCOM. And that was it. There was almost nothing else. It was so bad that ZeroC priced their ICE suite based on a PERCENTAGE OF GROSS SALES: https://web.archive.org/web/20040603094344/http://www.zeroc.com/licensing.html https://web.archive.org/web/20040603094344/http://www.zeroc.... Their ICE suite was basically an RPC with a human-designed IDL and non-crazy bindings for C/C++/Java. Then the situation got WORSE when SOAP came. At this point, anything, literally anything, that didn't involve XML was greeted with enthusiasm.
- motorest 1y ago> Care to list them? From the top of my head, OData. https://www.odata.org/ https://www.odata.org/
- cyberax 1y agoThis is a recent project. REST happened basically in the environment where your choices were CORBA, DCOM, SOAP and other such monstrosities. Of course, REST won handily. We're not in this environment anymore, thankfully, and REST now is getting some well-deserved scrutiny.
- motorest 1y ago> This is a recent project. OData officially started out in 2007. Roy Fielding's thesis was published in 2000.
- cyberax 1y agoSo it was a contemporary of Protobufs, Cap’n Proto, and other frameworks. Facebook had Thrift, Amazon had Coral, and so on. They appeared almost simultaneously, for the very same reason: REST by itself is too vague and unreliable.
- bborud 1y agoPeople got things done with flint axes too. It isn't really a useful argument.
- theamk 1y agoJust not in C++ code. gprc has a bajillon dependencies, and upgrades are a major pain. If you have a dedicated build team and they are willing to support this - sure, go ahead and use it. But if you have multiple targets, or unusual compilers, or don't enjoy working with build systems, stay away from complex stuff. Sure, REST may need some manual scaffolding, but no matter what your target is, there is a very good chance it has JSON and HTTP libs.
- rplnt 1y agoYou can mess up grpc just as much. Errors are a good place to start.
- bborud 1y agoCould you elaborate?
- cyberax 1y agoWait until you hear about errors in REST...
- motorest 1y agoWhat about errors in REST? It's HTTP status codes, and implementations are free to pick whatever approach they want for response documents. Some frameworks default to using Problem Details responses, but no one forces that.
- cyberax 1y agoYou can't rely on them because they can come from middleboxes (load balancers, proxies, captive portals in hotels, etc.). So you can't rely on having structured errors for common codes such as 401/403/404, it's very typical to get unstructured text in payloads for such errors. Not a few REST bindings just fail with unhelpful serialization exceptions in such cases.
- paulddraper 1y agoThe critical problem with gRPC is that it uses protocol buffers. Which are...terrible. Example: structured schema, but no way to require fields.
- cyberax 1y agoWith Protobuf this is a conscious decision to avoid back-compat issues. I'm not sure if I like it.
- PaulHoule 1y agoThat's exactly how these systems fail in the marketplace. You make one decision that's good for, say, 50% of cases but disqualifying for 50% of cases and you lose 50% of the market. Make 5 decisions like that and you lost 31/32 of the market.
- nosefrog 1y agoInfra teams like it, app devs don't like it.
- therealdrag0 1y agoWell the competition is REST which doesn’t have a schema or required fields, so not much of a problem.
- motorest 1y ago> Well the competition is REST which doesn’t have a schema or required fields, so not much of a problem. A vague architecture style is not competition to a concrete framework. At best, you're claiming that the competition to gRPC is rolling your own ad-hoc RPC implementation. What I expect to happen now is an epiphany. Why do most developers look at tools like gRPC and still decide it's a far better option to roll their own HTTP-based RPC interface? I mean, it's a rational choice for most. Think about that for a moment.
- motorest 1y ago> REST is just too "floppy", there are too many ways to do things. I think there is some degree of confusion in your reply. You're trying to compare a framework with an architecture style. It's like comparing, say, OData with rpc-over-HTTP.
- bborud 1y agoIn practical reality the distinction is mostly, if not completely, without a meaningful difference. The words "practical" and "meaningful" being key. The distinction only has relevance if one engages in pedantry. Or possibly some form of academic self-pleasuring. I'm aware this is an unappealingly rustic reality, but it is nonetheless the reality experienced by most. Besides in the practical world we are able to observe, REST isn't even an architectural style: it is several architectural styles multiplied by every possible permutation of how you address a dozen or more different concerns. Necessitating disambiguation whenever you talk about it. First to state the obvious, that it isn't really what Fielding described, then on to communicating what vector describes your particular permutation of choices. It's okay. We don't need to pretend any of us care about REST beyond as an interesting academic exercise.
- bborud 1y agoI don't see the point of ConnectRPC.