In my first blog post, I introduced the Custom Elements module: A solution for soft-decoupled Drupal! Following that, I want to put more emphasize on the frontend side of the stack in this blog post:
Selecting a frontend framework
With the backend producing custom elements markup, we need a frontend framework that is able to work with that. While there are many frameworks that play nice with custom elements, we want to pick a well-established solution with a large user base. That way, it’s more likely that the framework stays relevant and well maintained on the long term. Also, finding more integrated libraries, learning materials or developers knowing the framework becomes much easier.
- Angular has been not liked much by developers that used it and won’t be used again by the majority of them (see survey). Besides that, it’s provided as a whole MVC framework with lots of things potentially not needed here. So not the best fit.
- Vue.js on the other hand, comes with template parsing built-in that is able to render custom elements data easily. Like React, it utilizes a virtual DOM and is well adopted and continuously growing. Finally, the Vue.js single file components are following a template based, web-standard oriented approach.
- Since web components build upon custom elements, they seem to be the perfect fit. However, they are not, since they are not well adopted and server-side rendering web components is not a well solved issue (yet?).
Thus, Vue.js turns out to be the ideal candidate for our decoupled Drupal stack built upon custom elements. Moreover, I like it for the following:
- It’s approachable and easy to use. It has great documentation and sticks to web standard oriented notations.
- It comes with a set of incrementable adoptable companion libraries for further needs, like routing or state management.
- It’s fast! It only weighs 20kB gzipped and scores well in rendering benchmarks.
- Just like Drupal, it’s a community backed open-source project, not depending on a single large corporation. Check out the Vue.js team and its sponsors.
Finally, it’s built upon a powerful, modular architecture and allows providing features as re-usable Nuxt.js modules – what makes it a great addition to Drupal. While the number of modules is nowhere comparable to Drupal, there are many useful modules available, like PWA generation, Google Analytics or Tag manager integration, or the usual frontend/CSS framework integrations with Bootstrap, Material UI or Tailwind CSS. Check out the module directory at modules.nuxtjs.org for more.
Nuxt.js deployment options
One of the nice features of Nuxt.js is that it’s really easy to deploy your project using various ways, all from the same code-base – just by a different deployment configuration. The options are:
Generate a static site and leverage the Jamstack approach for dynamic functionality and content previews.
Server Side Rendering
Render the markup using a Node.js server or Serverless functions.
Single Page Application
That way, one can choose the best suiting deployment target per project. Small sites without a large number of pages could be very easily statically generated and benefit from fast, cheap and secure hosting; e.g. via providers like Netlify, Amazon S3 or Github pages. If SEO is not required, running as a Single Page application does away the need for re-building after content changes and allows for highly dynamic, user-specific content and app-like UIs.
More demanding projects, requiring SEO and having a large number of content, can use server side rendering with any Node.js compatible hosting provider like Platform.sh or Heroku. Alternative options would be specialized hosting providers like Vercel, AWS amplify or deploying via the Serverless framework to various serverless cloud providers.
The frontproxy approach
Finally, I’d like to mention we also developed a custom, more advanced approach that becomes possible with custom elements markup: The lupus-frontproxy is a small PHP-based script that serves content as custom element markup combined with a pre-generated app shell (site header and footer). That way, large, content-heavy sites can easily run without a node.js server driving the frontend, while still providing decent SEO based upon the custom element markup delivered (Google just ignores custom elements and indexes the contained markup). However, with the rise of easy and affordable hosting options for server side rendering, such a custom built, uncommon solution seems unnecessary and not really worth the efforts.
Nuxt.js is a great framework that makes it really easy to build a Vue.js based frontend application that renders the custom elements markup provided by the Drupal backend. Since each custom element is mapped to a Vue.js component, it’s the perfect fit for building up component-based frontends, while keeping the editorial controls in the backend.
Thanks to its flexible deployments options, we can leverage static generation for smaller sites and use server-side rendering for larger, more content-heavy sites.
Since there are so many details more to talk about, I’ll be following up with further blog posts in the coming weeks, covering the following topics:
- Authentication & related architecture variants. Custom Elements markup & json formats.
- A developer introduction: Creating components, adding Custom Element processors, the relationship to Drupal’s render API, Custom routes and optimizing cache metadata.
- Handling blocks & layout builder, content previews, forms, caching & performance optimizations.
Finally, I’m going to talk more about this stack at the Drupalcon Europe 2020 in my session “Custom Elements: An alternate Render API for decoupled Drupal” at December 08 – 09:15 – so mark your calendars!