4 ms·

GraphQL Didn't Kill REST

35 points by mengledowl 8y ago

HumanDrivenDev 8y ago
Here I was continuing my naive existence, blissfuly unaware that REST was even dead!
- smt88 8y ago
  The whole intro to the article is about how REST can't be honestly called dead.
- ChristianGeek 8y ago
  I’ve been blissfully unaware that GraphQL was alive.
samspenc 8y ago
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-Design-Filtering-Sorting-and-Pagination/ https://www.moesif.com/blog/technical/api-design/REST-API-De... [3] https://stackoverflow.com/questions/207477/restful-url-design-for-search?rq=1 https://stackoverflow.com/questions/207477/restful-url-desig...
- NicoJuicy 8y ago
  I can second OData, but i think it's important to know that OData has nothing to do with Microsoft anymore ( officially). The only thing is that they support it officially in the dot net environment. It's now an open protocol with lot's of integrations: https://www.odata.org/libraries/ https://www.odata.org/libraries/ But it's great to use though. You'll love it if you like Linq/lambda's. /odata/Clients?$filter=Status eq 0 or LastLoggedIn is null
- somada141 8y ago
  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 8y ago
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.
- y4mi 8y ago
  Last year around this time I tried to implement a bare bones graqhql API with Django. I kept having to write boilerplate code to get it working. I quickly learned why Django rest framework is the defacto standard... The tooling is just uncomparibly better
- chrisco255 8y ago
  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__ 8y ago
    Have any good resources to get into AppSync, especially with CloudFormation?
    - chrisco255 8y ago
      https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-with-amazon-cloudformation-9a783fdd8491 https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-w... https://andrewgriffithsonline.com/blog/serverless-websockets-on-aws/ https://andrewgriffithsonline.com/blog/serverless-websockets...
      - k__ 8y ago
icc97 8y ago
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 8y ago
  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.

35 points by mengledowl 8y ago

HumanDrivenDev 8y ago

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

smt88 8y ago
The whole intro to the article is about how REST can't be honestly called dead.
ChristianGeek 8y ago
I’ve been blissfully unaware that GraphQL was alive.

samspenc 8y ago

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-Design-Filtering-Sorting-and-Pagination/ https://www.moesif.com/blog/technical/api-design/REST-API-De... [3] https://stackoverflow.com/questions/207477/restful-url-design-for-search?rq=1 https://stackoverflow.com/questions/207477/restful-url-desig...

NicoJuicy 8y ago
I can second OData, but i think it's important to know that OData has nothing to do with Microsoft anymore ( officially). The only thing is that they support it officially in the dot net environment. It's now an open protocol with lot's of integrations: https://www.odata.org/libraries/ https://www.odata.org/libraries/ But it's great to use though. You'll love it if you like Linq/lambda's. /odata/Clients?$filter=Status eq 0 or LastLoggedIn is null
somada141 8y ago
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 8y ago

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.

y4mi 8y ago
Last year around this time I tried to implement a bare bones graqhql API with Django. I kept having to write boilerplate code to get it working. I quickly learned why Django rest framework is the defacto standard... The tooling is just uncomparibly better
chrisco255 8y ago
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__ 8y ago
  Have any good resources to get into AppSync, especially with CloudFormation?
  - chrisco255 8y ago
    https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-with-amazon-cloudformation-9a783fdd8491 https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-w... https://andrewgriffithsonline.com/blog/serverless-websockets-on-aws/ https://andrewgriffithsonline.com/blog/serverless-websockets...
    - k__ 8y ago

icc97 8y ago

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 8y ago
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.