Ask HN: What Are HNers thoughts on REST vs. GraphQL?

6 points·Blackstone4··5 comments

Do HNers believe GraphQL will become the new REST?

Is GraphQL just a new fad that will come and go?

Are you using GraphQL in production or thinking about it?

If you are using GraphQL in production, what language or framework are you running on? I heard Sangria works well and there's the nodeJS versions.

Is there something better than REST and GraphQL?

View on HN

The comparison is mainly of interest to people who believe in silver bullets. REST is going nowhere, and is a highly appropriate choice for lots of situations - e.g document-oriented stores.

GraphQL solves a number of different issues and is particularly good on the front end, but the ability to write/update data is more limited.

RPC is still a very valid technology, and suits event architectures very well. It's incredibly flexible, but that means you need to spend more time designing a good API.

Choose the best approach for the problem at hand.

Thank you for your response. What do you mean by GraphQL's "the ability to write/update data is more limited"?

You have to define every mutation you need, whereas with REST it's a bit more generic.

I think the two are equivalent, but the more mutations you need, the more complex your GraphQL schema becomes.

I posted this because I've never used REST and I've been using GraphQL in the last six months. I've found it be to very powerful and has made the web app development a pleasure.

It helps that I'm using Graph.cool for the backend. It handles most of the CRUD boilderplate operations, database and server. I then layer on permissions and serverless functions.

Thoughts welcome :)

I've used odata and graphql, I like odata more. Which is just rest with query capabilities

Reply on news.ycombinator.com