loading...

Explore Poxa as an open Pusher implementation?

ben profile image Ben Halpern ・1 min read

I came across this repo the other day...

GitHub logo edgurgel / poxa

Pusher server implementation compatible with Pusher client libraries.

Build Status Inline docs Release Docker

Poxa

Open Pusher implementation compatible with Pusher libraries. It's designed to be used as a single registered app with id, secret and key defined on start.

How do I speak 'poxa'?

['poʃa] - Phonetic notation

[posha] : po ( potion ), sha ( shall )

Features

  • Public channels;
  • Private channels;
  • Presence channels;
  • Client events;
  • SSL on websocket and REST API;
  • Simple console;
  • REST API
    • /users on presence channels
    • /channels/:channel_name
    • /channels

Development

Poxa is a standalone elixir server implementation of the Pusher protocol.

You need Elixir 1.9 at least and Erlang 21.0

Clone this repository

Run

mix deps.get
mix compile

The default configuration is:

  • Port: 8080
  • App id: 'app_id'
  • App key: 'app_key'
  • App secret: 'secret'

Using Docker

Docker images are automatically built by Docker Hub. They are available at Docker Hub: https://hub.docker.com/r/edgurgel/poxa-automated/tags/

One can generate it using: docker build -t local/poxa ..

The docker run command should look like…

It seems maintained, well-thought-out, and seemingly used in production.

Currently we have a hard dependency on the closed source Pusher, and it would be nice if we could break this as we have other stuff.

The easiest way to break our dependency would be to use a compatible open source version that more or less plugs right in, I'd think.

There are a few options for how we might make use of this...

  1. Only use it in development— such that we don't have to install a third party to make the real-time stuff work.
  2. Use it in dev an as an option in prod, but we can still use the real Pusher for our infrastructure and as a suggestion in prod.
  3. Go all in on using this in dev and prod and work with this project for all of our needs if we run into problems at production scale.

Our other options for moving off Pusher to go full FOSS would require more substantial rewrites, so going with a compatible library like this seems really cool!

A good part of my reluctance to add more real-time functionality is the fact that we're currently writing our code against a closed-source API, so if we'd eventually move in the more fully open source direction we wouldn't want to create more surface area for a future rewrite.

I played around with it myself and got it sort of working... I'd be curious to hear peoples' thoughts on this.

Posted on by:

ben profile

Ben Halpern

@ben

A Canadian software developer who thinks he’s funny. He/Him.

Discussion

markdown guide
 

I would like to propose mercure.rocks/ for this, it does not have pusher compatibility but I think it is a good alternative, it supports end-to-end encryption, authorization, refetches. Personally I also like the fact that it is written in go as this makes it really easy to deploy on would not need to install any dependencies, the only thing that is required is the compiled binary.

 

My one concern would be ensuring that this could handle the scale that we need it to. Probably would want to do some load testing on a server but with that said I think IF we decide to use this the only way to go is all the way. I would vote #3

 

The good thing is that if we run into problems we could always swap in Pusher after we've failed.... But if we tried to do it this way, then we control the cost structure more for higher upside in the long run.

 
 

I think this is a very cool idea! Anything you need that Poxa doesn't offer you can add to the repository, which helps everyone, or you could even have a forem fork down the road.

A couple of concerns:

  • There have been no updates to the code base this year, other than automated ones.
  • There are some [WIP] pulls that have been open for 5 years.
  • It doesn't have the best documentation in the world.

As a test of sorts it might be worth adding an issue asking about one of the missing features, maybe the push notifications API @rhymes noted was missing, and seeing what the turn around is on getting a response.

 

Beside scaling as highlighted by @molly_struve I have a few other concerns:

  1. what would be a potential plan in integrating, modifying, tuning and if needed, forking, a real time server written in Elixir?
  2. I don't think it supports the push notifications API that Pusher has (not that's a big deal but if we want something to be 1:1 with Pusher we're already encountering a road block)
  3. I see no buzz around it, the community on GitHub seems quite small for such a critical piece of software. I searched the web but can't find much. This scares me a bit
  4. what happens if tomorrow Pusher releases a critical API update or breaks compatibility and Poxa is not up to date?

A possible alternative path: move off Pusher using another real time server gradually. We make a list of our needs (possibly also including transition to end to end encryption for messages which Pusher has but unfortunately the Ruby client doesn't support yet) and we find a open source "battle tested" real time server.

I understand rewriting here is not the best or easiest of solutions but currently we call the Ruby Pusher API less in just a few places around the code. What if, with feature flags, we start integrating a new server by wrapping those calls in a proxy object that sends them both to pusher and this new other server? We also call the frontend Pusher API in just a few files as well and we can build a wrapper to do the same: push messages to Pusher and to this new server.

We can then test it by activating the feature flag for direct messaging between two users, then for a group and so on.

A few possible alternatives with a decently sized community (I haven't tested any nor dug in deep into pros and cons of each but they have documentation and benchmarks):

  • AnyCable is ActionCable compatible on the client side and instead of using Rails for the real time part uses a Go server. So we'd be more or less compatible with verbatim Rails
  • Centrifugo which has quite a lot of features, written in Go

Sadly none of those seems to support e2e encryption :-D

 

Any thoughts on noticed ? I have not personally used it.