Real Time Web Apps
I’m starting to get serious about real-time web apps. At first I was considering using some of the Perl stuff (Meteor, Twiggy, AnyEvent, etc) to roll my own, but then I started looking around, and found a bunch of other interesting stuff to investigate:
- Firehose
- Firebase
- PubNub
- Pusher
The thing that’s cool about these services is that I can still write my apps using non-async stuff that I love (like DBIx::Class) and still get most/all of the benefits of an async web service.
[From my blog.]
My little part in the greater Perl world.
Could you provide some example application that makes use of Perl? The resources seem to be mainly based on JavaScript, so I wonder how a Perl backend could look like. Maybe one should not use Perl at all? ;-)
Mojolicious seems th have the most mature baked in support for async / realtime applications, so you might want to give that a go. Catalyst in the most recent stable release has the basics of async, but its still new and we have a handful off examples, not detailed documentation:
https://github.com/jjn1056/Perl-Catalyst-AsyncExample
If you wanted to try Catalyst and give me some reports, you could help make it better for everyone!
John
@Jakob: I'll be releasing Perl modules I made for both Pusher and Firebase in the next week or two. But in the mean time, my use case is like this:
a) Someone calls a web service to my web app, which is backended by non-async stuff like DBIx::Class.
b) You add something like this to your code:
after insert => sub {
my $self = shift;
send_message_to_pusher($self->message);
};
c) Meanwhile applications around the world are subscribed to the pusher queue, and they all get the instant event update from pusher.
That's, of course, a gross oversimplification, but I hope it explains why and how Perl is involved.
@john napiorkowski: Sorry, but that's exactly what I don't want to do. I'm not looking to write an async app. I'm looking to hand off the async stuff to a separate service so that I don't need to write an async app. Sorry if I didn't make that clear in my post.
Hi JT,
I'm the author of Firehose.io. The nice thing about Firehose is that its a plain' ol' HTML PUT request to a URL, which is the same URL that all of the clients are listening to.
Hit me up on Github or the Mailing list if you need help figuring it out, but it should be pretty simple (that's what I gun for).
Cheers!
Welcome Brad. Yup, I already set up Firehose and got it working. Pretty simple really. However, I think I've decided not to use it, cuz I'd rather pay someone else to host it for me. I'm probably not the typical user, I'd much rather pay to outsource services that I didn't write. Less phone calls at 4am for me that way.
I'm taking, "Pretty simple really," as a compliment. Thanks!
I've been thinking about launching a hosted version of Firehose.io for the very use case you mention. I know its too late to convince you to use Firehose.io (sunk costs!) but I'd love to know what provider and plan you ended up choosing if you don't mind me asking.
You're not too late. Drop me an email: jt at plainblack dot com