Decoupling the front end and back end
As we previously mentioned, BMJ’s flagship journal, bmj.com, is on a Drupal 7 platform. That sits on top of the JCore (Journal Core) platform which hosts the scholarly journals provided by HighWire Press. Being a traditional CMS, the Drupal platform is a monolith that controls the website's front end and back end.
Our main task is to transition to a fully decoupled experience, which involves a complete separation of concerns between the content's structure and its presentation. Because bmj.com has multiple types of pages and experiences, our goal is to incrementally migrate pages of every type without disrupting the website's publishing activity.
Choosing the technology stack
The lead developer for bmj.com has been experimenting with static site generation over the last couple of years to better understand what tools are available. Based on this knowledge, he started experimenting and creating several different prototypes to better understand how the available tools could scale, and how they would function well for usage by BMJ’s editorial team.
Rather than going with a headless content management system (CMS), he decided to stick with WordPress because he knew it would be a smoother transition for the editorial team. Since other development teams within BMJ had already been working with React, choosing something similar was a good option.
The chosen technology stack was Node.js, Next.js, AWS (Lambda functions) and Vercel for deployment. Its main benefits include its ability to easily create plain HTML & CSS without the need for any particular framework to serve up content. Also, the tooling on the build and development sides are familiar for the team engineers.
Switching from Drupal to headless WordPress
Unlike Drupal, which has a direct integration with HighWire, WordPress needs an import script, so the development team decided to build one.
They created Atom4WordPress, based on the Atom Syndication Format. Similar to RSS, Atom is a web syndication tool which imports the metadata from the publishing platform, HighWire in our case, into the new WordPress platform we’ve created, using XML files.
Once a new article is published, the XML comes from HighWire using the Atom format. The script parses it, identifies any changes within the file since its last import, and sends its metadata to WordPress so that the editorial team can curate it.
We use Page.ly as a managed WordPress host. Page.ly is built on Amazon Web Services, and offers a fully-managed WordPress experience across a robust and scalable stack. We chose it because it’s flexible enough for developer usage and can sustain more traffic without sacrificing performance.
Vercel and Next.js
We decided to use Vercel and Next.js because we thought it would integrate well with our headless Wordpress and help us achieve the goals we had set out.
Vercel is a cloud platform for serverless deployment of frontend projects, similar to Netlify. Next.js is an open-source React framework built by Vercel and Google and Facebook to create production-ready and fast apps with many useful features built-in, such as server-side rendering (SSR) and static site generation (SSG). One great thing about Next.js is that it has ISG, which allows you to update existing pages by re-rendering them in the background as traffic comes in, blurring the line between static and dynamic.
Although we’re using Next.js mostly for the front end part, we’ve also built some back end functionality for some endpoints.
To date, we've migrated about 60 pages, 40 of which are static pages. Over the next few weeks, we'll focus on one of the three main types of pages on bmj.com
If you’ve also worked with Vercel & Next.js drop us a line, we’d love to exchange more ideas on the topic.