alt Hacker NewsI 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.