3 ms·

> Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Not re

> Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Not remotely true. There are plenty of web apps that work just fine with a standard fixed set of API endpoints with minimal if any customization of responses. Not to mention the web apps that don't have any client-side logic at all... GraphQL solves a problem that doesn't exist for most people, and creates a ton of new problems in its place. The value of GraphQL is also its downfall. The flexibility it offers to the client greatly complicates the backend, and makes it next to impossible to protect against DoS attacks effectively, or even to understand app performanmce. Every major implementation of GraphQL I've seen has pretty serious flaws deriving from this complexity, to the point that GraphQL APIs are more buggy than simpler fixed APIs. With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility. Just have the backend provide the APIs that the front-end actually needs. If those needs change, also change the backend. When that kind of change is too hard or expensive to do, it's an organisational failing, not a technical one. Sure, some use-cases might warrant the flexibility that GraphQL uses. A book tracking app does not.

lmm 1y ago
> With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility But also no problem with it. There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? > Just have the backend provide the APIs that the front-end actually needs. If those needs change, also change the backend. Sure, but how are you actually going to do that? You're always going to need some way for the frontend to make requests to the backend that pull in related data, so that you avoid making N+1 backend calls. You're always going to have a bunch of distinct but similar queries that need the same kind of related data, so either you write a generic way to pull in that data or you write the same thing by hand over and over. You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library.
- sibeliuss 1y ago
  Exactly. People pull this argument right out of their hat, already prepared, where spending just a few moments thinking about it would give one pause. The tools and patterns to limit these (very common, in any kind of system) drawbacks are so well-established that its a non-issue for anyone sincerely looking at the tech.
- fvdessen 1y ago
  > There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries
  - lmm 1y ago
    > People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.
    - buzzerbetrayed 1y ago
      So un-graphql-ing your graphql. This shit is wild.
      - lmm 1y ago
        Shrug, databases have been doing the same thing since the 1970s (and consider also e.g. regexes). Turns out a flexible, expressive language for writing queries isn't always the most secure or performant thing to use as your wire format.
        yawaramin 1y ago
dyogenez 1y ago
> Sure, some use-cases might warrant the flexibility that GraphQL uses. A book tracking app does not. I agree! If you're in control of the experience, then I wouldn't choose GraphQL for a limited experience either. The project started because Goodreads was retiring their API, and I wanted to create something better for the community. I have no idea how people will use it. The more we can provide, and the more flexible it is, the more use cases it'll solve. So far we have hundreds of people using the GraphQL API for all kinds of things I'd never expect. That's the selling point of GraphQL for me - being able to build and figure out the use case later. But I would never want to create a GraphQL API from scratch (not again). In this case, Hasura handles that all for us. In our case it was easier than creating a REST API.

lmm 1y ago

> With most web apps having their front-end and back-end developed in concert, there's simply no need for this flexibility But also no problem with it. There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? > Just have the backend provide the APIs that the front-end actually needs. If those needs change, also change the backend. Sure, but how are you actually going to do that? You're always going to need some way for the frontend to make requests to the backend that pull in related data, so that you avoid making N+1 backend calls. You're always going to have a bunch of distinct but similar queries that need the same kind of related data, so either you write a generic way to pull in that data or you write the same thing by hand over and over. You can write each endpoint by hand instead of using GraphQL, but it's like writing your own collection datatypes instead of just pulling in an existing library.

sibeliuss 1y ago
Exactly. People pull this argument right out of their hat, already prepared, where spending just a few moments thinking about it would give one pause. The tools and patterns to limit these (very common, in any kind of system) drawbacks are so well-established that its a non-issue for anyone sincerely looking at the tech.
fvdessen 1y ago
> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries
- lmm 1y ago
  > People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.
  - buzzerbetrayed 1y ago
    So un-graphql-ing your graphql. This shit is wild.
    - lmm 1y ago
      Shrug, databases have been doing the same thing since the 1970s (and consider also e.g. regexes). Turns out a flexible, expressive language for writing queries isn't always the most secure or performant thing to use as your wire format.
      - yawaramin 1y ago

dyogenez 1y ago

> Sure, some use-cases might warrant the flexibility that GraphQL uses. A book tracking app does not. I agree! If you're in control of the experience, then I wouldn't choose GraphQL for a limited experience either. The project started because Goodreads was retiring their API, and I wanted to create something better for the community. I have no idea how people will use it. The more we can provide, and the more flexible it is, the more use cases it'll solve. So far we have hundreds of people using the GraphQL API for all kinds of things I'd never expect. That's the selling point of GraphQL for me - being able to build and figure out the use case later. But I would never want to create a GraphQL API from scratch (not again). In this case, Hasura handles that all for us. In our case it was easier than creating a REST API.