How To Setup Your Rails Backend For Pusher

Updated Jul 24, 2024 • 4 min read

Pusher.js is ready to use SaaS providing websockets in multiple technologies. It may handle public, private and client events with or without the authorisation.

What You Will Use:

pusher gem - as server gem that is responsible for triggering events to clients (events may also be triggered between clients excluding server, but it demands more configuration that will be grappled with later).

Pros:

easy to set up,
support provided,
available for Ruby, iOS, Android and JavaScript.

Cons:

paid service (check out pricing here).

Step 1: Setup Initialiser

Pusher will be available as a global singleton object being set up in initialiser. You need to add pusher.rb to your initialisers that will simply define app credentials and enable encryption.

Step 2: Create Pusher::Dispatcher Service to Trigger Events

This step depends on your architecture of choice. I chose to have Pusher::Dispatcher class that will just trigger the Pusher singleton. Looks like overkill, but it's a good place to - say - calculate the channel's name based on some variables (e.g. user id).

Notice that the channel may be named as you like it - it is created and handled by Pusher on demand, there is no need to define it earlier. You only send events on channels via server and everybody who connects to your channel will get these particular events.

Step 3: Add Authorisation Endpoint

Authorisation in Pusher is very simple:

you provide an endpoint for authorisation to every client (e.g. on a frontend side or an iOS app),
when client wants to connect, it hits the endpoint with the client-side's defined params,
your endpoint should validate these params (e.g. checking the authorisation token) and authenticate the connection via Pusher singleton object with params of your choice - e.g. more data about the currently authorised user that will be shared among other clients connected to this channel.

Each client can define its authorisation endpoint during initialisation, e.g. in a frontend app or an iOS app, you can initialise Pusher with authorisation endpoint pointed out to https://myapp.com/api/pusher/auth.

Clients can also configure params that they are sending to that endpoint, e.g. you can send to your /api/pusher/auth endpoint the current user ID and auth token that is used in a frontend application.

Let's call our endpoint /api/pusher/auth. There is one action to implement.

Safe, easy and secure.

Step 4: Debug and Validate

You can easily debug and validate your Pusher implementation without any frontend at all. In my app, where there is basically no business logic, I created a simple endpoint that will trigger Pusher events on demand for testing.

Now, I can simply trigger Pusher events by using CURL:

curl http://localhost:3000/api/pusher/trigger?channel_name=test&event=myEvent

What is cool about Pusher is that it has excellent debug console available on web. What it means is that you don't need to have a frontend-ready solution - work on a backend till you're ready!

Go to your Debug Console in the Pusher dashboard, restart your server and observe if Pusher is getting the needed data!

Summary

You have set up all you need to embrace Pusher base possibilities fully. You can handle public, private and presence channel (private and presence demands authorisation). The events can be triggered easily, and you have a reusable Pusher::Dispatcher class. You've just learned about Pusher Debug console, which is a must-have in your toolbelt. Good job!