Challenges

The project was full of exciting challenges! Let us highlight the most interesting ones:

# Hosting

Even though there are several PAAS/IAAS players on the market offering hosting for decoupled systems matching the requirements, we had experienced poor quality of service and uptime with many of them. This resulted in a monumental decision to move the project to our own Kubernetes cluster on AWS.

# Uptime guarantee

Our aim was to give the client a 99.99% uptime guarantee as well as extensive hosting customisation options should they need it. We used Terraform and Kubernetes on AWS for running the project workload across multiple servers in different regions. This helps reduce the workload for each server, because Kubernetes is quite smart as to where to send a request depending on the current load on each of the servers. In case of a huge traffic spike, adding several more servers to the cluster is a matter of few minutes and fully automated. Additionally, having each server in a different region makes the site resilient to outages, because Kubernetes routes traffic to servers in other regions dynamically.

# Full editorial control over page templates / content / URLs / SEO in a decoupled Drupal world

Concern Worldwide wanted to be able to create complex blocks (i.e. DOM elements) on each page regardless of the page type and be in charge of page templates, URL structure, redirects and so on. To solve this challenge we based the content building experience on Paragraphs and built a module called REST Entity Recursive to glue the streamlined Drupal editorial experience to the frontend application. For better visual reference between Paragraphs and the resulting components we provided preview images for each of the paragraph types.

# Decoupled Drupal Commerce

By the time we started, there were no solutions for decoupled commerce, neither were there any payment gateways ready for working with decoupled solutions. Therefore, we developed a new module called Commerce Decoupled Checkout to provide integration with Commerce module via the API. Moreover, we built three modules for payment gateways (for Paypal, Global Payments and Direct Debits) to accomplish the desired user experience around payments on the donation forms.

# Progressively responsive design

Some paragraphs (blocks) look completely different depending on the device type of the end users. We used the React.js framework to develop those different blocks and toggle their display based on viewport width and device type.

# Content migration from the old to the new site

The content structure changed dramatically between the old and new sites. The old content was long text with html, while the new system had all content divided into reusable paragraphs of different types. To resolve this challenge, we performed a very thorough mapping and data conversion exercise together with the client. Thanks to “Migrate” and “Migrate HTML to Paragraphs” modules we were able to provide a really robust migration experience and successfully moved thousands of pages in a largely automated fashion. During this exercise we submitted multiple patches to the existing open source solutions as none of them completely fit our use case.

# Content sharing between regions

Technically each region has their own copy of the project, which means they have their own database and their own version of the code. However, some of the content needs to be shared between regions, while other content needs to be entirely independent. We came up with a solution which allows sending selected pages (nodes) between different websites and resolve the potential URL / reference conflicts automatically.

# Reusable components

It often happens on long-term projects that designers come and go throughout, which can affect the look & feel of the site resulting in discrepancies with spacings, colours, behaviours and so on. To fix this problem of too many proverbial cooks in the design kitchen, our team developed a set of all React.js elements to build pages in a style guide hosted on a separate domain. It includes all buttons with their states, form inputs, colours, icons, typography, grid system and many more elements. Then, we built every block (paragraph of a certain type) based on those components. When that was done, the blocks were finally connected to the backend. So now if someone will ever change the padding of a button, it will change all over the website. The same goes for any other element in the system.

# Test coverage

While automated testing of Drupal websites is not something new, having to figure out what test approaches and frameworks to use to cover a decoupled project built in two different programming languages was an interesting journey. After some debates internally and conversations with the client, we decided to base test coverage on the Codeception framework. We leverage their API tests to cover API endpoints; end-to-end (acceptance) tests to cover the most critical user journeys of the frontend application, and finally, functional / unit testing to cover business logic on Drupal level.

# Minimal Viable Product

Who said that challenges can only be technical? Concern Worldwide had and still has a lot of ambitions for the project and it was a huge challenge to decide what should go into the initial project launch and what could be done later. This is especially true given the fact that the old site was in constant development over the past 7 years and nobody wanted a noticeable regression of its features. Thanks to the special relationship between the SystemSeed and Concern Worldwide teams allowing for very close collaboration, many open discussions around the business value were facilitated going into each epic, and we were able to launch the project well within the expectations of senior stakeholders.