Transitioning a live app to a different cluster

We offer three clusters for Pusher apps, in the United States, Europe, and the Asia Pacific regions. You can read more about the release here or find about more about cluster configuration here.

It's only necessary to use these instructions if you need to transition a live application from one Pusher cluster to another without losing messages on any client.

The migration process involves multiple steps since clients may be connected to either cluster during the transition process.

Caveats

  • It's currently not possible to migrate applications using presence channels while maintaining the same state on both sides. Depending on your application this may be acceptable for a short period.
  • If you rely on channel existence WebHooks, things get complex since you'll receive WebHooks for both clusters independently.
  • If your application connects via a native client the transition period may be unfeasibly long due to the length of time it takes to roll out a new version to all your users.

We may address these shortcomings in future, please get in touch if they affect your app.

Transition process (using JS client)

  1. Change your server code to publish to both the old cluster and the new cluster API endpoints.

    Taking the ruby gem as an example, you'd need to create a pusher client instance rather than using the global configuration:

    pusher_old = Pusher::Client.new({
      app_id: 'OLD_APP_ID',
      key: '...',
      secret: '...',
    })
    
    pusher_new = Pusher::Client.new({
      app_id: 'NEW_APP_ID',
      key: '...',
      secret: '...',
      host: 'api-eu.pusher.com',
    })
    

    Then trigger all your events on both clients.

  2. Deploy the server change

  3. Change the js configuration to connect to the new cluster

    Pusher.host = 'ws-eu.pusher.com';
    Pusher.sockjs_host = 'sockjs-eu.pusher.com';
    var pusher = new Pusher('NEW_APP_KEY');
    
  4. Deploy the client change

  5. After waiting long enough for the js configuration change to propagate stop publishing to the old client.

If you're using private channels

During the transition period you will receive channel auth requests for clients connected to both the old and new pusher apps. Channel auth requests must be signed with the appropriate app credentials, but unfortunately no information is provided in the channel auth request to indicate which app is being used.

The solution is to adjust the Pusher.channel_auth_endpoint in step 3 above, and deploy server code which responds to auth requests on both the new and old endpoints, signing with the new or old client respectively.

In the JavaScript

Pusher.auth_endpoint = '/new_auth_endpoint'

On your server (Railsish example)

class AuthController < ApplicationController
  def your_existing_auth
    // Authenticate...
    response = pusher_old[params[:channel_name]].authenticate(params[:socket_id])
    render :json => response
  end

  def new_auth_endpoint
    // Authenticate...
    response = pusher_new[params[:channel_name]].authenticate(params[:socket_id])
    render :json => response
  end
end
Was this article helpful?
0 out of 1 found this helpful
Haven't found what you were looking for?
Submit a ticket