# Turbo Stream vs polling for updates

**URL:** <https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004>\
**Category:** General\
**Created:** [April 26, 2023, 11:03am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004 "2023-04-26T11:03:09Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![stooshie45](https://avatars.discourse-cdn.com/v4/letter/s/85f322/32.png) [@stooshie45](https://discuss.hotwired.dev/u/stooshie45)\
**Post date:** [April 26, 2023, 11:03am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/1 "2023-04-26T11:03:09Z")

</div>

Hi all,

This is more of a conceptual question to see how others might decide to handle this. I have a Rails app (recently upgraded to 7) which has historically been mostly static. Few tiny bits of JS here and there. It has about 150 users, and most of the features are what I would describe as being “single user” - i.e. CRUD resources for things that only the current user has access to anyway, so there’s very little need to update content dynamically.

However I’ve recently added a booking component, where users can book and pay for events. It works well, but most events have a max capacity so updating things like “X places left” and hiding the “Book Now” button when full would be great to do in real-time.

The question is whether conceptually it makes more sense to spin up Redis and use Turbo Streams, or just poll for updates when the user is on the correct page and use Stimulus to reload the frame(s)? I’m just not sure I want to added complexity and cost of ActionCable/Redis when simply reloading the frame every, say, 5 seconds would be workable.

It feels overkill to have extra infrastructure just to manage this relatively small thing. I’d appreciate some thoughts on the topic.

Thanks!

---

<div class="post-metadata">

**Author:** ![roincent](https://avatars.discourse-cdn.com/v4/letter/r/ba9def/32.png) [@roincent](https://discuss.hotwired.dev/u/roincent)\
**Post date:** [April 26, 2023, 3:10pm UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/2 "2023-04-26T15:10:11Z")

</div>

[Mecure](https://mercure.rocks) is a really simple and reliable solution for real time feature.  
You can implement it via Stimulus : [Mercure.rocks: Real-time APIs Made Easy](https://mercure.rocks/docs/ecosystem/hotwire#creating-a-stimulus-controller)

---

<div class="post-metadata">

**Author:** ![evenreven](https://yyz1.discourse-cdn.com/flex027/user_avatar/discuss.hotwired.dev/evenreven/32/1867_2.png) [@evenreven](https://discuss.hotwired.dev/u/evenreven)\
**Post date:** [April 26, 2023, 8:42pm UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/3 "2023-04-26T20:42:38Z")

</div>

Hard to answer, it’s a trade-off. I’m in more or less the same boat (mostly static app that got a booking component recently), but I was already using Redis as both cache store and sidekiq instance, so expanding it for ActionCable purposes wasn’t that big of a deal. (I’m implementing CableReady now since it, unlike Turbo Streams, supports Rails 5.2 properly). So far it’s worth it for me, but for a small site it should be usable to reload a turbo frame on an interval or whatever. There would probably be scaling issues with many concurrent users doing this. Then again, premature optimisation is bad, so… 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![stooshie45](https://avatars.discourse-cdn.com/v4/letter/s/85f322/32.png) [@stooshie45](https://discuss.hotwired.dev/u/stooshie45)\
**Post date:** [April 27, 2023, 8:29am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/4 "2023-04-27T08:29:27Z")

</div>

Yeah this is the thing, I don’t know if there’s a correct answer exactly, mostly just something to discuss with people who are also potentially in the same boat. I think I’m of the mind that right now, a reload of the frame is enough and like you said optimising too early isn’t a good idea.

For reference, here’s what I’ve done so far in case anyone else needs it. It’s based off a few other controllers and snippets I’ve found around the web.

Firstly, I’ve got a really simple ‘reload’ controller in Stimulus:

```auto
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static values = {
    src: String
  }

  connect() {
    console.log("Connected to reloader...")
    window.reload_interval = setInterval(function(obj){
      console.log("Reloading")
      obj.element.setAttribute('src', obj.srcValue)
    }, 7000, this);
  }

  disconnect() {
    console.log("Clearing reloader")
    clearInterval(window.reload_interval);
  }
}

```

That you can simply connect to any turbo frame with:

```auto
<%= turbo_frame_tag 'events_list', data: { controller: 'refresh', refresh_src_value: request.path } do %>
   <%= render 'fixture_grid_table', events: @all_events, title: 'Upcoming events' %>
<% end %>

```

I’m happy with a fixed 7s interval for all reloaders right now, but you could also add a second value to allow you to define that separately for each instance of the controller that’s loaded to make it more flexible.

I knocked this together very quickly, and it doesn’t ‘cost’ me anything in additional infrastructure or complexity. It’s very early for me on the Hotwire journey, but so far this is really very cool. Let’s you add a LOT of functionality with very little effort.

---

<div class="post-metadata">

**Author:** ![stooshie45](https://avatars.discourse-cdn.com/v4/letter/s/85f322/32.png) [@stooshie45](https://discuss.hotwired.dev/u/stooshie45)\
**Post date:** [April 27, 2023, 8:31am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/5 "2023-04-27T08:31:41Z")

</div>

Interesting, looks like that could pretty useful if I outgrow the polling solution. Thanks!

---

<div class="post-metadata">

**Author:** ![evenreven](https://yyz1.discourse-cdn.com/flex027/user_avatar/discuss.hotwired.dev/evenreven/32/1867_2.png) [@evenreven](https://discuss.hotwired.dev/u/evenreven)\
**Post date:** [April 27, 2023, 10:03am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/6 "2023-04-27T10:03:10Z")

</div>

Just a thought… Why don’t you reload just the turbo-frame on an interval? There’s also a builtin reload function for frames and since you attach the controller to the turbo-frame itself, you could just put `this.element.reload()` inside the setInterval. Unless I’m missing some complexity in your implementation, that is.

---

<div class="post-metadata">

**Author:** ![Wusinho](https://yyz1.discourse-cdn.com/flex027/user_avatar/discuss.hotwired.dev/wusinho/32/3186_2.png) [@Wusinho](https://discuss.hotwired.dev/u/Wusinho)\
**Post date:** [May 3, 2023, 5:27am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/7 "2023-05-03T05:27:32Z")

</div>

```auto
turbo_stream_from 

```

should do the trick

---

<div class="post-metadata">

**Author:** ![stooshie45](https://avatars.discourse-cdn.com/v4/letter/s/85f322/32.png) [@stooshie45](https://discuss.hotwired.dev/u/stooshie45)\
**Post date:** [May 3, 2023, 9:31am UTC](https://discuss.hotwired.dev/t/turbo-stream-vs-polling-for-updates/5004/8 "2023-05-03T09:31:45Z")

</div>

I actually tried that and ran into some issues, not sure why but setting the src works reliably, yet calling the .reload() function doesn’t? I’ll dig into it at some stage but for now I’m happy, it works.