REST or GraphQL? A Simple Answer
medium.com
medium.com
While I appreciate your argument and your intention, you don't make your case strongly enough, nor do you make it all rigorously enough, and most importantly you lean too heavily into a false binary as rhetorical device (we all know it is a false binary, by playing this game in your headline you are deliberately not answering the question you proposed).
First of all, the way that I see it, you invite the immediate question of "which RPC?" as there are many conflicting standards (and it does not help the discussion that the one you suggest isn't even a well recognized cross-platform standard such as gRPC or SOAP). So rather than pick between two directly competing standards as your headline suggests, you simply open Pandora's Box with "but there's a third option, and it's full of more options".
Beyond that though, one particular thing to point out is that both REST and GraphQL themselves are responses to RPC, and you neither take that into account nor address it:
1. Much early REST advocacy was an intentional rejection of the growing influence of RPC standards like SOAP (and its extended WS-* family).
2. GraphQL itself is heavily RPC influenced (in mutators especially, but it drives several parts of the language/engines), while trying to also avoid the mistakes of things like SOAP and some of the over-correction away from RPC of things like REST. It tries to hit a sweet spot between REST, RPC, and query language. Whether you think it succeeds or not as an RPC language (or hitting that sweet spot anywhere near close to your own heart), it fits the basic definition of an RPC language, and so your "third option" isn't even an exclusive-or, but a complicated overlap in the Venn diagram.
Anyway, I hope the criticism helps you explore your arguments further, and maybe helps push you to be a better writer.
My goal is to rise awareness that RPC should be the default choice when creating an API.
> REST and GraphQL themselves are responses to RPC, and you neither take that into account nor address it
REST was introduced in 2000, jQuery in 2006, the iPhone in 2007, React in 2013. My point: API had different goals when REST was introduced. In 2000, we didn't have mobile frontends nor dynamic browser frontends. There was little need for frontend-backend communication.
For an API that was meant to be consumed by third-party developers in 2000, REST was an excellent choice.
But, today, to communicate between a backend and a modern frontend, RPC is most of the time the better choice.
> you simply open Pandora's Box with "but there's a third option, and it's full of more options".
I disagree with that.
It's pretty clear:
- For an API between a Node.js backend and a browser frontend, Wildcard API offers a super simple RPC solution.
- For an API between a python/go/java/... backend and a browser/mobile frontend, create custom JSON server endpoints.
- For communicating between backend services, use gRPC.
I don't see many use cases where you'd need something beyond what I just mentioned. Maybe I'm missing on some important use cases?
I'd recommend against using JSON-RPC. (Using JSON-RPC requires you to implement too much non-standard stuff that will only exist within your company). I'd recommend gRPC instead.
The problem with RPC is that people are not familiar with it. It may seem "complicated" at first because people are not proficient with it. But, and that's what I'm trying to show with my Wildcard API project, RPC is actually super simple. Fundamentally, RPC is simply about defining a function in one env and calling it remotely from a different env, that's super simple.
That said, RPC is no good if your API is meant to be consumed by third-party developers. In that case you need to create a generic API with REST or GraphQL. (Although my prediction is that RPC will eventually also become a viable option for third-party devS in the future... basically by introducing a schema to RPC... but that's a whole different topic.)
Your response seems to indicate to me that you are not familiar with it to know its downsides or long, complicated history. RPC as a concept dates back to the beginnings of inter-process communication in the 60s and has an equally long history in network communications.
There's always been a pendulum swinging between tightly coupled RPC standards and loosely coupled data interchange standards (or one made from the other in all sorts of combinations). It's a fact of software development life since essentially the dawn of the industry.
It's the "tightly coupled" part of RPC that caused REST to be evangelized over SOAP, an XML-based RPC standard. It's the "tightly coupled" part that GraphQL tries to balance in its looser query syntax embedded in its RPC dialect.
There's nothing wrong with "tightly coupled", just know that it is a trade off. You almost seem to realize it in your realizations that RPC is complicated when working with third party developers. You are almost close to the enlightenment of why REST became so popular and SOAP faded away.
> basically by introducing a schema to RPC
COM has IDL. SOAP has WSDL. gRPC has proto files. GraphQL has its schema language. These wheels have been invented many times, it might be useful to research some of them if you wish to further discuss RPC.
ETA: Which is not meant to discourage you, I want to encourage you to learn more. It's not wrong that you don't know these things, it's an opportunity, and I really do hope you explore it.
The whole point of a schema is to have a generic API. Whereas with RPC and any other schemaless approach such as SOAP, you are essentially building a custom API that is only usable for your clients.
That's precisely the reason why RPC is not usable to create an API that is meant to be used by third party devS.
Third party devS need a generic API. That's the point.
Also, a generic API decouples whereas a custom API tightly couples.
WSDL is actually only describing the API - it's not defining a schema. So SOAP is not and was never usable for a third-parties. Same for gRPC's proto files.
I do appreciate your encouragement but I don't see where I concretely am missing out on something important. You simply state that I'm lacking knowledge without ever concretely showing the flaws of Wildcard.
> You are almost close to the enlightenment
That's just not very helpful. You are telling me that I'm missing an important point without telling what it is I'm missing.
I'd love to be shown wrong. You would for sure save me a lot of effort if you'd pin point my lack of knowledge.
For a Node.js backend and a browser frontend, what exactly is the problem with Wildcard API? (https://github.com/reframejs/wildcard-api). As long as you don't have third-parties consuming your API, I'd say that Wildcard is superior to GraphQL and REST >95% of the time. Especially when using Wildcard with TypeScript.
> There's always been a pendulum swinging between tightly coupled RPC standards and loosely coupled data interchange standards (or one made from the other in all sorts of combinations). It's a fact of software development life since essentially the dawn of the industry.
Interesting. I've not been a programmer long enough to know all that :-).
Thanks for you reply, I truly appreciate it.