Request for service: Global message broadcasting

Phoenix
1

Noticing the turn based game system in Elixir, I’d like to suggest building out a global message broadcasting service on Fly, officially.

The API would look something like

  • To publish to topic1 , do a POST to https://cast.fly.io/accountID/topic1 with the message in the body.
  • Use a EventSource or WebSocket on https://cast.fly.io/accountID/topic1 object in a browser or app to subscribe.

There are a few competitors in the space like PubNub, Fanout.io etc, but having this as an add-on on Fly with cost follows pricing (based on connected time and bandwidth) would be super-useful.

If this was built on Fly with Phoenix/Elixir it could accept connections close to the user / wherever there’s capacity and could distribute connections pretty well.

2 Likes
2

What kind of message API would you want for this? Is there a standard? Do you just want Fanout as an addon?

If I were trying to solve global message broadcast I think I’d be hesitant to adopt something specific to Fly.io.

3

Fanout as an add-on might work, but I don’t fully understand the consequences of their AGPL usage.

Examples would be stock market tickers (send stock prices to thousands of app viewers), live blogging (send posts to lots of readers), sports scores (broadcast JSON to millions of viewers), real time alerting (had a customer once who’d send messages all schools in the state), that kind of thing. Messages will usually just be JSON, normally under a few KB.

Phoenix should work great for this. If Fly doesn’t want to do something officially I can put this on my list of projects.

4

Would the already existing Consul cluster watch feature be useful here?

5

I wouldn’t run AGPL fanout, I think it would make more sense to have them be a paid addon. We know them!

I don’t think we’re going to build this ourselves. I do think we want to hook people up with stuff like Fanout (and charge them!) though.

If it were me, I’d use Fanout directly or run nats.

6

As habitual abusers of consul watch, it’s not very good. :slight_smile:

7

Good to know! I’ve had good experiences with redis streams, which might not be terrible to setup in Fly.

8

I would probably use NATs if it were me. It works really well across geos, vs something with a centralized “primary” source of truth.

1 Like
9

Yeah, options are NATS (can be standalone or embedded in Go) and Go / Node servers to amplify (hold tens of thousands of web sockets and send the messages on all of them. NSQ might also work.

Phoenix/Elixir can do this automatically, though. There’s an option to have Phoenix servers form a cluster and broadcast messages to all VMs in the cluster, and there’s also Phoenix primitives to broadcast messages to all actors (holding web sockets open) waiting on a topic.

10

Revisiting this topic - can you expand on ‘not very good’?