Archive for July, 2007|Monthly archive page
As promised, here’s the post about the development process of the BeerRiot Facebook app.
Aside: Wow, rereading that last post about the Walled Gardens, I can’t believe I posted it. Totally fluffy lameness. Forgive me – this post will not be as bad.
I could very easily make this another post like others out there right now. Many people are upset about how unfinished the Facebook API is. Documentation is lacking (and only available online), specifications are weak, and test environments could be more feature-rich.
But, except for that little digression above, I promise, this is not one of those posts.
Instead, I’d really like to remark about how great it is developing this app in Erlang and Erlyweb!
There are nearly a dozen different Facebook API implementations – every object-oriented web language you can name. Facebook’s own official one is PHP5. I could have used the PHP version – Yaws comes complete with the ability to run PHP scripts. But, since the rest of BeerRiot is already in Erlyweb…
I rewrote the Facebook client in Erlang. And truthfully, it really wasn’t that bad at all. Erlang comes with very simple HTTP-communciation and XML-munging code. Hell, there’s even a simple way to compute an md5 sum. Once I figured out how to actually put together a proper POST and walk a rather verbose XML tree, the rest was just mimicking as closely as possible the official PHP scripts.
All this is not to say the process wasn’t without difficulties. Yaws’ standard url_encode proceedure doesn’t like nested io_lists very much, so I’m doing some ugly string/binary flattening. And, Facebook’s errors are nearly meaningless … but this isn’t about Facebook complaints. 😉
There are yet more benefits. Rather than dealing with cron firing up processes periodically, I have fully-supervised Erlang gen_servers up to date constantly with what data needs to be pushed out to Facebook. I can log into the running server and examine the current active sessions, monitor profile data pushes, etc.
Extending my existing Erlyweb application to handle new Facebook requests from the canvas page was even pretty simple (once I finally – I think – understood the Facebook session rules). Another controller, another view – bam!
One of my few real pains was source control. I may need to finally bite the bullet and leave CVS. I’m hearing good things about SVN. But that’s another topic.
So, chalk up one more win for Erlang/Erlyweb. Fantastic existing libraries. Quick development environment. Crazy server flexibility. I’m staying as long as I can.
Yes, I promised new things well over a week ago. My excuse is that I picked up a cold during my trip to the Middle of Nowhere that took me out of commission for a solid week. 😛 But, now that that is over…
I’ll probably talk more about how the development went in another post. Right now, though, I’m thinking over the whole “Walled Garden” argument.
For many of the apps, both the data source and the data sink reside inside the Garden – Facebookers talk to other Facebookers. For another large chunk, the data source is outside, but the sink is still inside – Stock quotes, sports scores, etc.
For BeerRiot, I’ve managed to allow the data source as well as the data sink to be on either side of the wall. Beers and comments added by Facebookers can be seen by non-Facebookers, and the other way around. Really, I’m just using Facebook something like an OpenID provider.
Of course, for some apps this isn’t necessary, and for others it may be impossible. But, it feels like this is the right way to think going forward. Using this method, there would be nothing stopping me from bridging more walls to connect more gardens together, while still keeping the web at large in the loop.
Okay, I’m about to fall asleep, and I can’t tell if this blog post is just simple fluff or not, but I’m going to post it anyway. Post in the comments if you like/dislike the FB app, what you think of Walled Gardens, or how bad this post really is.