
Why I believe GraphQL will come to replace REST - martijnwalraven
https://dev.to/reactiveconf/why-i-believe-graphql-will-come-to-replace-rest
======
riskable
Meh, everything in GraphQL can be defined as JSON. I fail to see the benefit
(over just using JSON).

I definitely agree with the author's assertions as to how and why REST sucks.
I'd also add that a big reason why REST sucks is that it is completely
orthogonal to streaming. You're supposed to GET or POST never both at the same
time.

Your web app has grown astronomically and the number of GET and POST calls are
creating a _massive_ overhead ("maybe we _shouldn 't_ have put so much state
data in cookies."). So everyone gets together and decides WebSockets are a
good solution... Because all your stuff was made with REST in mind you are now
tasked with basically writing _an entirely new API_ from scratch whereas if
you used something like JSON-RPC you could just send the _same exact API
calls_ over the WebSocket and call it a day.

~~~
jack9
> You're supposed to GET or POST never both at the same time.

The standard says you can. The simplest way to add pagination is to POST your
data with GET values overriding. I see no reason to use PUT or DELETE at all.

------
niftich
The pendulum swings back the other way. One of the advantages of (proper) REST
is precisely that the returning payload is a server-defined, well-specced
mediatype, so you know that responses always look the same way. GraphQL -- and
literally any other client-driven query language, including SQL -- instead you
ask for specific data items and have to case-by-case write the handling logic
right after your request completes.

It's a trade-off, like any other. As another commenter said, this battle was
fought many years ago with SQL, where it began to be considered good practice
to formalize the APIs with stored procedures or abstract away from the backend
tables by restricted-column views, instead of just accepting arbitrary queries
against the raw table.

------
pedalpete
I'm in the process of re-writing an API and was looking at GraphQL just
yesterday.

I'm trying to figure out if there is any environment/situation where GraphQL
is not a good solution?

I'm moving everything to a lambda/microservice architecture, and it seems now
I would have a single service managing all the api calls rather than using
something like API Gateway to route to the correct lambda.

Any thoughts on this?

------
jack9
I can't think of one (other than FB) where this is preferable over some form
of REST (just go back to calling it HTTP actions or HTTP). Tying services
together makes for more problems (as coupling often does), not less.

The very first point is either disingenuous or outright ignorant. "Gone is the
mess of relying on an ever expanding set of predefined REST endpoints", moving
that to the server logic is not "better". The number of code paths hasn't been
reduced, just placed deeper in the execution path. How many months does it
take the average developer to learn deep paths are worse than shallow ones?

Next, your result caching needs to be inserted in other places. As result
caching is no longer at a predictable location AND mixed with other cached
values (if you just keep caching everything at the request level) which makes
splitting work more difficult.

Most of the sentences are restatements or vague assertions, until you get to
the "type system". This part is where the "idea" stops seeming all that
original, since webservices (in aggregate) define an application query system.
You can always define what your APIs return so the "asking for the results you
want" as if it's new, is a just a misunderstanding of how webservices work
NOW.

Finally we get to the actual selling point. Ad-hoc results. Typically, if your
using services, you know the common operations that need to be combined and
probably, so do the vendors (sometimes that's yourself). Popping out a new
endpoint for combined data (see:
[https://client.cdn77.com/support/api/version/2.0/data#Purge](https://client.cdn77.com/support/api/version/2.0/data#Purge)
All vs Purge) or adding a GraphQL-esque query param is not all that unusual,
except in edge cases where you have a giant graph database. This is not the
common case.

~~~
justinclift
The GitHub post about GraphQL indicates it's more efficient (on the server)
when people use GraphQL instead of REST.

To me - looking to provide API access from a new project soon - that sounds
like a good potential win.

------
Someone
On the one hand, when I read the open sourcing announcement, I found it
enticing, too.

On the other hand, we have had this kind of thing for decades in the form of
SQL. There, it is considered best practice to restrict the API by requiring
callers to exclusively use stored procedures. Reasons are that they make it
easier for the engine to optimize query evaluation, for the DBA to optimize
the storage format to the queries to be run, for the security guys to enforce
security, etc.

You can make the front-end API more flexible, but that doesn't remove the need
to do that kind of back-end stuff.

Yes, I still like it, but I'm not sure it really simplifies stuff as much as
it seems at first sight; to get performance you still have to tune the backed
to the kind of queries that are run.

------
weatherlight
I'm in the process of rewriting our external api using GraphQL, It's kind of
amazing, I do find my self tripping on "best practices" e.g. pertaining to a
User view model

query {user {name}} query {users(someQualifier: $qualifier){name}} mutation
{createUser(name: $name) {name}} mutation {updateUser(id: $id, name:
$name){name}} mutation {destroyUser(id: $id) {name}}

It ends up looking like CRUD. But so much easier to reason about :)

------
k__
Same here.

REST was a nice idea, but still too undefined.

Even attempts like JSON-API never really catched on.

The tree structure with the whole auto-discovery alone is a killer feature.

------
ChoHag
Well it has a Q in it. What's not cool about that?? Of course it's next!

(DNR)

