Top all-time · #7014
Fanout
Company blog · blog.fanout.iowebsystems
Fanout is the company blog at blog.fanout.io, writing about web and systems. Since 2012, 11 different Hacker News readers have linked it 49 times, most often “Fun with Zurl, the HTTP/WebSocket client daemon”. The last post was in 2022, but the archive is still widely read.
Too few sampled comments (2) to say how often HN recommends it.?
Why HN links it
HN commenters cite Fanout posts on long polling compared with Socket.io and on zurl, an HTTP tool. The linked posts are technical comparisons of real-time web approaches.
Summarised by Claude from a sample of 2 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Blog for all things Fanout.
Most-linked posts?
- Fun with Zurl, the HTTP/WebSocket client daemon2 people · 3 mentions · first linked 2014-02-18
- Long-polling doesn't totally suck2 people · 2 mentions · first linked 2013-03-04
- You might not need a WebSocket2 people · 2 mentions · first linked 2014-07-10
- Long-lived connections in a serverless world2 people · 2 mentions · first linked 2019-02-15
What Hacker News says?
This reminds me of a similar vulnerability in webhooks [1]. I never thought of throwing a POST request at Redis to muck with keys but I tried it just now and it totally works. Geez. [1] http://blog.fanout.io/2014/01/27/how-to-safely-invoke-webhoo...
Comment linking /2014/01/27/how-to-safely-invoke-webhooks/
on “How to steal a developer's local database”Submitted You might not need a WebSocket as a story · 160 points
HN discussionI love this kind of stuff. Awhile back I attempted to do similar benchmarking with Pushpin: http://blog.fanout.io/2013/10/30/pushing-to-100000-api-clien... Like the Pheonix test, this tested broadcast throughput. However we couldn't push more than 5000 messages per second out of a single EC2 m1.xlarge instance otherwise latency would increase. My theory is that we were hitting the maximum throughput of the underlyin…
Comment linking /2013/10/30/pushing-to-100000-api-clients-simultaneously/
on “The Road to 2M Websocket Connections in Phoenix”Submitted An HTTP reverse proxy for realtime as a story · 150 points
HN discussionWe did a write-up last year about combining our WebSocket gateway with a FaaS backend: http://blog.fanout.io/2016/09/29/serverless-websocket-chat/ The FaaS used in the article is Microcule, but the same approach should work with Lambda now that API Gateway supports binary.
Comment linking /2016/09/29/serverless-websocket-chat/
on “Support for tagging of Lambda functions and for the Python 3.6 runtime”Submitted How to safely invoke Webhooks as a story · 60 points
HN discussionPushpin could be good for keeping sockets open for the duration of a task without tying up threads in the webapp. http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-r...
Comment linking /2013/04/09/an-http-reverse-proxy-for-realtime/
on “Celery – Best Practices”Submitted Fun with Zurl, the HTTP/WebSocket client daemon as a story · 46 points
HN discussionI've upvoted your original post to see if that helps. The article does play up the compatibility with legacy frameworks. However, the proxy approach itself was designed independently of this, and the versatility turned out to be a bonus. Some background: http://blog.fanout.io/2013/02/10/http-grip-proxy-hold-techni... Basically, I'm positing that as a system gets larger, then moving the problem to an outer layer is g…
Comment linking /2013/02/10/http-grip-proxy-hold-technique/
on “An HTTP reverse proxy for realtime”Submitted Publishing JSON over XMPP as a story · 38 points
HN discussionSome discussion about handling webhooks with evil URLs: http://blog.fanout.io/2014/01/27/how-to-safely-invoke-webhoo...
Comment linking /2014/01/27/how-to-safely-invoke-webhooks/
on “Exploiting URL Parser in Programming Languages (2017) [pdf]”Submitted Make HTTP requests over ZeroMQ with Zurl as a story · 35 points
HN discussionYou can use Pushpin in front of Django (or any web framework, whether event-driven or not) to implement realtime features. http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-r... The thesis behind this architecture is that most realtime web applications can be reduced to request/response and publish/subscribe messaging patterns. Instead of looking at Django as a legacy framework, look at it as 50% of the sol…
Comment linking /2013/04/09/an-http-reverse-proxy-for-realtime/
on “Real-time applications and will Django adapt?”Submitted XMPP great for federation, not for queuing: a lesson from Livefyre's early days as a story · 31 points
HN discussionI think this sums it up: http://blog.fanout.io/2013/03/04/long-polling-doesnt-totally... I admit its FUD at this point
Comment linking /2013/03/04/long-polling-doesnt-totally-suck/
on “Socket.io 1.1.0 released”Submitted Pushing to 100,000 API clients simultaneously as a story · 16 points
HN discussionWe've built a pretty cool library for Express that makes it easy to do WebSocket stuff through Pushpin (a proxy server). http://blog.fanout.io/2015/03/09/stateless-websockets-with-e... Not that this was covered in the article, but it would be a reason to choose Express as the backend. It would be cool to build something similar for Koa though.
Comment linking /2015/03/09/stateless-websockets-with-express-and-pushpin/
on “The 3REE Stack: React, Redux, RethinkDB and Express.js”Submitted Building a realtime API with RethinkDB as a story · 9 points
HN discussionCongrats on the announcement. Templar looks like a great project. Re AMQP, I want to mention that our Zurl project does something similar, but with ZeroMQ. It leads to some interesting possibilities: http://blog.fanout.io/2014/02/18/fun-with-zurl-the-http-webs... Zurl is not an HTTP proxy though, but a ZeroMQ gateway. Templar with async responses would be much more generally useful to HTTP developers.
Comment linking /2014/02/18/fun-with-zurl-the-http-websocket-client-daemon/
on “Templar: A proxy to improve HTTP API interactions”Submitted Long-polling doesn't totally suck as a story · 9 points
HN discussionYes, Fanout works as a publish-subscribe service. Clients listen on channels (topics), and you publish messages to channels which Fanout then delivers to the right clients. In the case of HTTP streaming, Fanout acts like a reverse proxy in front of your web server. Incoming requests are relayed to your server, and you can control Fanout's behavior depending on how you reply. For example, you can reply with a "hold"…
Comment linking /2013/04/09/an-http-reverse-proxy-for-realtime/
on “Server-Sent Events: The simplest realtime browser spec”Submitted Show HN: Serverless WebSocket chat as a story · 8 points
HN discussionHey there. The main difference is that Fanout is invisible to clients. You explicitly choose the data transports and formats. This makes it well-suited for fronting public APIs, since you're in control of the interface. Our codebase is also open source. This article goes into good detail about the reference implementation for our HTTP transport: http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-r... Althoug…
Comment linking /2013/04/09/an-http-reverse-proxy-for-realtime/
on “Fanout.io Emerges From Private Beta, Provides Real-Time Push CDN”Submitted Realtime API Management with Pushpin and Kong as a story · 8 points
HN discussionI'd be curious to see how this compares with zurl http://blog.fanout.io/2014/02/18/fun-with-zurl-the-http-webs...
Comment linking /2014/02/18/fun-with-zurl-the-http-websocket-client-daemon/
on “REST Commander: Scalable Web Server Management and Monitoring”Submitted Five years of Fanout as a story · 7 points
HN discussionYou want this: http://blog.fanout.io/2013/04/09/an-http-reverse-proxy-for-r...
Comment linking /2013/04/09/an-http-reverse-proxy-for-realtime/
on “Ask HN: Is async request processing possible with Python Django?”Submitted You might not need a WebSocket (2014) as a story · 7 points
HN discussionSubmitted Mongrel2 HTTP server now in Debian/Ubuntu as a story · 6 points
HN discussionSubmitted Realtime Conference 2012 Recap as a story · 6 points
HN discussion
