Chris Oliver

@1klap Who said that? You're literally commenting on Hotwire content on GoRails lol. Obviously, we're going to continue teaching Hotwire content with Rails on GoRails.

I think the point of confusion is that Learn Hotwire is specifically about Hotwire, which can be used with Rails, Laravel, Django, etc. It's not a Rails course and also teaches Swift + Kotlin and how to use them to build Hotwire Native apps.

@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.

A couple things come to mind:

1. Unless you have other things parsing the SQL, squishing it should be fine.
2. You probably add to the payload instead of modifying it.

event.payload[:squished_sql] = event.payload[:sql].squish

I think Phlex or View Component is mostly personal preference. Phlex will be all Ruby and View Component can be a mix of Ruby classes, ERB, and sidecar Stimulus controllers contained in the same folder. Either way you go they're pretty similar.

Guarantee you I've made this mistake many times over the years. 😅

Oh yeah?