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. Yes, a bo

by lmm 2y ago

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL. Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place. Do you need a complicated build process? No. You want your build process to be just "run npm". And that's what something like Next gets you. "Monolithic RoR app with HTML templates on VPS" would introduce more problems than it solves. If Next-style frameworks had come first, you would be posting about how RoR is a solution in search of a problem that solves nothing and just overcomplicates everything. And you'd be right.

makeitdouble 2y ago
> ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Everytime I hit the "should we use GraphQL" question in the last decade we balked because we already had fast REST like APIs and couldn't see a how it would get faster. To your point it was more of a mish-mash than anything with a central library magically dealing with the requests, so there is more cognitive load, but it also meant we had much more control over the behavior and performance profile.
Diggsey 2y ago
> 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 2y 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 2y 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 2y 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 2y 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.
realusername 2y ago
Maybe I'm biased but I don't see any scenario where GraphQL ever makes sense, the complexity is never worth it. You throw away all the debuggability and simplicity of rest for close to zero advantages
- lmm 2y ago
  How so? You've got all the same debuggability that you'd have with rest - sure you need to look at your requests and responses through your tools rather than directly, but that was already the case unless you're not using HTTPS (which is a bigger problem). Throw up GraphiQL on one of your developer/admin pages and you've got easier exploratory querying than you could ever get with an old-style Rest API.
  - realusername 2y ago
    Simple questions like "which teams own the slowest endpoints" suddenly become a nightmare to compute with GraphQL. There's a reason why every industry moved to division of labor. Then the security looks also annoying to manage, yeah sure the front-end can do whatever it wants but nobody ever wanted that.
    - lmm 2y ago
      Shrug. Your tracing tools need to understand your transport protocol (or you need to instrument all your endpoints), sure, but that's always been the case. Likewise with security. IME the stuff that's available for GraphQL isn't any worse than what's available for raw HTTPS and is often better since you have more information available (e.g. if you want to redact a particular object field from all your responses depending on the caller's authorisation, it's much easier to do that in GraphQL where that field only exists in one place than in a bunch of handwritten endpoints where you have to find every response that field might appear in).
wordofx 2y ago
GraphQL is the new mongodb. This fancy new thing that people want to use and makes no sense in reality and just causes more problems than it solves. It solves a very specific problem that makes sense at Facebook. It makes 0 sense for companies that have a web app or web and mobile app. And nothing else. Anyone deciding to use graphql is making a dumb decision.
- Kwpolska 2y ago
  Facebook does not really use GraphQL in their public apps. The apps call named queries defined server side, so GraphQL is just a glorified RPC mechanism, not a query language.
- homebrewer 2y ago
  I sometimes have to write integrations with external data providers (most of them being government agencies), and they love graphql, where (IMHO) it makes a lot of sense. They provide data about some entity¹ split into X fields, your application needs maybe 20% of them, and thanks to graphql you don't have to request anything but those 20%. When loading hundreds of millions of records, it saves you from loading, parsing, and then throwing away gigabytes of unnecessary JSON. 1: one example being tax records with all associated information about tax collecting agencies and taxpayers — it's a lot of data
- tekno45 2y ago
  GraphQL is webscale
sibeliuss 2y ago
People hate on GraphQL and every time I read it, I just default assume they haven't used it at scale and don't understand the benefits, or fail to grasp just how hard frontend dev is for anything non-trivial. It has worked so remarkably well, and scaled from app to app to app in an almost copy/paste kind of way (all type-safe!), that it is easily my favorite tech, along with Relay. We've been using it in production for 10 years. Would I change a single thing? No. Every day I come to work thankful that this is the tech stack that I get to work on because it _actually works_ and doesn't break down, regardless of size.
fulafel 2y ago
Greenspun's rule worked in favour of Common Lisp (to the extent that it did...) because CL solves a lot of hard problems that ad-hoc solutions do poorly, like automatic memory management, DSLs, etc. But lots of apps can do with a lightweight pull API that can be tailored, fits the applications' access control model (as points of contrast to GraphQL) and it's less work and less risk than finding, integrating and betting on a GraphQL implementation.

