Drupal's API-enabled architecture—one the main reasons why we at Evolving Web use this system—opens up infinite possibilities for a decoupled Drupal, separating its back-end CMS from its front-end theming system and giving us the tools to use our Drupal installation as a content hub for various technologies and applications.

In this two-part article, we'll look at the three application types you should consider, examine key decisions regarding how your application will function, and offer some additional resources to get your implementation started.

👩‍💻 Check all of our upcoming Drupal training courses!

Choosing an Application Type

Which type of web application to build the front-end is a key decision in planning a decoupled Drupal platform. There are currently three types of web applications that you can choose from:

• Single-page applications - Characterized by having a single HTML page with content retrieved and rendered on the browser via Javascript. A single-page application is ideal for creating an application-like user experience in the browser, with seamless transitions and fast response to user interactions. Because it loads all of the code and data at once, it's important to consider the audience's tolerance for the initial page loading time and to be aware of potential SEO issues.
• Server-side rendered applications - Content is returned on the server during the initial page load, while subsequent requests render content on the browser, much like single-page applications. Choose a server-side rendered application for a more conventional user experience with easy dynamic content, personalization, and SEO.
• Static site generators - All website pages are rendered ahead of time, rather than at runtime. Users are served static HTML files without any calls to the CMS or rendering processes. Consider a static site generator for largely static, content-driven sites that don't require heavy personalization or real-time updates. An SSG can provide significant performance improvements and reduce security and hosting challenges for these sites.

A Detailed Review of Application Types

Each type of application has its strengths and weaknesses. When I plan my client projects, there are a few criteria that I find to be the most important:

1. The degree to which pages render on the server and refresh in the browser
2. How well the application type handles dynamic content
3. How effectively pages can be personalized on a per-user basis
4. How SEO-friendly the application type can be

Now let's check in detail what each application type has to offer:

Single-Page Applications

In a single-page application (SPA), the browser retrieves the current data from the database, downloads all the application code upfront, and handles all page rendering on the client side. Subsequent data requests are handled seamlessly as the user interacts with the application. Users can navigate the site without any page refreshes, creating a smoother, faster, and more application-like experience.

Because the application queries the database, dynamic content and personalization are easy to include. However, off-loading page rendering processes to the client side reduces server loads.

A SPA does require the browser to download quite a lot of code on the initial page load, which can result in a user-perceived lag and increase the risk of abandonment. It is also important to note that while robots have gotten better at crawling SPAs, they can introduce SEO challenges, including the need to rebuild some standard Drupal functionality, like metatag generation, into the client-side code. It is important to carefully consider SEO requirements and test thoroughly.

Server-Side Rendered Applications

Server-side rendered applications (SSR) are very similar to single-page applications with a couple of exceptions.

With an SSR, the initial page rendering happens on the server. This allows the user to begin their interaction with the site or application a little more quickly, while the client-side application code loads. After that initial page loads, the subsequent rendering occurs in the browser using the same methods as a SPA. Since the page has been fully rendered on the backend, this option allows for a more SEO-friendly page.

What's more, because Drupal renders the initial page HTML structure, it's easier to manage and update SEO with familiar Drupal admin tools.

Static Site Generators

A static site generator (SSG) takes a very different approach. Pages are rendered as static HTML files, which are deployed to the hosting server; this provides a conventional site browsing experience, with refreshes occurring between pages. When a visitor requests a page, the appropriate HTML file is served and there is no data retrieval or rendering process.

Because there is no database query, the site should be regenerated when new content is added. Please note that it is technically possible to add code to rewrite parts of the page with dynamic content or personalization data, but this requires significant custom code and negates some of the performance benefits of serving static HTML documents. Additionally, programmatically replacing previously built content in the browser can cause confusion and problems with SEO.

Now that you know the different approaches you can take to build decoupled Drupal, it's time to go through some valuable tips to actually implement it. This will be covered in the second part of this article. Stay tuned!

Want to improve your Drupal skills? Sign up for our Front-end Drupal Developer Training Track!

+ more awesome articles by Evolving Web