In April, I posted my last update on the programme of work to rebuild GOV.UK’s Publishing Platform.
Here’s an update on what we’ve been doing since then.
The Publishing Platform architecture
Recently we’ve been focused on iterating the roadmap for the Publishing Platform. We’ve revisited our architectural goals, and planned our work again. We’re migrating all of our publishing applications (like Whitehall) to use the Publishing Platform, so its performance is increasingly critical. We’ve validated our roadmap iteration with the product teams who will be dependent on the Publishing Platform for their work too. Visually, our roadmap looks like this:
In the very long term we’re planning to provide a write API and an improved public API from our Publishing Platform. This is point 5 in the vision that we shared earlier this year, and we have many goals to achieve before then.
In the future there will be lots of other requirements made of the Publishing API, and the rest of the Publishing Platform, which we can’t yet predict. That means we need to build an architecture that is easy to maintain and build upon, with enough flexibility that we can respond to whatever the needs might be. We will continue to undertake discoveries on ways to make the architecture easier for product teams to work on.
While we have been focused on revisiting our approach and priorities, we have still been building features into the Publishing Platform. We’re working on Govspeak at the moment. Govspeak is our version of Markdown, and publishers use it when they’re adding content to GOV.UK. It’s currently held in each of our publishing applications (Whitehall, Mainstream, Specialist Publisher etc.) so now we’re moving it into the Publishing Platform. This is so that all publishing applications will have the same Markdown functionality - parity of features - and so that we are only maintaining it in one place.
Progress on Whitehall migration
So far we have migrated 8 Whitehall formats to use the Publishing API.
We're working on 21 formats - that leaves us with 14 formats to go.
The Whitehall formats are listed under 'Core' here:
We're recording changes in the performance of the Publishing Platform following the rebuild. As we look to simplify our code through this process, we expect to see performance improve too.
We've already seen a significant change with respect to our front end code. So far we have recorded that our CSS and javascript are loading up to 51% and 27% faster, respectively. So our front-end (what the user sees) is now loading much more quickly than before we began this programme of work.
Specialist Publisher rebuild
Specialist Publisher was migrated to use the new Publishing API and the single database some months ago. We’re also rewriting it as the old version was unnecessarily complex and it was hard for developers to make changes easily. Rewriting an application isn't a decision we take lightly.
We're about to start the work to migrate our first ‘Finder’ to go on the new version of Specialist Publisher. As with the rest of the technical work we’re doing, publishers shouldn’t notice the changes we’re making. As much of this content is sensitive or critical in nature, we’ll be making sure that we have plenty of testing in place to make sure everything goes as smoothly as possible.
What’s next
We’re aiming to complete the migration of Whitehall Publisher in the next few months, as long as we don’t find any further major technical challenges to overcome.
There are also a few tricky and one-off type formats in Whitehall that are out of scope for now. We will need to pick these up after we’ve migrated Mainstream Publisher, which is next on the list after Whitehall publisher.
We’re doing the work on Finders at the same time as the work on Whitehall. With the rebuild of Finders looking like it will be live in late summer, we’ll then be focussing on the Manuals format. This will then complete the work on Specialist Publisher.
And, once all of that is done, the task is then to consolidate the databases of each publishing application into a single database. This is so we only have to maintain one database for all publishing applications, which is much more manageable and reduces the risk of error. A single database allows us to then prioritise our longer term goals; publisher workflow, GOV.UK as it’s own archive and APIs for content and publishing.
