This post was originally published on Brandwatch's main blog on 20th June 2014.
Last year we launched our second product, Vizia, which is a second generation social media command center. Vizia is a highly flexible application for presenting the online conversation about your brand using beautiful real time visualisations.
Since it runs in a web browser it is highly portable, and functions just as happily on a mobile phone or tablet as it does on a 10 foot wall display or 4K screen.
Built with cutting edge open source technology, it really pushes the boundaries of what’s achievable in the browser today and has been great fun to build.
We’d like to share with you the technical details of the product; how it’s made, what it’s made with and how we ensure everything’s working smoothly.
So you’ve all now heard about Vizia, Brandwatch’s latest product. What you might not be aware of is the technical side of the operation. Who’s building Vizia and how? Let’s find out.
Firstly, this article would like to recognise the fantastic work done by our product owners and our clients for having the vision and spotting the use cases for this glorious offering. Consider yourselves recognised.
So let’s get the low-down on some of the tech we use to develop Vizia.
In terms of our release cycle, we work using the scrum methodology: developing in two week sprints, releasing new code every four weeks. We adopt and embrace all the scrum ceremony (meetings) too.
We consume our own Brandwatch API for the Vizia data and implement bespoke Vizia endpoints ad hoc.
It’s fair to say we love JS. Given that we all program in JS and we have the Brandwatch Analytics API doing all the heavy lifting of data, we found nodejs a perfect choice for our server code.
It gives us the power to implement composite data calls and keep data transformation on the server, without changing syntax.
Express, a node framework for creating web apps, was our choice for the server-side logic. It bundles with some nice sugar for configuring development/production mode settings, templating engines and routing.
Nodejs ships with its own module loading system. For a large, scalable client-side applications, having such a system is essential. We opted for requirejs to take care of our frontend module loading.
Speaking of modules, what about all those local copies of third party libraries clogging up the repository?
“Not today”. It quickly becomes difficult and stressful to maintain library dependencies on a large (or at least complex) JS application.
Luckily, npm and bower come to the rescue. These are package management tools for client-side (bower) and server-side (npm) dependencies. If your favourite library isn’t bower/npm ready, I’m sure the author would welcome a pull request.
What about separation of concerns?
Good question. We primarily use Backbone for our models and views, with event bindings handled in the views. Smaller modules are typically written in vanillajs.
Another bonus of the modular approach is testability. All our code is peer reviewed and all new behaviour is unit tested.
For Vizia, we use mocha’s ‘bdd’ syntax for structure and an expectation library written by one of our prized developers, Steve Mason.
Next up is source control. We’re all massive gits. Github is used for source code management, code reviews, merging of features and we all work from forks to keep the repos tidy. If you don’t already work from forks, work from forks.
Having our repos in github gives us instant access to CI server hooks. Jenkins listens out for changes and keeps a handle on continuous deployment of our integration and staging environments.
All this tech comes together to make Vizia the great product that it is.
There’s plenty more to come on the tech we’re using and how we’re using it, so do come back.