What we’ve learnt about building a publishing platform

We’ve written in the past about our decision to build our own publishing platform, and the pros and cons that come with doing this. As a frontend developer, I’ve been maintaining and updating the frontend of this platform (a Javascript application known as “Florence”) since the launch, almost a year ago. We’ve also recently been focusing some time on refactoring Florence, so it’s fair to say that we’ve started to get a good idea of where the original codebase went wrong and what it got right. So, here’s a few of our findings, some technical and some not (warning, they might seem obvious!).

Having support from your team is important

This might appear like an odd heading for my first point, however, I have to mention just how valuable it has been that we have a product owner, service manager, chief publishing officer and so on who all appreciate the problems that technical debt causes. We’ve been given the time and freedom to get on with finding out what problems Florence currently has and how we’d go about fixing them. I’ve seen stories of how bad codebases can become when technical debt is never prioritised by anyone other than the developer. Well, that definitely is not the case in our team (high fives all round).

Clear application state is vital

This finding (along with others) may seem obvious, but the fact is that the application state wasn’t being managed well and this caused us issues chasing down bugs on many occasions. The original implementation stores some state in global variables, which couldn’t be observed for changes or stopped from being changed. Whilst other state for components are held in the webpage (or the DOM). The latter had caused us some real problems with state getting lost and mangled on really slow machines.

We’ve done spikes into implementing Redux, which is a fantastically simple library that makes it easy to stop state being mutated and allows you to observe state changes. It’s a clear winner to help fix our problems with state and we’re starting to build it into Florence at the moment.

The beta took a toll on Florence

Florence had to evolve very quickly to keep up with the regularly changing beta website. This meant that what it needed to be able to do as a minimum viable product grew constantly. This meant that the code wasn’t necessarily in the kind of condition you’d want it to be in. It also meant that by the time we’d learnt a lot about what we wanted Florence to do it was already being used to do daily publishing. It’s difficult to say we could’ve approached it much differently, but nevertheless it impacted how Florence was built.

Clever people have solved a lot of our problems already

We’re not the first people to build a Javascript application. Other people, who are far cleverer than us, have already made many of our mistakes and come up with libraries and techniques to overcome them. In short, let’s not reinvent the wheel if we don’t need to.

As an example, we initially set about building a prototype using vanilla object-orientated Javascript (JS) and a model-view-controller approach. We soon found that the overhead of writing vanilla JS, without a framework to help us, negatively outweighed the control it gave us. Essentially we’d learnt why so many other people had ended up building frameworks/libraries for single page applications.

Naturally, this has led us to exploring the vast range of Javascript frameworks and libraries. We’ve been using ReactJS to build the frontend for the Data Discovery alpha, so it felt like a natural choice to try out for Florence. It’s performance, community and kinder learning curve has made it the most suitable choice to use for the refactored code.

Spikes are useful

We’ve done a lot of spikes comparing different technologies, solutions and approaches. This might not be the right approach for all teams, but we found it helpful to be able to spend a bit of time exploring something without having to commit to it. Each spike would spark a lot of conversation and usually left us with a fairly clear answer to the questions we’d set out with.

It’s worth mentioning that we’ve learnt huge amounts about the limitations of the current build with the regular maintenance and updates we do for Florence. We also have great opportunities to explore new ideas or technology in our 10% time, when we spend one day a sprint working on something not necessarily related to our day-to-day tasks, like Google or BBC do. However, much of this knowledge has still ended up being applied when we’ve got round to doing the spikes.

Never fail, always learn

This is one of our Digital Publishing principles, so it’s good to see that it’s echoed in our daily work. At times we’ve invested quite a bit of effort going in a particular direction, and in some cases we’ve ended up deciding that it’s not the right way to go. We’ve learnt something new, so there’s no point persisting with something just because that’s the decision we made to begin with.

Write code that’s easy to delete

We’ve found that the way Florence has been written means it’s hard to pick out a bit of functionality and then try to rewrite it. There are lots of large components that are closely tied to each other, making it difficult to rewrite one without rewriting the other. For this reason we’d done a few spikes to attempt rewriting the most complex part of our application from scratch. After a few spikes we’d come away with an important realisation: we will never get it perfect and we’ll continue needing to refactor code, but we can make refactoring much easier for ourselves. If we build small components that are as loosely tied as possible, then we can more easily delete and refactor small bits of functionality without it becoming a mammoth task.

Other people have written about this too, so I suggest reading this blog post by programmingisterrible to further delve into this topic if you’re interested.

Building our own application was the right decision

It’s fair to say that our decision to build our own publishing platform has stood the test of time. We still have many more points in the “pros” column than “cons”, but we’ve learnt a lot about how our Javascript application should’ve been written. Fortunately we’re in a position where we have complete control over the codebase and time set-out for refactoring, so with some work we know we can gradually refactor components in the existing application.