Chris Oliver

Alexandre, that's not needed for this. For example, your Rails app can load SQLite, then Rails itself will load the database config and ensure that SQLite gem is required as a double check.

Using require: false would just move the loading of SQLite from boot and instead load SQLite when Rails requires it. It's not going to give you a benefit in your application because it will be required either way.

This is more for libraries that have optional dependencies. This way Rails doesn't have to add SQLite as a dependency for everyone, it can optionally require the gem later on.

Love solving problems like this with pure CSS and no JavaScript. 👌

Not your computer. It is probably with propshaft

Hmm, it might be a bug in something but it's hard to say. That change should not affect any performance.

Try restarting your server.

@1klap, no it is a separate, dedicated course since it's so in-depth.

Hey Allan,

Can you cache the calculation results to the database? That would make retrieving and filtering faster since you wouldn't have to re-calculate every time (which I assume is the slow part?).

In case you're interested, you can sign up for our Learn Hotwire course here. We're covering Hotwire with Rails and Native with iOS and Android, diving deep into the details more than any other course out there.

"from Async" means your background jobs are being processed by the default "async" adapter.

You'll want to change the ActiveJob queue adapter to Solid Queue or Sidekiq and you'll see the following:

[ActiveJob] [Turbo::Streams::BroadcastStreamJob] [e6bee483-4ebb-439e-a6df-69959947506a] Performed Turbo::Streams::BroadcastStreamJob (Job ID: e6bee483-4ebb-439e-a6df-69959947506a) from SolidQueue(default) in 37.44ms

That's awesome. Curious to hear what change(s) made the biggest difference. That's a huge improvement.

Structured output makes advanced AI integrations actually possible. Imagine trying to parse a string response every time without structured json output! 😅

It's always trade-offs. For example, an icons gem is probably going to load them into memory so rendering icons is faster by not loading them from disk every time.

Reducing memory usage sometimes means making things slower so don't look at it as an arbitrary goal. You may want to keep it low so your server costs are low, but in production paying for more RAM to achieve more throughput is often worth the trade-off.

In general, I think a Rails app tends to use 400-600MB of RAM. Gems and different configurations can affect the usage so there's not really a specific number to aim for.

One thing you can do is enable jemalloc and that often reduces memory usage by a good percentage as it's more efficient than the default malloc.

https://community.render.com/t/how-to-use-jemalloc-in-ruby-web-service/1183

broadcasts_refreshes actually broadcasts to a couple different streams:

<%= turbo_stream_from :lockouts %>

<%= turbo_stream_from @lockout %>

Yeah, behind the scenes you'd use ActionCable, but Turbo morphing is what will make that easy. You'll add "broadcasts_refreshes" to the models to have them broadcast a page refresh with those updates automatically anytime the database records change. We don't have a lesson on that just yet but I'll make one for you!

We'll definitely do a video on structured outputs. 👍

What other types of AI integrations would you like to see?

Awesome! Sounds like a fun project. Definitely want to hear more about how it goes.

I remember now that I wanted to cover how to build this but also extract it into a gem so maybe we can kill two birds with one stone on this series. 🤔

I don't think we ever made a lesson for this. I will prioritize that. 👍

I love removing dependencies. 💖

Also, learning how libraries can make features or dependencies optional is a great thing to learn along the way.