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?
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).
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.
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!
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.
> 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.
> 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.
> 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
> 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.
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.
Do you understand that decompilers and reverse engineering are a thing?
Adversaries are not restricted to using your system the way you designed your system. GraphQL queries are trivial to pull out of Wireshark and other sniffers. If you deliver it to the browser, any determined-enough adversary will have it, period. I wouldn't be surprised in the least if it is already a thing for LLM models to sniff GraphQL endpoints in the quest for ever more data.
> Do you understand that decompilers and reverse engineering are a thing?
Do you understand how compiled queries in GraphQL (or even an old-school RDBMS) work? All that gets sent over the wire is the query id. There's physically no way to make the server execute a query the author didn't write.
So you threw out all the benefits of GraphQL. Instead of allowing the frontend to determine what it needs, you need to write a new backend endpoint that will return what's needed for that page. This is no different from writing some /rpc/bffe/get-profile-page call, which is much simpler to write and has much better tooling.
No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the shelf functionality. Maybe spend 5 minutes trying to think about how a system might work instead of assuming everyone else is an idiot.
Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with. Exactly what you just described doing is what the parent comment expected you were doing.
> Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with.
What are you talking about?
The build process takes the queries the frontend wants to use, compiles them, and includes them in the backend build. There is no manual step, you don't even change a single line of code or config on the backend, much less write a new endpoint. As far as I'm aware this is the completely normal way to use graphql.
I think I finally understand your earlier comment in context:
> 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.
Everyone else is "pulling in an existing library", they have names like Express and Kysely, and thinking that Apollo is the only library that deserves this designation is a bit of a head-scratcher.
If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change), and not using a fad-of-the-month just because it came out of a FAANG.
> If you take the time to invest in a proper REST API first, odds are the endpoint may already exist, and you may not need to wait for a new backend build; not investing in a custom endpoint for every frontend change unless real-world performance requirements actually dictate it. You get tooling that is more mature and easier to maintain as a result, makes it easier for Product to experiment (remember: not forcing a backend change for every frontend change)
If it's a giant system where your backend/frontend/product teams are separate, maybe - but even then, they can run any custom queries they want on non-prod instances, so it's easy to do internal testing, and always including backend deployment when you do a prod release is not a huge burden.
I still think there's never going to be an advantage to doing N+1 queries - there might be cases where the performance difference doesn't matter, but an endpoint that returns precisely what you want would always be better if you could get it for free. And you can't really set up "aggregating" endpoints ahead of time, unless you pre-emptively create all N*N possible combinations, and that's going to go against having a "clean" normalised set of REST endpoints. Just like in a database schema, there's value in having every individual endpoint orthogonal and then doing the joining at query time, at least for a system under active development where you want to try new things without redoing your whole dataflow.
> not using a fad-of-the-month just because it came out of a FAANG.
I don't think it's a fad at this point - graphQL has been around for 10 years, the systems I've worked on have been using it successfully for about 5, and the design is built on what the likes of Thrift and gRPC were already doing where possible. There are, as you pointed out, multiple library implementations for many languages. It's popular because it works.
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.
> 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.
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.
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
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.
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.
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.
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).
> 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.
