I recently had the opportunity to improve the UX on a client project by backgrounding a slow network request and broadcasting the response to the browser asynchronously with Turbo.

At first, I was a little overwhelmed because I didn't know exactly how to do this. The response was mapped to a Ruby object, and was not Active Record backed, so I wasn't sure how to leverage Turbo. However, I found it to be surprisingly easy, and I wanted to share the highlights through a distilled example.

Although we'll be focusing on network requests, I want to highlight that this approach works for all types of slow operations.

Here's an outline of what we're trying to accomplish.

Feel free to follow along below, or view the final code which lives in our Hotwire Example Template.

We'll start with a simple Active Model backed form where the user enters the ID for a record stored in an external system. Since the record is stored in an external system, we issue a network request to retrieve it. Note that the page can't respond until the request is processed, resulting in a poor user experience.

The controller and corresponding model aren't particularly interesting. The only thing worth mentioning is that we're calling in our controller, which issues the network request in-line.

It's worth highlighting that we're mapping the response from our network request to a non-persisted Active Model object.

The corresponding views are just as unremarkable.

With our setup out of the way, we can improve the UX by backgrounding the network request in a job which will allow the controller to respond immediately.

Our job is not only responsible for processing the request, but also for broadcasting the response back to the page.

In order to do this, we'll need to rely on some lower-level APIs provided by Turbo Rails and Rails.

Finally, we need to ensure we actually broadcast something to the page. We could build up the HTML by hand, but since we already have an existing partial, we can just call and pass in the partial path and object to build the content.

Since Active Job does not support Active Model instances as a type of argument, we'll need to create a custom serializer and make some changes to our application's configuration.

Finally, we need to add a corresponding identifier to our view to map to the option from above. We also need to add a element to the page so that it can receive the broadcast from our job.

With these changes in place, we should have a much smoother user experience.

If you were reading the last section and thought it was a smell to leverage all those low level APIs, you're right.

What we did was essentially recreate the API. We did this because we didn't have access to it, since it's only included in Active Record, and we're using Active Model.

We can dramatically improve our implementation simply by including it in our model, and calling .

I want to highlight that this works so seamlessly because we closely adhered to Rails conventions from the start. Most notably, regarding where we placed our partials, and the inclusion of in .

However, even if we hadn't, we could still have leveraged to control the broadcast without all the ceremony from before.

Finally, I wanted to share some pragmatic advice in regards to scoping the broadcast to the current user.

Since it's more than likely your application is using authentication, you'll want to scope these broadcasts to the user that issued them.

We just need to make sure to update our serializer too.

I used to think of Turbo as something that was exclusive to Active Record. However, as we just demonstrated, that's not the case.

Turbo can work just as seamlessly with Active Model-like objects, especially when you're closely adhering to Rails conventions.

Finally, this approach doesn't need to be limited to network requests. We can use the same pattern to handle any type of process that needs to be run in the background, such as a large calculation or query.