These are chat archives for fanout/pushpin

10th
Feb 2017
Devin Fee
@dfee
Feb 10 2017 00:07
I just read a pretty good article about event-subscriptions from Facebook on their GraphQL blog (http://graphql.org/blog/subscriptions-in-graphql-and-relay/). They advocate subscribing to particular events (for instance, a client would subscribe to StoryLikeSubscription:($StoryId) to be notified of changes on StoryId (Facebook posts).
This exchanges logic complexity about who to notify of changes on the server – for subscription overhead with a platform like Pushpin. And this presents a challenge when building something like this chat (gitter.im/fanout/pushpin). Gitter notifies us of who has read the message – if they're also using the event-subscription strategy, I'm likely subscribing to an MessageReadSubscription for every message in this channel. What are Pushpin's limits in standing up to something like 10k people with 1000 subscriptions each (or more)? Does Pushpin support this strategy / architecture?
Devin Fee
@dfee
Feb 10 2017 00:22

I do see this from the docs:

As for vertical scalability, Pushpin has been tested reliably with 10,000 concurrent connections running on a single Amazon EC2 m4.xlarge instance. 20,000 connections and beyond are possible with some latency degradation. We definitely want to increase this number, but the important thing is that Pushpin is horizontally scalable which is effectively limitless.

But I'm wondering how many subscriptions each of those connections had?