At several times in this thread (including parent comment) you refer to your service as a "push CDN". You compare it to Fastly in one response.

CDNs have many well-connected points of presence around the globe. They often route traffic through their own global/regional dark fiber networks to decrease latency.

If a Fanout customer buys the self-hosted package, obviously this won't be the case. But is it the case for your cloud service? How many points of presence do you have? Do you have an expansive network that you control, or are you yourself using a cloud provider?

We're an early stage startup, so some of our claims are aspirational. We're definitely not on the same level as Fastly today.

At present, we have one point of presence (California). We used to have another in Europe but we shut it down to save money. However we'll be reinstating it again next month. We're bootstrapped, so justifying the costs of expansion takes time. Long term we hope to have POPs everywhere.

We use cloud providers for our servers. Most of our workload is on Digital Ocean.

If you find the Fanout concept compelling, but have particular regional/latency requirements, it would be great to chat. Understanding demand may help us on the investment side, which may help us expand faster.

Hey, how is this diff from a simple WebSockets implementation?

A couple of main differences:

1) Fanout can proxy WebSocket client events as as series of HTTP requests to the origin server. This means you can use a normal web backend or FaaS to manage the connections, which is even simpler than having to write a custom stateful server process.

2) Connections are delegated to Fanout, and we handle 1-to-many propagation, for high scalability.

Socket.io also proxies websocket events as HTTP if needed.

So is this is basically socket.io as a service?

Interesting! Do you have a link to any info about this?

Edit: or, are you talking about HTTP fallback on the client side, when WebSockets aren't available? Fanout can do that too, but what I was talking about earlier was how Fanout can speak WebSockets to the client and HTTP to the server (like an inverted sockjs/engine.io).

No, the bit that is different about Fanout is that the HTTP servers don’t need to necessarily know about the fact they’re coming from a persistent connection. The backend servers remain as stateless HTTP servers.

Or MQTT over WebSockets?

Although we have not actually tested this, it should be possible for applications to make Fanout speak the MQTT over WebSockets protocol (and if this is not possible then I'd consider it a bug).

So it's not that the two are incompatible options necessarily, but that you could use Fanout to scale out such an implementation.

What is your own stack written in?

Edge server is C/C++ (based on Mongrel2, libcurl, and Qt), most everything else is Python. API is Django. We use ZeroMQ for internal messaging between processes/servers.

How do you compare it with PubNub?

PubNub is more of an end-to-end system. Clients knowingly connect to PubNub, and they can even publish messages to each other.

Fanout is primarily server-side tech. Clients don't necessarily have to know they are connecting to a Fanout-powered service, and only the server publishes messages.

Integrating with Fanout is a little more involved than PubNub, due to the need to set up an origin server, but the advantage is you own your API contract and avoid any lock-in. This can be particularly useful if your API is public.