Memcached was a savior for caching when it launched. I love that it was created in 2003 by Brad Fitzpatrick for LiveJournal. Each post on a users feed could have different access restrictions, and this allowed posts (or entire pages) to be cached.
I used it with Ruby on Rails for many years. It sped up pages, and just worked.
The downside (and upside for speed) is (and always was) that cache was saved in memory not disk. This meant hosting would be expensive if you have a large scale site with a wide amount of data to cache.
Solid cache has been a savior for those cases for me. We have over 100gb of cache for a project I'm working on, and it's stored in postgres on disk, with fast lookups with an index and expirations that happen automatically in Rails to delete those rows.
If I had a smaller cache need and was already using Redis, I'd probably just use that. But if speed was the number 1 factor, and I'd try benchmarking Memcached vs Redis.
I'm doing something similar with Tiller (which I've been using since Mint was acquired by Intuit).
It's neat to see how OP did this using a Claude Routine though. My version locally uses a local qwen model + an API key (annoyingly created using OAuth) with sheets access. A Claude Routine would've been significantly easier
One game that changed my life was SimCity 2000. It shaped how I think about building products - before I even knew the term. Just published a new blog post about how it impacted me.
Lately I've been thinking about how the feeling I get creating products is chasing the feeling I had building my first city. When I thought more about it, I was amazed at how well the ideas from the game related to building products.
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.
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 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)
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.
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.
We usually spend about $60/month at Google anyways, so $100 wasn’t a crazy jump. That could be one left on Cloud Run instance. When it jumped to $300 total after disabling it that’s when I got worried.
I recently had a call with Google and have a sales/solution person I’ve been talking to about moving more services there. I’ll share what happened and see what they say.
This sounds like a solid next step. I’d like to stop storing URLs we don’t control in our DB and share URLs to these images behind a CDN. We could slowly roll that out and update each image url in our database over time with both continuing to work.
I didn’t realize you could do this with a private bucket by granting it access either. That combined with IP throttling at the CDN level might be a good replacement for this and cut out the need for Rails.
I used it with Ruby on Rails for many years. It sped up pages, and just worked.
The downside (and upside for speed) is (and always was) that cache was saved in memory not disk. This meant hosting would be expensive if you have a large scale site with a wide amount of data to cache.
Solid cache has been a savior for those cases for me. We have over 100gb of cache for a project I'm working on, and it's stored in postgres on disk, with fast lookups with an index and expirations that happen automatically in Rails to delete those rows.
If I had a smaller cache need and was already using Redis, I'd probably just use that. But if speed was the number 1 factor, and I'd try benchmarking Memcached vs Redis.