Dominic

Yeah, we should move on from this because it's getting depressing.

Yeah, it absolutely does. The big opportunity, the big unlock here is... So we should take a step back, right? The reason this is a big deal is Rails aims to be a developer-friendly framework that makes it relatively straightforward to get your basic CRUD, your basic this-is-a-web-app stuff done. One of the challenges that I think a lot of people struggle with in Rails is, well, caching, right?

Yeah, it absolutely does. The big opportunity, the big unlock here is... So we should take a step back, right? The reason this is a big deal is Rails aims to be a developer-friendly framework that makes it relatively straightforward to get your basic CRUD, your basic this-is-a-web-app stuff done. One of the challenges that I think a lot of people struggle with in Rails is, well, caching, right?

So, you know, you don't want to hit the database every time necessarily. Make a new query every time for each request if it's the same request and nothing's changed. And, of course, queuing, right? So delay jobs. You know, Rails does not have a... I know I'm going to get... Yeah, I'm going to get shit for this, but...

So, you know, you don't want to hit the database every time necessarily. Make a new query every time for each request if it's the same request and nothing's changed. And, of course, queuing, right? So delay jobs. You know, Rails does not have a... I know I'm going to get... Yeah, I'm going to get shit for this, but...

there's compared to something like let's say a fast api rails doesn't really have an async story it's this is way too in the weeds but rails is basically a process model so different jobs have to run different processes kind of it's like threat there there's a million ways to do it but it's not as simple as you can get away with with fast api and let's say uh their async postgres uh pip package and

there's compared to something like let's say a fast api rails doesn't really have an async story it's this is way too in the weeds but rails is basically a process model so different jobs have to run different processes kind of it's like threat there there's a million ways to do it but it's not as simple as you can get away with with fast api and let's say uh their async postgres uh pip package and

and just, you know, async IO your way to glory and like do funny, fun things like gather up a bunch of queries and put them in. I forgot the method call, but basically you gather them up and put them into a big async queue and the whole queue returns when everything's done, which is what you want, right? And they're running in parallel. Rails, let's say it struggles from that.

and just, you know, async IO your way to glory and like do funny, fun things like gather up a bunch of queries and put them in. I forgot the method call, but basically you gather them up and put them into a big async queue and the whole queue returns when everything's done, which is what you want, right? And they're running in parallel. Rails, let's say it struggles from that.

And there's all kinds of debugging issues with, you know, delayed jobs. It's a huge pain in the ass. You remember when Stack Overflow was a thing and people actually went to it instead of just ChatGPT?

And there's all kinds of debugging issues with, you know, delayed jobs. It's a huge pain in the ass. You remember when Stack Overflow was a thing and people actually went to it instead of just ChatGPT?

If you search Rails questions, you're going to get a lot on delayed jobs and caching.

If you search Rails questions, you're going to get a lot on delayed jobs and caching.

So in Rails 8, they've built in solutions for all these things, right? So you can get rid of your Redis for your real-time messaging. Because if you're chasing that, I'm building a chat app dragon, I suppose you care about this. I think it's a little silly, a little late, but okay. Solid cache. Everybody needs caching. I don't care if you say you don't need caching. You need caching. You do.

So in Rails 8, they've built in solutions for all these things, right? So you can get rid of your Redis for your real-time messaging. Because if you're chasing that, I'm building a chat app dragon, I suppose you care about this. I think it's a little silly, a little late, but okay. Solid cache. Everybody needs caching. I don't care if you say you don't need caching. You need caching. You do.

You're eventually going to need it. It's a pain in the butt to add later. You should just start with caching. And before, you still have to make hard decisions, like what caching system am I using? Where am I caching? Am I caching in memory? Do I have enough memory? If I cache in the database, how many am I on an RPM hard drive? Am I running on a good old 5400 RPMs? Is that going to take forever?

You're eventually going to need it. It's a pain in the butt to add later. You should just start with caching. And before, you still have to make hard decisions, like what caching system am I using? Where am I caching? Am I caching in memory? Do I have enough memory? If I cache in the database, how many am I on an RPM hard drive? Am I running on a good old 5400 RPMs? Is that going to take forever?

Does it defeat the purpose of caching? Not anymore. NVMe drives. Great. That's a big win there. And solid cache being built into the framework makes it a hell of a lot easier to get started with. There's very little configuration. So that's just a win. Solid queue.

Does it defeat the purpose of caching? Not anymore. NVMe drives. Great. That's a big win there. And solid cache being built into the framework makes it a hell of a lot easier to get started with. There's very little configuration. So that's just a win. Solid queue.

same idea i'm a little more skeptical because if you're writing big large enterprise rails applications they have complicated jobs that need to be done see the problem is i don't have anything that's greenfield right now using solidq and it doesn't make sense in my opinion to start mixing and matching right to try to retrofit older applications to use it