Conceptually, gRPC gives much more server predictability at the expense of client flexibility whereas GraphQL optimizes for the opposite. Sure you can have gRPC calls with lots of client options or GraphQL servers with lots of restrictions. There are security/performance concerns around client flexibility and time-to-market concerns around server-side rigidity. I prefer the latter in most cases and don't expose GraphQL on the public web (again, I know GraphQL can be secured and made more predictable/inflexible).
As I understand it, they are essentially very different technologies. GraphQL focuses on providing a DSL for requesting subsets of data from a web endpoint that "talks" JSON. gRPC-Web is just a wrapper around gRPC so that you can expose your RPC endpoints in a front-end friendly manner.
In other words: GraphQL is akin to SQL, while gRPC-Web would be closer to a serialization/exchange format like XML/SOAP.
gRPC is lightweight, highly performant, difficult to debug, difficult to detect breaking schema changes, lots of magic going on to learn compared to REST or GraphQL.
GraphQL is much heavier, easier to test and debug and has some performance optimisations like data loader and is better for multiple clients to consume. I’d say it’s easier to manage schema changes but it’s probably not empirical. I guess huge overheads by comparison to gRPC but I’m guessing data over the wire is a much larger piece of the pie.
Personally think GraphQL is far superior for web clients and I think gRPC for services in general can be a pretty large overhead for most teams... at least initially you are going to get things done much faster with restful services.
Because the schema is based on a numbered position rather than a field name. This means you need to never rename positions - if you want to deprecate fields you just loose the numbering. Numbers 0-15 use less space in the message than others for example.
I was thinking the same. I’ve often seen GraphQL contrasted with just REST, and likewise the OP talks about gRPC-Web vs just REST.
I performed a web search and found some articles comparing the three together, the first among which [1] I will proceed to summarize.
This article gives an overview of how GraphQL, REST and gRPC work and then provides some opinions on which situations each of them are most suitable in, and also includes examples of companies and services using/implementing each of the three (as well as additionally doing the same for Webhooks).
Note that it speaks of gRPC, not gRPC-Web, so you have to keep in mind that when they talk about gRPC some of the things they are saying do not apply directly for gRPC-Web. I think however that this article is still relevant if one takes into account the details about gRPC-Web from the OP.
The presentation of each of the four is consistent with what I know about REST and GraphQL from having read about them and having worked with REST (both on the consumer and as provider sides) as well as having explored GraphQL a bit, so I am inclined to believe that they know what they are talking about.
Near the end of the article they offer the following opinions for which is appropriate when:
> REST: A stateless architecture for data transfer that is dependent on hypermedia. REST can tie together a wide range of resources that might be requested in a variety of formats for different purposes. REST is fundamentally concerned with stateless resource management, so it’s best used in such situations. Systems requiring rapid iteration and standardized HTTP verbiage will find REST best suited for their purposes.
> gRPC: A nimble and lightweight system for requesting data. gRPC, on the other hand, is best used when a system requires a set amount of data or processing routinely, and in which the requester is either low power or resource-jealous. The IoT is a great example of this.
> GraphQL: An approach wherein the user defines the expected data and format of that data. GraphQL is from Facebook, and that pedigree demonstrates its use case well — situations in which the requester needs the data in a specific format for a specific use. In those cases, those data formats and the relations between them are vitally important, and no other solution provides the same level of interconnected provision of data.
> Webhooks: Data updates to be served automatically, rather than requested. Finally, Webhooks are best used when the API in question primarily updates clients. While such APIs can also have other functions, even RESTful ones, the primary use of a Webhook microservice should be to update clients and provide updated, provisioned data upon the creation of the new, updated resource.
> Choosing amongst these specific options is really a matter of aligning your business functions with the appropriate approach, and ensuring that the systems in place respond within the given parameters.
I found the article to be well written, thought out, and to answer the question I had in my mind. The whole thing is worth a read.
