alt Hacker NewsEvery 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.
Replies
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.
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
> 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.
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.
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.
> 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.