Our Technology Stack
… or as my team colleague Jezen put it so eloquently and true at the same time:
In earnest though: We’ve been working on the application that enables our customer to invest money and reach their financial goals, for quite some time now. And all the time while doing this people kept asking what our technology choice is and how this choice has been working out for us.
So I’m shedding some light on the first question and we’ll cover the second question in a future series of posts.
Our application is currently a “classic” web application, in the sense that most of the heavy lifting is happening on the server side.
Basically we have a Scala- and Play!-based application on the server, with some Akka sprinkled here and there for the offline processing parts. In production this part is running as a standalone application, via an embedded Netty server and behind an nginx-based reverse-proxy.
We use PostgreSQL as our only persistent data store right now, even though we use Event Sourcing extensively in our application, which in some circumstances lends itself nicely to non-relational data stores.
require.js to modularize our code-base. Jezen wrote a
very nice overview on how to structure your modules in an easy yet scalable
way. As the DOM manipulation
library of our choice we currently use jQuery. We only
use very small parts of it, so it might get replaced by a smaller library at
For drawing the charts we use Flot. It was really great and served us well. It was ok to customize, but we somehow hit it’s limits already and as soon as we’re working on the graphs again, we’ll likely replace it with something based on D3.js.
Overall our tech stack is a nice mixture of proven technology and modern tools, that until now worked quite well for us.
As mentioned in the beginning of this post, we’ll continue sharing more details of our stack and architecture in the future.