Post author here. I've been developing in Ruby and Rails for almost 20 years. Here are some of the downsides in my opinion.
- The Global interpreter lock (GIL) in Ruby is less performant than async thread programming in JS (and some other languages)
- Rails creates a monolith rather than a bunch of independent endpoints. If you have a large team, this can be tricky (but is great for smaller teams who want to move fast)
- How Rails integrates with JS/CSS is always changing. I recommend using Vite instead of the asset pipeline, unless you're going with the stand Rails stimulus js setup.
- Deploying Rails in a way that auto-scales the way serverless functions can is tricky. Their favored deployment is to server of set size using Kamal.
It's less expensive now with Rails than our hosting was with Next.js. If there was more traffic, we'd save even more money in comparison. That was mentioned in the post.
Yep! It'd be possible with Next.js. The difference is how it's organized. In Next.js with RSCs, we were fetching data for each part of the page where it's used (trending books, Live events, blog posts, favorite books). Each of those could be their own cache hit to Redis.
One advantage of Rails is the controller. We can fetch all data in s single cache lookup. Of course it'd be possible to put everything needed in a single lookup in Next.js too, but then we wouldn't be leveraging RSCs.
I tried self-hosting Next.js on Digital ocean, but it crashed due to memory leaks without a clear way to understand where the leak was. Google Cloud Run and Vercel worked because it would restart each endpoint. We have more (and cheaper) hosting options with Rails.
This is my exact criticism of RSCs, they basically encourage the N+1 query problem. Basically nobody should be organizing their data fetches like this.
We have one developer (me) and we're bootstrapped and not yet profitable. That means I'm paying the difference every month in hosting and working for free. The site makes it look like we have a lot more together than we are.
> 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.
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!
That is one of the slower pages on the entire app. I'd like to move that one to use an InertiaRails.deferred setup, so it loads instantly with a loading spinner - like you'd see with Suspense + RSC. (Hardcover founder here)
We recently did a major migration from Next.js to Ruby on Rails with Inertia that took a few months. I wanted to share some of the thought process behind that decision, how we made it and what the change looked like in practice.
Inertia.js turned out to be amazing for this switch, and turned me into a big fan of Vite and Rails.
With RSCs, I’d have code scattered throughout components that would hit APIs to get data.
With Rails + Inertia, that code is all in a Rails controller - usually with a serializer.
I’m still getting used to using InertiaRails.optional there which is what’s needed for a Suspense like experience w/Inertia. Having everything in controllers again is nice.
The app was initially client-side only. I choose GraphQL over REST because Hasura created a super quick API for the database.
Also, our API is public! We started as an alternative to Goodreads when they closed their API.
reply