How we picked d3js to draw SaaS metrics

There are only few webapps that can do without displaying nice looking charts. This is even more so when you are running a Software-as-a-Service (SaaS) website. If you believe we are living in a knowledge economy as I previously described in Open source business models, this means we must search and are bound to find already made solutions.

This post started as the hunt for an open source solution to draw nice looking charts within fortylines django webapp but after much googling and experimenting, it was better re-written as an insight on how technical decisions are made. I hope you find the journey interesting.

First and foremost, fortylines business model requires that its entire SaaS solution can be deployed on an air-gap network. Most of fortylines bigger clients prefer to pay the extra cost and retain physical control of the cluster machines. This is an important requirement that ruled out many of the Google Chart API wrappers out there.

For consistency and to avoid many headaches, we also favor projects with BSD-like licenses and written in Python or Javascript (the two languages with picked for server-side and client-side code respectively). These were the guidelines when we started the search. Outside picking a specific open source project to build on, two open questions had to be decided:

• Should we do the rendering server-side or client-side?
• Which format should the graphics be rendered as (PNG, SVG, Canvas)?

The server-side way

First, if we did all the rendering server-side, it would be a lot easier to serve charts through different medium. Not only could we put the charts inside a web page but also embed them in a pdf, or an email, etc.

Charts being more in the graphics more than the photography cluster as far as image processing is concerned, it made sense to focus on producing a vector format (SVG) over a pixel format (PNG).

Ideally we are looking for python code that would transform a data model into a nice looking SVG file that we can later send to a web browser. Of course, browser SVG support being what it is, it is conceivable that in practice we have to resort to sending PNG images in the end.

All python solutions seem to either rely on the Python Imaging Library (PIL) or PyCairo, both of which are mostly bindings to a native C implementation.

Both pycha and BeautifulCharts are available through pip. A Pip search for charts also shows svg.charts, an MIT-style licensed package which looks promising though I couldn't figure out the prerequisites it is using for drawing the charts.

Since our search did not turn any pure-python solution, it is not far-fetched to look for chart applications that can be invoked on a command-line shell. We serialize the python data model then do some os.system call. If the quality of the charts is a lot better than the C/Python implementations, that might be worth it and won't introduce more Python to native dependencies that we would otherwise have. Suddenly something like ChartSVG, a collection of XSLT scripts that creates SVG charts from XML file, could fit the bill.

The client-side way

Google Chart API out of the equation, we were looking for full javascript libraries here. There are surprisingly an amazing pool of fully features chart library written in javascript though most of them have a commercial license with different restrictions on how you can use it for free.

amCharts and HighCharts, both have been packaged with fanstatic, a python framework to manage javascript dependencies if that matters at some point. FusionCharts charts also look really good.

d3js is not technically a chart library but it appears in many related searches. D3js deals with the much broader scope of data visualization (see here for pointers). Making charts using d3js can be quite complex but a gallery of examples exist and d3js is released under a BSD license.

The choice

The visual quality of the charts produced by client-side javascript libraries appears to be a lot better than their server-side python counterpart. If we keep bent on generating the charts server side because we care about caching, eldest browser support or simply using the same code to output monthly report PDFs, we will have to think about introducing nodejs in our back-end stack. Visual quality matters.

Fortylines builds a trace visualization tool not unlike GTKwave, though it runs in a web browser and supports the iPad touch interfaces. It is only the beginning as more rich and interactive trace analysis tools will make their way into the web product. So sooner or later, we are bound to introduce an interactive data visualization library in our stack.

If we need a data visualization library at some point and all the best charting libraries come with restrictions, we might as well pick d3js. A side advantage is that we add a single dependency and only need to learn one API.

That is how we picked d3js, an unlikely candidate, to draw charts for fortylines SaaS webapp. Later we found a chart library based on d3js - just amazing.