by lmm 2y ago

makeitdouble 2y ago

> ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Everytime I hit the "should we use GraphQL" question in the last decade we balked because we already had fast REST like APIs and couldn't see a how it would get faster. To your point it was more of a mish-mash than anything with a central library magically dealing with the requests, so there is more cognitive load, but it also meant we had much more control over the behavior and performance profile.

Diggsey 2y ago

> 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 2y 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 2y 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 2y 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 2y 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.

realusername 2y ago

Maybe I'm biased but I don't see any scenario where GraphQL ever makes sense, the complexity is never worth it. You throw away all the debuggability and simplicity of rest for close to zero advantages

lmm 2y ago
How so? You've got all the same debuggability that you'd have with rest - sure you need to look at your requests and responses through your tools rather than directly, but that was already the case unless you're not using HTTPS (which is a bigger problem). Throw up GraphiQL on one of your developer/admin pages and you've got easier exploratory querying than you could ever get with an old-style Rest API.
- realusername 2y ago
  Simple questions like "which teams own the slowest endpoints" suddenly become a nightmare to compute with GraphQL. There's a reason why every industry moved to division of labor. Then the security looks also annoying to manage, yeah sure the front-end can do whatever it wants but nobody ever wanted that.
  - lmm 2y ago
    Shrug. Your tracing tools need to understand your transport protocol (or you need to instrument all your endpoints), sure, but that's always been the case. Likewise with security. IME the stuff that's available for GraphQL isn't any worse than what's available for raw HTTPS and is often better since you have more information available (e.g. if you want to redact a particular object field from all your responses depending on the caller's authorisation, it's much easier to do that in GraphQL where that field only exists in one place than in a bunch of handwritten endpoints where you have to find every response that field might appear in).

wordofx 2y ago

GraphQL is the new mongodb. This fancy new thing that people want to use and makes no sense in reality and just causes more problems than it solves. It solves a very specific problem that makes sense at Facebook. It makes 0 sense for companies that have a web app or web and mobile app. And nothing else. Anyone deciding to use graphql is making a dumb decision.

Kwpolska 2y ago
Facebook does not really use GraphQL in their public apps. The apps call named queries defined server side, so GraphQL is just a glorified RPC mechanism, not a query language.
homebrewer 2y ago
I sometimes have to write integrations with external data providers (most of them being government agencies), and they love graphql, where (IMHO) it makes a lot of sense. They provide data about some entity¹ split into X fields, your application needs maybe 20% of them, and thanks to graphql you don't have to request anything but those 20%. When loading hundreds of millions of records, it saves you from loading, parsing, and then throwing away gigabytes of unnecessary JSON. 1: one example being tax records with all associated information about tax collecting agencies and taxpayers — it's a lot of data
tekno45 2y ago
GraphQL is webscale

sibeliuss 2y ago

People hate on GraphQL and every time I read it, I just default assume they haven't used it at scale and don't understand the benefits, or fail to grasp just how hard frontend dev is for anything non-trivial. It has worked so remarkably well, and scaled from app to app to app in an almost copy/paste kind of way (all type-safe!), that it is easily my favorite tech, along with Relay. We've been using it in production for 10 years. Would I change a single thing? No. Every day I come to work thankful that this is the tech stack that I get to work on because it _actually works_ and doesn't break down, regardless of size.

fulafel 2y ago

Greenspun's rule worked in favour of Common Lisp (to the extent that it did...) because CL solves a lot of hard problems that ad-hoc solutions do poorly, like automatic memory management, DSLs, etc. But lots of apps can do with a lightweight pull API that can be tailored, fits the applications' access control model (as points of contrast to GraphQL) and it's less work and less risk than finding, integrating and betting on a GraphQL implementation.