I came across this repo the other day...
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...
- Only use it in development— such that we don't have to install a third party to make the real-time stuff work.
- 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.
- 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.
Top comments (9)
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 the key term here was option. Forem the company can use Pusher proper, and a smaller instance that want to be able to host everything themselves would potentially be able to use poxa.
3 all the way 😎
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:
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.
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.
Selfishly, I think it would be awesome if you used Poxa, because it appears to me to be the best option for a Pusher client-compatible server and would really give me confidence in using it in my own stuff :D
There is also Laravel Websockets which is branded as a Laravel-specific realtime library, but in practice is just a Pusher server alternative that works with any Pusher client.
beyondco.de/docs/laravel-websocket...
IMO Elixir was made for this exact thing so it would be cool to see more examples of real-time Elixir used in the wild besides Phoenix.
Beside scaling as highlighted by @molly_struve I have a few other concerns:
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):
Sadly none of those seems to support e2e encryption :-D
Any thoughts on noticed ? I have not personally used it.