Feedback - Method and considerations for choosing between a full or gradual decoupling with Drupal

The Project - The Design and Development of an E-learning Platform

The project will go live at the beginning of June 2021. It is a learning site intended for medical students. It prepares students for competitions and exams through several learning and knowledge-assessment pathways. Most of the courses and features are therefore accessible to logged-in users, often on the move, and are presented as a work interface (multiple choice questions, questionnaires, knowledge checks, corrections, interactions with teachers.) The technical stack, which is based on Drupal, must nevertheless guarantee flexibility, performance, and adaptability in terms of interfaces. We naturally turned to frontend development with React. The main question was to determine, together with site administrators and contributors, where to set the "slider" for this decoupling... How far should the decoupling go given that the features and updates are likely to be numerous and impactful. Here, we share the key takeaways from our collective process.

Studying Progressive or Partial Decoupling

Progressive decoupling allows you to retain and benefit from the quality of the Drupal CMS to generate certain pages or content. At this stage, it is necessary to inventory all the pages/content types to determine which will be generated by Drupal and which ones will be generated in JavaScript (with React in our example).

The main advantage of partial decoupling is therefore to retain the benefits of Drupal's strengths, particularly in terms of:

• Error management;
• User management;
• Security;
• SEO optimizations;
• Accessibility compliance;
• The in-place editor;
• etc.

Thus, your interfaces will be rendered using mixed methods, enabling you to benefit from the power of the Drupal CMS and the advantages of the ReactJS service for certain pages. The main challenge is to define the ideal list of pages to be handled by React. As we will see below, this architecture can be implemented in 2 ways...

First Partial Decoupling Solution

The Drupal site is used for both backend and frontend.
Drupal’s back office usage will be prioritized for managing user accounts, their permissions, pages, content, and data.
Twig is used for 100% Drupal pages and Twig/React for "business" or functionally important pages requiring interactivity and performance.
URL management remains the responsibility of the Drupal CMS.

Drupal generates:

• The administration area (backend);
• 100% Drupal pages (with the Twig template engine);
• Pages including only certain React blocks;
• Empty Drupal pages composed of blocks and elements that call on React for their construction (100% React on a page generated by Drupal).

Second Partial Decoupling Solution

The Drupal site is used for both backend and frontend, just like in the first solution.
Drupal back office usage is prioritized for managing user accounts, their permissions, pages, content, and data.
Twig is used for 100% Drupal pages.
JSX is used for 100% React pages.
URL management is handled in React.
A JSON feed ensures data exchange between the Drupal backend and React.

• Drupal generates:
  • The backend;
  • 100% Drupal / Twig pages.
• React generates:
  • URL management;
  • 100% React / JSX pages.

The Possibility of Total Decoupling

Total decoupling makes the frontend completely independent from Drupal, using the CMS solely for managing users, modules, and content. Using React exclusively for interfaces allows for faster rendering and greater fluidity. React also enables generating a progressive web app (PWA).

Advantages of total decoupling:

• It strictly separates data from presentation;
• It enables parallel development: frontend developers focus only on rendering the interfaces while backend developers provide a RESTful API;
• It allows content distribution across several different platforms (web, mobile, connected devices);
• It ensures an enriched user experience: content is adapted to the device and target used.

Disadvantages of total decoupling:

• It is impossible to manage interface configurations through the Drupal back office (e.g., the order in a view sort);
• It is impossible to preview content before publishing in the Drupal administration area;
• The error and warning notification system is unavailable in the interface;
• This architecture does not support the advanced cache system offered by Drupal.

To sum up:

• Drupal is only used for the backend;
• URL management is handled by React;
• JSX is used for 100% React pages;
• Content is supplied via a JSON feed.

The Possibility of Supporting a PWA

PWAs load like regular web pages or sites, but can offer users features for interacting with mobile devices (offline content display, notifications, camera or device geolocation interaction). The user can have a shortcut on their screen and launch the app without going through their web browser.

Benefits of a PWA:

• The site becomes installable on mobile devices. This installation prompt is triggered when a visitor accesses the standard site;
• You can use Service Workers for caching and offline use of the website;
• The user is free to subscribe to notifications;
• Notifications can be sent to subscribed users when specific tasks are triggered;
• The site administrator can send generic notifications to all subscribed users;
• The site administrator can see subscribed users (user ID and subscription endpoint).

The Tests Done

To determine the best architecture, and after presenting the different solutions to the project committee (with the list and implications of the pages that React could consume), we tested all of these architectures. We chose partial decoupling with a Twig theme enriched with React applications for all parts related to user accounts (messaging, courses, history, statistics, shop, live classes). The anonymous part is managed 100% by Drupal.

We therefore decided on partial decoupling as described in solution #1 of this article.
The result will be available in a few days...