How we picked d3js to draw SaaS metricsby Sebastien Mirolo on Fri, 1 Mar 2013
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.
- 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.
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
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.
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.