7 ms·
Why create gRPC if you can run REST over HTTP/2, and there is websockets?
If you say communication, then isn't websocket already there for that? gRPC honestly looks like it could have been just websocket with library enforcing data contracts.
I'm confused, over actual benefit here. It seems it is being forced with promise of benefits that already exists..
- skybrian 8y agogRPC isn't really designed with web programming in mind at all; it's primarily used for server-side languages. (For example, it supports 64 bit ints.)
- dozzie 8y agoAre you really asking why not replace a well-defined RPC protocol that has properly specified data serialization and error signaling with a randomly slapped together half of an RPC protocol?
- jsiepkes 8y agoThis a million times. gRPC / Protobuf allow you to neatly design your messages in a backwards and forewards compatible way. This helps you make changes to your service after your application has been deployed. Why on earth would you try to reinvent something like that?
- RantyDave 8y agoIndeed why. Yet we have near-countless 'standardised' ways of marshalling parameters - this is just the one that has the best marketing.
- gonyea 8y agoDriving the highest traffic sites in the world, and the backend systems that power them for 2 decades, is just marketing? Weird.
- seangrogg 8y agoWhich company does this? While my workplace has used many of these components individually I can't think of a single team that actually uses gRPC off-the-cuff. Nor can I think of anyone that's even mentioned migrating to it. Disclaimer: I work at Google.
- exikyut 8y agoWell, I'll concede the point, but mass adoption doesn't imply idealness. See also, JavaScript.
- techsin101 8y agoI guess what I am asking is why was it not build on top of websocket instead of http/2
- madmax96 8y agoREST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. The point of REST is to totally and generally describe the semantics of a networked application's state transitions and is protocol-agnostic. GRPC exists to invoke remote functions. Why use REST? That's well-documented in Fielding's thesis [1]. Use the appropriate architecture for the appropriate task. [1]https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...
- dozzie 8y ago> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. Though whenever somebody talks about REST API, they mean "almost RPC with underspecified semantics", not a hypertext driven way of fetching the data.
- madmax96 8y agoThe web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. RESTful architecture (e.g. the architecture that lets you use one client to consume literally billions of applications and provides the mechanisms for you to move between them totally transparently) works very well for building a specific kind of application. Now, most of us are not building the web, and so we have other constraints that are often times more important. You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. The way to escape this game of buzzword bingo is to introduce nuance to our conversations about architectures, not by changing the buzzword.
- dozzie 8y ago>>> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. >> Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. > The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. Quite an apt observation: as consumed by humans. But we're comparing something that's commonly called "REST" to an RPC protocol, and RPC protocols are quite clearly intended for computers, not humans. This something that is commonly called "REST", even if you argue it's called incorrectly, is very far from the famous PhD thesis. > You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. OK. If you say that I'm wrong about implementations, show me where's a production system where the computer is the primary consumer (i.e. not merely a terminal for displaying something to a human operator, and not a second-class citizen like web crawling bots) and the system is RESTful in the original meaning. I can't think of even a single one. Note, however, that WWW cannot be considered such an implementation, because its primary consumer is human, not computer, and I remind you once again: we're talking under this post about unsupervised computer-to-computer communication, where human operator is a rare guest. > A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. Much less productive is trying to pull an unrelated idea (the original meaning of "REST") into discussion about machine-to-machine communication, especially that the original term was created post factum to describe WWW's architecture (already existing back then!) and wasn't used for pretty much anything else, so introducing the term hasn't advanced nor produced anything.
- RantyDave 8y agoIt's almost exactly like the difference between static and dynamic languages (with gRPC being the static option). It's an order of magnitude faster and (like you said) to a certain extent enforces compliance with an API. Brittle, though.
- techsin101 8y agoi get it's faster over http, but i haven't seen much when it comes to websockets.
- Matthias247 8y agoApart from the fact that you can do bidirectional data transfers with both, they are quite different: - grpc and HTTP/2 have a fixed paradigm (RPC plus streaming), whereas websockets are lower level and just describe how packets are transferred in each direction. For PRC you have to build something on top (e.g. following the WAMP conventions). - grpc on top of HTTP/2 features per stream flow. Doing something like transferring a 4GB file on top of websockets without loading everything in memory is not as easy, since flow control is somewhere between basic and missing there. - They have different ordering guarantees. grpc doesn't gurantee ordering between different requests, websockets guarantees it between messages. - grpc comes with an interface definition language (protobuf) and code generators, which makes it much easier to build interoperable and backwards compatible services. - gprc is proxyable per request, since each stream contains all relevant information (endpoint, parameters, auth, etc.). In total grpc and HTTP/2 are more stateless than a websocket connection, which could contain any kind of data. - websockets work out of the box in browsers. The original grpc specification not, due to relying on features that are not exposed in browser APIs.
- techsin101 8y agoyou can't proxy websocket? i agree having contract for apis make it easier, but that could have been implemented over websocket instead of http2 just wondering? guaranteeing order, isn't that a good thing? transferring 4gb file over websocket, hmm... i actually never looked into it so i'll take the word here. .... I guess my overall question is why not gRPC over websocket instead of Http/2
- Matthias247 8y ago> you can't proxy websocket? You can proxy the whole connection. But not a single request/stream inside it, since there is no notion of such a thing in websockets. Compared to that grpc is basically built on standard HTTP/2 requests, where the method is denoted in the path. So you can use a standard HTTP/2 capable proxy or load balancer to route requests based on the method.
- notheguyouthink 8y ago
- segmondy 8y agoYou can build gRPC and get REST for free. https://github.com/grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grpc-gateway
- notheguyouthink 8y agoHell, I don't know how production-friendly it is, but it sounds like clay[1] will even give you http-json endpoints without setting up a 2nd server. [1]: https://github.com/utrack/clay https://github.com/utrack/clay edit: If you're using Go, of course.