dyogenez

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.

Another +1 for Tiller!

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.

> Why do you need GraphQL here?

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.

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.

> You can do this with Next.js SSR

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)

I haven't so far. I’ve preferred the new way:

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.

Thanks for the post! I noticed an uptick in referrals from YC for a little while just from this.

- Adam, Founder of Hardcover

Really curious about this too. react-rails is deprecated, so the choice seems to be react_on_rails or inertia.js.

Nice! Yeah I like the idea of sharing our static book data here on some kind of cadence. I'll pencil this in by the end of the year.

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.

Thank you! I was wondering where the 250ms of latency was coming from. I’ll change this up today.

I think you have it right. The signed URLs are a way to giving people an address to the files from our API, then they have call it again to key the keys. I suspect if once we put the files behind a CDN with signed keys, we’ll have even more security here.

I’m going to have to look into this today. I assuming generating the URLs hit an API, but if those can happen fast locally that changes things.

Thanks for the comment! Few things to reply to from here.

We didn’t have list access enabled, but someone did get a list of files from our API.

Rails with Paperclip and active storage is amazing. Our front end is in Next.js though, so we have people upload straight from Next to GCS, then we sent the GCS URL to Rails. We don’t do pre-processing of images, so just storing the original is good.

They can still download every image, but they’ll be throttled now and kicked out at the middleware level, or permission denied from GCP. 60/min vs 10k/min.

The signature calculation happening might not be hitting Google in that case. I noticed a long data dump in the console after requesting the signed URL combined with the additional latency and assumed. Maybe it’s just a cryptically difficult calculation like bcrypt and it takes a while. Will have to check, because it’s be great to not need a network reliant call for that.

This is true. I’d still need a CDN in front of the actual files to prevent that. That’s a takeaway for me from this feedback.

I hadn't thought of that, but I love the idea! How's that work?

I left off the method that generates the signed URL. It limits the bucket to a specific one per env and blocks some protected folders and file types. I left that out in case someone used it to find an opening to attack.

If this were a business and someone else's money I'd do the same. This is a bootstrapped side project coming out of my own wallet.

If money wasn't an issue, I'd probably just allow people to download images for free.