5 ms·

I remember reading their blog post about how moving from pages router to app router in Next.js helped their SEO last year. This time they are moving from Next t

by 3sbi 1y ago

I remember reading their blog post about how moving from pages router to app router in Next.js helped their SEO last year. This time they are moving from Next to React+Inertia.js because of growing bills from Vercel even though deploying the same app on your own VPS instead of relying on cloud provider would probably solve the issue. Nonetheless, I still don't understand their yearn for complexity - does book tracking app really need GraphQL, separate frontend framework and complicated build process or all that could have been solved by sticking to deploying monolithic RoR app with HTML templates on VPS from the very start?

lmm 1y 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 1y 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 1y 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 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.
    - 1y ago
- realusername 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y ago
    GraphQL is webscale
- sibeliuss 1y 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 1y 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.
Version467 1y ago
I stumbled upon hardcover when I was looking for a book info api and saw that goodreads discontinued theirs. Although it's pretty rough around the edges I've been using it extensively since then. As far as I understand hardcover was really created because goodreads discontinued their api and the team at hardcover saw how many people relied on it for a myriad of different niche projects. If hardcover was just a replacement for the goodreads platform, then I'd agree with you. But it's not. It's there for the api, with the platform around it intended as a way to ensure free access of the api for everyone. And from that pov choosing GraphQL makes a lot of sense imo. You can't anticipate all the cool and different things people might want to do with it, so they chose the most flexible api spec they could. On the other hand, I'm not sure if a complete rails rewrite was the right choice. The App was slow and sluggish beforehand, with frequent ui glitches and it still has those same issues. Their dev blog claims significant performance increases, but as a user I haven't noticed a big difference. Sticking with next.js, but moving to a selfhosted instance and then iteratively working on performance improvements would've been (imho) the better way forward. I see no reason why next.js somehow fundamentally couldn't do what they're trying to do, but rails can. Especially with just 30k users (which tbc is a great achievement, just not impressive from a technical standpoint).
- dyogenez 1y ago
  Thanks for the comments! You hit on a lot of why our app is structured the way it is. I agree too, we could've put those investments into Next.js rather than migrating to Rails. The difference was with Rails I could envision what the endpoint looked like (codebase, costs, caching, dev env, deployment, hosting options, etc). If we were to invest that time Next.js, some of those answers were (and still are) unclear. Agree we could still get there, it just wouldn't be as clear a path.
  - Version467 1y ago
    That's a fair argument. And to be clear (because my original comment might read as negative), I do like hardcover a lot. It might not work sometimes, but I still use it to track all my reading, because the ui is charming, because it has a good, open api and because it's very clearly made by people who really like reading. Wishing you all the success you can get!

by 3sbi 1y ago

lmm 1y 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 1y 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 1y 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 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.
  - 1y ago
realusername 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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 1y ago
  GraphQL is webscale
sibeliuss 1y 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 1y 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.

Version467 1y ago

I stumbled upon hardcover when I was looking for a book info api and saw that goodreads discontinued theirs. Although it's pretty rough around the edges I've been using it extensively since then. As far as I understand hardcover was really created because goodreads discontinued their api and the team at hardcover saw how many people relied on it for a myriad of different niche projects. If hardcover was just a replacement for the goodreads platform, then I'd agree with you. But it's not. It's there for the api, with the platform around it intended as a way to ensure free access of the api for everyone. And from that pov choosing GraphQL makes a lot of sense imo. You can't anticipate all the cool and different things people might want to do with it, so they chose the most flexible api spec they could. On the other hand, I'm not sure if a complete rails rewrite was the right choice. The App was slow and sluggish beforehand, with frequent ui glitches and it still has those same issues. Their dev blog claims significant performance increases, but as a user I haven't noticed a big difference. Sticking with next.js, but moving to a selfhosted instance and then iteratively working on performance improvements would've been (imho) the better way forward. I see no reason why next.js somehow fundamentally couldn't do what they're trying to do, but rails can. Especially with just 30k users (which tbc is a great achievement, just not impressive from a technical standpoint).

dyogenez 1y ago
Thanks for the comments! You hit on a lot of why our app is structured the way it is. I agree too, we could've put those investments into Next.js rather than migrating to Rails. The difference was with Rails I could envision what the endpoint looked like (codebase, costs, caching, dev env, deployment, hosting options, etc). If we were to invest that time Next.js, some of those answers were (and still are) unclear. Agree we could still get there, it just wouldn't be as clear a path.
- Version467 1y ago
  That's a fair argument. And to be clear (because my original comment might read as negative), I do like hardcover a lot. It might not work sometimes, but I still use it to track all my reading, because the ui is charming, because it has a good, open api and because it's very clearly made by people who really like reading. Wishing you all the success you can get!