Technology choices [Alpha]
A guest post from David Carboni our Technology Lead and Movember survivor..
If you’re curious about the technology behind the Alpha website, here’s how we did it.
Principles
We had a couple of principles in mind to guide our decisions. Here are the ones that stuck:
Do less
Adding complexity multiplies difficulty. Subtracting a little now saves a lot of pain and protects options for change. It’s remarkable what can be achieved by keeping things basic – and by deleting
API-first
The server should focus on data and services, the browser should focus on presentation and user experience. Keeping a clear distinction and focus was even more effective than we hoped.
Pause for design
Probably the most dangerous words in design are “could we just quickly do [X]”. We made an effort to invest a little time to pause, reflect on the right answer and aim for that. Build with urgency, not with haste.
Minimise distraction
Humanly, we tried to avoid interrupting each other, technologically, we used continuous integration and automated deployment. We also made sure our code was reloadable because we wanted changes to be seen with no more delay than a browser refresh.
Technology:
These are the technologies we decided on to build the Alpha:
Server side
Java and JSON. Java was a natural choice because the ONS operations team are familiar with it (the current site is built in Java). It’s also the language our Alpha team had most experience with and there’s a great ecosystem of libraries, tooling and support. Json was a natural choice – a defacto Web standard with solid support both server-side and client-side. We decided not to use a database because it’s one more moving part and an additional piece of complexity to manage. Using Json files made data very concrete and direct to view and fix. This was well matched to the pace and scale of Alpha and will move on in future.
User side
HTML, CSS, Javascript – Angular JS.
For the user interface we focused on Web standards. Web browsers are now, on the whole, a standard platform for the delivery of user interfaces. The ONS website is not fundamentally a single-page application, but Angular enabled us to rapidly prototype, building the application directly in the browser. This will change in future, but has been invaluable in delivering a lot more functionality in the Alpha than we expected to be able to.
Github, Maven, Travis, Heroku
Our source control, build and deployment pipeline has been fantastic. The scale of effort we didn’t need to spend on operations has been superb (bearing in mind that live operations is an entirely different proposition from Alpha development). When it comes to prototyping, the more effort and attention can remain focused on iteration and development the better. The source code is held in a public Github repository, Maven is a natural build choice for Java, Travis-CI provided continuous integration and integrated really well with Heroku, which provided an ideal platform for deployment. In future the plan is to investigate other cloud options via GCloud but for now, this pipeline was spot-on for our needs.