GraphQL vs REST

What are the downsides for using GraphQL over REST?

What is the consensus on GraphQL? Is it really killing the Rest API or is that more hype?

GraphQL isn`t an alternative for REST. GraphQL is a solution for very specific cases and even in this cases it has his own drawbacks.

Just use GraphQL. REST is dead.I've had a lot of experience with REST & JSON API and those "generators" or abstraction people create always end up being very inflexible. With GraphQL, you have full control on what you return, as well full control over how you want to change your data. Easy to avoid n+1 etc. Maybe that's just me, but I think this question is already answered. Took us a few years to discover a better way.I've been using GraphQL for the last 2 yea

i was over graphql when it started. REST was fine

Exactly the same experience with GraphQL - indeed I think in the end it cost more time than REST. The thing is, GraphQL is a tool that really shines when you have... graph data (like Facebook). The problem is every company under the sun is now rushing to use it as if it's some kind of silver bullet because of all the hype.

Disagree - GraphQL is a legit better way to build APIs.As a backend engineer, I publish a schema of all the available data - the frontend can fetch it in any shape it prefers. Web UIs and mobile UIs often have different views, so they want different data, and fetching it in one request or many is up to the preference of the UI.I don't have to build different REST endpoints presenting some data in a different shape for performance reasons or because different applications wanted to req

GraphQL as a query language is simply better than REST in most cases imo. REST has too much client side state, which not only has the potential to make things harder for clients to consume, but also has all the inconsistent states to handle where your consumer gets part way through a multiple-REST method workflow, and then bails. REST also absolutely sucks for mutating arrays.Really I just look at GraphQL as a nice RPC framework. The graph theory operations like field level resolvers are most

I'm very surprised by this. I have built REST in the past and recently I built a large GraphQL service. I found GraphQL to be a lot less confusing both for front-end and for back end. The tooling is amazing, standardized schema introspection is great.Sure, if you try to shoehorn an API that does not fit the database, it can be challenging, but you can always start with the simple case, doing multiple queries to the DB for one GraphQL request and only later see what is actually used and c

I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns.I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for.I've read about an apollo bridge that basically does GQL over REST. I'm pr