These are chat archives for fanout/pushpin

Nov 2016
Nov 29 2016 06:59
@jkarneges So i took your advice and are moving away from sockjs. After trying out pushpin I ended up going for SSE with fallback to http streaming for IE. However I do want to make the api available not only for the browser but also consumable from a non browser client (like node.js). I am bit confused about this part, should i just let the non browser clients use the http endpoint (faking a browser) or expose something over tcp/zeromq endpoint?
Justin Karneges
Nov 29 2016 07:28
non-browser client should use the http endpoint, yes. "faking a browser" is a pretty strong way of putting it. many non-browser clients and servers interact using http-based APIs these days
SSE is a simple enough protocol that you can just document your API as such
however if you want to make it even simpler, you might consider an alternate endpoint (or choose via Accept header or query param) that returns one line per event
Justin Karneges
Nov 29 2016 07:35
BTW, there is an SSE client for node: . never used it though
I generally don't recommend exposing a raw tcp or zeromq endpoint as part of an API service. you could use things like that between components that power a service, but the outer API should probably be in the http family (meaning http or websockets)
Devin Fee
Nov 29 2016 21:33
After working with pushpin over the last few days, I'm looking to swap it into my dev stack in place of nginx. However, one nice thing about nginx is the nginx-proxy package which lets me proxy to services as they go up and down dynamically and it's helper docker-letsencrypt-nginx-proxy. How have you worked around this (in-)convenience?