Hacker News new | comments | show | ask | jobs | submit login
Tell HN: I built a push service for HTTP APIs and want beta testers
18 points by jkarneges 2105 days ago | hide | past | web | favorite | 7 comments
Hi folks, I'm Justin. About 5 months ago I left my role as CTO at Livefyre to build Fanout, a publish-subscribe service for the web. It can be used to push data in real-time to browsers and other clients.

What makes Fanout special is its versatility. As an API/protocol guy, it occurred to me that existing cloud push solutions aren't well-suited for building APIs. For example, if you want to create and offer a real-time API like Twitter, Yammer, Digg, etc, then you pretty much have to set up your own infrastructure. Also, migrating to or between any of the existing solutions means having to update all client code to match. That's a very heavy transition cost, especially if you have any third-party consumers.

I figured there were probably other developers out there considering the cloud for push but having similar concerns about API feasibility and transition cost, so I've spent the last few months developing a solution that I now feel is ready for some beta testers.

Why should you be interested in Fanout?

Fanout allows for customization of the client/server interactions. This makes it possible to:

* Develop real-time APIs using HTTP streaming or HTTP long-polling. * Migrate APIs to the cloud without breaking existing consumers. * Keep using your existing client libraries. * Avoid proprietary protocols and associated vendor lock-in.

Of course, if you don't want to futz with designing protocol, Fanout additionally has its own JSON-based protocol and complementary JavaScript library that'll let you get off the ground quickly and is on par with existing solutions.

I'm currently letting a few developers access the beta, so if you're interested, please visit http://fanout.io/ and submit your email address. I look forward to hearing from you.




JSON protocol is exactly what I'm looking for. Will PM you with details.


Don't hate me for asking, I hate when people say this, but can you clearly explain to me this vs. Pusher? I use Pusher, so I'd like to know.


Hi there. The difference really comes down to whether you are building an API or not. For example, suppose you want to serve a live feed of data via long-polling as part of your public REST interface. This cannot be done with Pusher. If you don't have a public API, and your only consumer of live data is your own website, then this distinction is not very important.


Got it. Cool to know. Thanks for that. What are your plans with the platform?


The plan is to add more push mechanisms, like webhooks (so that APIs like Facebook's can be made), and in general to ensure the system remains flexible and versatile, so that the choice of using the cloud for push is not a hindrance or a compromise.


Very cool! Good luck with everything!


really don't think "push" is that hard to do...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: