My ZuriHac 2014 project: Revamping snaplet-perf

Posted in: haskell, snap, zurihac.


My ZuriHac 2014 project: Revamping snaplet-perf

ZuriHac wrapped up yesterday, and needless to say, it was an amazing event. Bas and the other guys at Better really made an incredible job, and the response from the community was just amazing. It was my first hackaton ever, but according to the others this year ZuriHac had three times more people than the last year, which is, I think, really promising. Being my first hackaton, I wasn’t sure about the rules, so I ended up choosing a project thinking it was mandatory; in retrospective I regret not having just jumped in and out from room to room, to meet even more people than I did. Anyway, lesson learned! The project I choose was to revamp snaplet-perf. In this small post (mostly written at the airport) I’ll motivate my choices and finally show you a brief demo.

What’s snaplet-perf?

If you are not living under a Haskell-y rock, you probably know that there are at least three prominent web frameworks written in Haskell: Yesod, Snap and Happstack (list not exhaustive!). Snap 0.6 onwards introduced the concept of “Snaplets”, self contained “piece of functionality” you can plug to your application, in a sort of “off the shelf” fashion. There are many snaplets available on Hackage, so why did I choose snaplet-perf? When I first contributed to Snap one year and a half ago (here the full story) Doug Beardsley, one of the lead dev on Snap, gave me access to a private repository (i.e. snaplet-perf) within the “Snap Framework” organization on Github, so that I could contribute to the Snap ecosystem in a sort of “low-pressure” environment. Snaplet-perf itself seems to be a sort of “middleground” for new Snap contributors. Ok, but what it does exactly? The idea behind snaplet-perf is that you plug it into your application, and it will record the response time of all your endpoints, so that you can get some insights on your data (.e.g. endpoint X is getting slower over time etc).

What was there

When I joined the project, almost two years ago, what was there was just a tiny middleware layer which was saving the response time of the endpoint using a caching library called zoom-cache. The idea behind zoom-cache is that allows you to “zoom” into intervals of your data, making easy to focus on a particular period of your application lifetime. Seems neat, right? Unfortunately it turned out that for some reason snaplet-perf was slowly bit rotting, and here I’ll try to explain what I think is the cause.

What was my plan for the ZuriHac

zoom-cache turned out to be the elephant in the room. Talking with other developers which joined the project, they admitted to have being put off by the presence of zoom-cache. One week before the ZuriHac, I tried to make snaplet-perf compile again under GHC 7.8.2 before the hackaton, but several problems arose:

class Succ x y | x -> y, y -> x where
...

Note how it’s basically expressing mutually recursive functional dependencies.

What I got at the end of Friday

So the plan was to shave the yak a bit, fix type-level, fix zoom-cache and finally adding a nice UI on top of that, capable of showing real time graphs of the whole data. But sadly, after a day of head banging, all my solutions were going nowhere:

Considering all this points, and considering that it was an hackaton and that I should really have fun with it, I have decided to simply drop zoom-cache altogether and using acid-state for the persistence layer. If we really want, in the future, to support interval queries, we can do that using IxSet and an appropriate index on our stored date.

What I shipped

At the end of Sunday, I finally had a prototype which is working nicely; I didn’t feel bold enough to demo the whole thing (and I regret it, I should have probably done it!). This is the architecture in a nutshell:

A lot of this code was already there, I specifically did the worker overhaul (to use acid-state), the websocket part and the UI bit. The result can be seen in form on a small screencast here:

url

Note how is possible to monitor the new incoming traffic without refreshing the page!

Drawbacks

The drawbacks of the current implementation:

Conclusions

As every hacking project, is rough around the edges and can be polished further. I don’t know what the future of this project will be, as its diverging from the “official one”, but I hope Doug seeing this video will accept my beefy PR :)

Alfredo


Loved this post? Stay update!

Comments