Kyle d'Oliveira

We've definitely been bitten by how easy it's been to make N plus one queries in the past. I think pretty much any Rails shop is going to be doing it. Rails offers tooling to help with that, but the tooling still requires a lot of effort. You have to kind of know what N plus one query you're introducing and fix it.

We've definitely been bitten by how easy it's been to make N plus one queries in the past. I think pretty much any Rails shop is going to be doing it. Rails offers tooling to help with that, but the tooling still requires a lot of effort. You have to kind of know what N plus one query you're introducing and fix it.

So though that's where you can build some more tooling, there exists a gem that we built, the JIP preloader. There's also another community gem called Goldiloder that removes stuff like N plus one queries. And those are ways to basically eliminate those kind of problems. Some other things that kind of come up on Rails as we are building is discoverability of templates.

So though that's where you can build some more tooling, there exists a gem that we built, the JIP preloader. There's also another community gem called Goldiloder that removes stuff like N plus one queries. And those are ways to basically eliminate those kind of problems. Some other things that kind of come up on Rails as we are building is discoverability of templates.

So I think one of the previous episodes of Ruby Rogues was talking about this. But as it scales up, Rails ERB makes it really easy to render partials all over the place. But it's really hard to understand, if you're looking at a page, where are those partials actually coming from? And how can you dig back into them? So that's a challenging thing with Rails as well.

So I think one of the previous episodes of Ruby Rogues was talking about this. But as it scales up, Rails ERB makes it really easy to render partials all over the place. But it's really hard to understand, if you're looking at a page, where are those partials actually coming from? And how can you dig back into them? So that's a challenging thing with Rails as well.

There's also some things with the community for things like paging that can be problematic at scale. If you look at what some of the basic gems that offer, it often comes down to a limit offset, which

There's also some things with the community for things like paging that can be problematic at scale. If you look at what some of the basic gems that offer, it often comes down to a limit offset, which

is also really fine on small datasets, but as you get to datasets that are really, really large and you're going to page really deep into them, it actually starts really falling apart and breaking down and things that you might not know until you actually just hit that scale.

is also really fine on small datasets, but as you get to datasets that are really, really large and you're going to page really deep into them, it actually starts really falling apart and breaking down and things that you might not know until you actually just hit that scale.

I think some of the Rails conventions also starts becoming a little bit problematic, and you see a little bit of discussion about this. Rails at one point said, throw all the logic into the controller. And then eventually the controllers became skinny and all the models became really fat.

I think some of the Rails conventions also starts becoming a little bit problematic, and you see a little bit of discussion about this. Rails at one point said, throw all the logic into the controller. And then eventually the controllers became skinny and all the models became really fat.

And I'm sure everyone has that God object that exists in their project, the user object or the account object that is 5,000 lines and really difficult to reason about. And people are offering opinions of having like service classes or various different patterns to try to combat that. But we're still trying to unpack some of the things that you started the Rails projects with.

And I'm sure everyone has that God object that exists in their project, the user object or the account object that is 5,000 lines and really difficult to reason about. And people are offering opinions of having like service classes or various different patterns to try to combat that. But we're still trying to unpack some of the things that you started the Rails projects with.

Yeah, and here's a little bit of my thoughts from it, but I'm not going to say my thoughts here are perfect. I think everyone's mileage will vary because documentation is a tricky thing. So when you get to... If you're getting to... gotchas. If you ever tell someone, oh, if you see this pattern, don't do it.

Yeah, and here's a little bit of my thoughts from it, but I'm not going to say my thoughts here are perfect. I think everyone's mileage will vary because documentation is a tricky thing. So when you get to... If you're getting to... gotchas. If you ever tell someone, oh, if you see this pattern, don't do it.

If you have code reviews that are like, oh, I've been bitten by this before, that should be something that falls into the linting or the just-in-time education where you try to codify that.

If you have code reviews that are like, oh, I've been bitten by this before, that should be something that falls into the linting or the just-in-time education where you try to codify that.

If you see people that have inline comments in code that says, you know, like, this next few lines are going to iterate over something and do these operations, that's probably an indication that their code is not written well to describe it, and that comment is not super valuable.

If you see people that have inline comments in code that says, you know, like, this next few lines are going to iterate over something and do these operations, that's probably an indication that their code is not written well to describe it, and that comment is not super valuable.