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