Of platforms and Javascript, of APIs and strings

For a very long time I've been intending to learn a better way of writing web applications. I had a very small potter with the the obvious candidate, but that didn't seem to work out. Screencasts don't make good tutorials, perhaps. There were a raft of Perl MVC web frameworks to look at, but that never quite worked out either.

When Fotango announced a competition - with prizes! - for the best Zimki application, though, I seemed to find enough motivation to do something new. Zimki is a Javascript-based hosted web development service. You write the server-side logic with Javascript, and there's a provided persistency framework, advertise RESTian web services and a choice of templating solutions (Trimpath's JavaScript templates and TAL). There's also a client-side library which uses MochiKit to allow you to make web service calls.

So, what to code? Well, I'd been intending to develop a small web app to keep an eye on the photos in Flickr pools for a while, and this seemed to be the ideal opportunity. Furthermore, Sven-S. Porst wondered if you couldn't get your group memberships in an alphabetical list. Seemed like the idea was sorted out then.

There's an entire other post to be written about the pitfalls I found in developing the app, but I'll have to trawl IRC logs to see what I was complaining about. Skipping to the end, the app got to a state where I was happy to submit it on the closing date of the competition, and here it is: groupr.

It's pretty straightforward really, but there is a bit of hidden complexity. Firstly, any request to the root of the domain checks to see if there's a Flickr authentication token in your session. If not, you're prompted to sign in (and shown a lot of explanatory text about it). If you are, you're directed to the groups page. Then your group list is fetched (and cached), and the main template is displayed.

As this is the first time you're looking at the page, none of the detailed information about the groups (most importantly, the photos in them) are available. I could fetch this all first, then display the page having done so, but that could take a while. Instead, once loaded, the page calls a web service (on groupr itself) that proxies through to Flickr, caches the result, then returns the photo data. (The caching means that, the second time you load the page, it's included straight into the template.) Hopefully this all works slickly enough that nobody really notices the difference between the first (AJAX) load and the second (cached) one.

Unfortunately, if I did this for all the groups I'm in (65 or so), it'd still take far too long, hammer Flickr's picture servers, and possibly swamp the client under the weight of HTML, so only ten groups are shown, with paging through to the other chunks of ten groups.

groupr's still under development; I'm looking at ways of showing more than just the most recent photos in the group, and also at persisting data so that you can get a list of photos you've not seen (somewhat like Flickr's "photos from your contacts" page). It's certainly a fun little app to hack on and a nice enough environment in which to do so. Plus, I'm still waiting to see if I win a prize. Which would be nice.