
GraphQL Didn't Kill REST - mengledowl
https://graphqlme.com/2018/04/01/graphql-didnt-kill-rest/
======
samspenc
Is REST perfect? Probably not. But it certainly does its job, and that's why
most middle-tier APIs these days, whether it be those that power web
applications or mobile apps, are in REST, with the backend itself being
written in a variety of languages (PHP, Python, Java, C#, etc).

I will admit that core REST doesn't support basic "querying" functionality, or
even things like pagination, filtering, sorting, etc, which is why there are a
set of standards, or best practices on top of REST that aim to standardize
those commonly used patterns. [1] [2] [3]

Finally REST, whether by design or not, follows the KISS principle (Keep It
Simple and Stupid), and that's probably why it's gained as much traction as it
has over the years.

Want to get a user object? GET /user/<id> Want to update it? POST or PUT
/user/<id> Get a list of all users? GET /user/

If you look at just the "basic" examples for GraphQL, you will understand why
it's never going to replace REST in its current form.

[1] Microsoft's OData: [https://www.odata.org/](https://www.odata.org/) [2]
[https://www.moesif.com/blog/technical/api-design/REST-API-
De...](https://www.moesif.com/blog/technical/api-design/REST-API-Design-
Filtering-Sorting-and-Pagination/) [3]
[https://stackoverflow.com/questions/207477/restful-url-
desig...](https://stackoverflow.com/questions/207477/restful-url-design-for-
search?rq=1)

~~~
somada141
I find that REST was 'perfect' given the status-quo of APIs at the time it
came out. It allowed for massive simplification of APIs compared to its XML-
based predecessors and enabled every man and his dog to make a half-decent
semi-standardized API.

For better of for worse as things progressed new requirements and complicating
factors like the ones you mentioned (filtering, pagination, need for dynamism
etc) came up that ended up being handled in a dozen different ways muddying up
the waters.

To me, GraphQL built on top of REST to cover those bases and IMHO that's how
these technology standards are supposed to evolve: thing comes up, it gets
used till previously unknown requirements surface, new thing learning from old
thing and addressing new requirements comes up.

I was really bothered when I realised that GraphQL doesn't allow for
heterogeneous input-type unions though, cause that makes filtering a hassle
(eg if you wanna have a query that can take an arbitrary number of filters for
fields of different types).

------
somada141
IMHO what makes or breaks a paradigm like REST or GraphQL in real-life is the
state of tooling made by third-parties to enable its adoption in the workplace
or personal projects.

Working in Python-land I'm pretty confident REST wouldn't have been as
ubiquitous if it wasn't for tools like Flask, marshmallow, and the myriad of
other tools.

Having taken up GraphQL in personal projects I can say that at least in Python
the tooling just ain't there so until it gets there I don't see GraphQL
killing anything.

~~~
chrisco255
I think serverless GraphQL is the future of the backend. And honestly, not as
familiar with the Python landscape but if you use tools like Prisma (Node-
based) or AppSync (AWS Lambda based), a lot of your GraphQL queries and
mutations can be generated automatically based on a typed schema file.

~~~
k__
Have any good resources to get into AppSync, especially with CloudFormation?

~~~
chrisco255
[https://read.acloud.guru/deploy-an-aws-appsync-graphql-
api-w...](https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-with-
amazon-cloudformation-9a783fdd8491)

[https://andrewgriffithsonline.com/blog/serverless-
websockets...](https://andrewgriffithsonline.com/blog/serverless-websockets-
on-aws/)

~~~
k__
Very good, thank you :)

------
HumanDrivenDev
Here I was continuing my naive existence, blissfuly unaware that REST was even
dead!

~~~
ChristianGeek
I’ve been blissfully unaware that GraphQL was alive.

------
icc97
REST can practically never die - it's just describes how most of the internet
works: HTTP + links.

Maybe people will stop using REST APIs, but REST will still be a thing as long
as HTTP is.

GraphQL seems like it can solve some pain points of REST once you start using
REST APIs at a massive scale. REST improves on SOAP in even the tiniest of
cases.

~~~
somada141
IMHO for a technology to be called dead it needs to stop being used in large
corporations and open projects.

I'm still aware of heaps of SOAP APIs, especially in more niche industries,
where porting to REST must not have been in the budget :D.

