All Case Studies Design Development Interviews Our Way Project Management

How To Setup Your Rails Backend For Pusher

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

 

 

What you will use:

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

Pros:

  • Easy to set up
  • Support provided
  • Available for Ruby, iOS, Android and JavaScript

Cons:


Step 1: Setup initializer

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

See this commit as an example

 

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 e.g. calculate channel name based on some variables (like user id).

See this commit as an example

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

 

Step 3: Add authorization endpoint

Authorization in Pusher is very simple:

  • You provide endpoint for authorization to every client (e.g. on frontend side or iOS app)
  • When client wants to connect, it hits the endpoint with client-side defined params
  • Your endpoint should validate these params (e.g. checking the authorization token) and authenticate the connection via Pusher singleton object with params of your choice - e.g. more data about currently authorized user that will be shared between other clients connected to this channel.

Each client can define its authorization endpoint during initialization. E.g. in frontend app or iOS app you can initialize Pusher with authorization 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 current user ID and auth token that is being used in frontend application.

Let's call our endpoint /api/pusher/auth. There is one action two implement and you can check it out here in this commit.

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 simple endpoint that will trigger Pusher events on demand for testing. Take a look this commit

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 frontend ready solution - work on backend till you're ready!

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

 

Summary

You have set up all you need to fully embrace Pusher base possibilities. You can handle public, private and presence channel (private and presence demands authorization). You can easily trigger events and you have reusable Pusher::Dispatcher class. And you learnt about Pusher Debug console which is must-have in your toolbelt. Good job!

Follow Netguru
Join our Newsletter

READ ALSO FROM Websockets
Read also
Need a successful project?
Estimate project or contact us