
REST or GraphQL? A Simple Answer - brillout
https://medium.com/@brillout/rest-or-graphql-a-simple-answer-fbd8dd2b0486
======
brillout
Author here. Let me know if you have questions.

~~~
WorldMaker
It's not really an answer, though, is it?

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.

~~~
brillout
You're right, it's not an answer.

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.)

~~~
WorldMaker
> The problem with RPC is that people are not familiar with it.

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.

~~~
brillout
The most fundamental difference between RPC and REST/GraphQL is that RPC is
schemaless whereas a RESTful or GraphQL API has a schema.

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](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.

