These are chat archives for fanout/pushpin

5th
Nov 2015
Andre F de Miranda
@trixpan
Nov 05 2015 05:21
hi there. Quick one. Reading the doco isn't clear
how does pushpin achieve cross-node message replication?
supposing I want a one-way comms with WS clients and a single origin and I exceed what a single server can offer, what would be the best approach to scale out pushpin?
Justin Karneges
@jkarneges
Nov 05 2015 05:22
@trixpan: pushpin instances don't talk to each other. when your app publishes, you should publish to all instances
Andre F de Miranda
@trixpan
Nov 05 2015 05:23
jkaneges. Cool. That is what I was suspecting.
Justin Karneges
@jkarneges
Nov 05 2015 05:23
most of our publishing libraries make this very easy to do. you can put more than one target instance in the configuration, so that a single publish call goes to all
Andre F de Miranda
@trixpan
Nov 05 2015 05:24
thanks. Would be correct to assume then that the whole setup is stateless unless something is wrapped around?
Justin Karneges
@jkarneges
Nov 05 2015 05:24
yup that's correct
Andre F de Miranda
@trixpan
Nov 05 2015 05:25
jkarneges: and also no durability of messages / replay of old stuff
Justin Karneges
@jkarneges
Nov 05 2015 05:26
right. that's out of scope for pushpin. determining how to replay is a decision of your backend and db
Andre F de Miranda
@trixpan
Nov 05 2015 05:30
@jkarneges awesome! So in theory let say I have a push notification thing that sends messages to a web client / mobile app without any restriction (i.e. fully Public channels) I can do that by serving a fairly static php/ruby/whatever page with the proper Grip headers. Clients connect to that pushpin endpoint and hang to the connection. Meanwhile from a side channel I submit messages to pushpin using REST or the libraries and those messages get delivered for whoever is listening to the channel at that stage and discarded when the broadcast is done?
Justin Karneges
@jkarneges
Nov 05 2015 05:31
you've got it. :) the service picking up the phone (responding with grip instructions) doesn't have to be the same service publishing data
and pushpin throws the data away after sending. nothing is stored to disk or overflowing memory or anything
well pushpin does contain a minimal per client buffer (200k i believe). but if a client is slow to read and a message cannot fit, then it is discarded for that client
Andre F de Miranda
@trixpan
Nov 05 2015 05:33
fantastic stuff. That sort of answers my question regarding use of pooling for subscription
Justin Karneges
@jkarneges
Nov 05 2015 05:34
oh and yes, many clients can listen on the same channel and a single publish would go to all
Andre F de Miranda
@trixpan
Nov 05 2015 05:38
great stuff. And if I want to use fanout cloud same principle applies. Except I will have my answering machine on a separate URL endpoint that I control, instead of using the FanOut CDN?
or does the Fanout CDN effectively call my origin server in this case (Custom API)
Justin Karneges
@jkarneges
Nov 05 2015 07:50
the fanout cdn calls your origin server so it works exactly the same
and if you use a custom domain with the fanout cdn then you can switch between the cloud or self-hosted pushpin with no client changes
Andre F de Miranda
@trixpan
Nov 05 2015 09:30
@jkarneges : fantastic stuff. thank you very much. Expect a new account created soon. :-)
Konstantin Bokarius
@kbokarius
Nov 05 2015 22:38
@v1p java-gripcontrol 1.0.0 is published to maven and HTTP usage examples are in: https://github.com/fanout/java-gripcontrol
websocket examples to follow.
Vipul
@v1p
Nov 05 2015 23:24
@kbokarius : Thanks a ton mate! :) working on right away!