The nuts and bolts of our Ruby-based realtime charts solution
Scout's
So, how did we go about it?
Overview
The Scout agent runs a process on your server(s), sending metrics to Pusher's
So the essence of
- Scout-managed process on your server
- HTTP posts from your server to Pusher
Websocket connections between Pusher and browser(s)
In Code
Diagrams are for project managers, right? Here's how it looks in simplified Ruby code:
The Scout Agent (Ruby)
Javascript on scoutapm.com
So far so good – but what about session control and security?
Realtime Session Control
You initiate a
Under normal operation, the Scout agent sends data directly to scoutapm.com. Only when viewing a
Security
We need to be careful that only members of the originating Scout account have access to
Why didn't we roll our own?
We don't stream metrics unless you initiate a
We investigated two Ruby EventSource servers for handling web sockets: Cramp and Goliath. It was clear that just using Pusher was a much simpler path for our limited use case.
Also see
- The Scout agent's
Scout::Streamer
class (handles sending data to Pusher) - Pusher
- Smoothie (for our
realtime charts)
Takeaways
- Use Pusher. Rolling your own
realtime infrastructure isn’t trivial. Using a PaaS like Pusher lets you start focusing on the experience faster. - Easy to get started. You can use tools that you are already familiar with (Ruby + Javascript).
- Don’t be intimidated by
realtime . Is there anything in your product that can be enhanced byrealtime communication?