Over the last several weeks, I have built solutions to the same web application problem using three approaches; a single page application (SPA), a WordPress plugin, and a Drupal module.
As background, the web application provides a digital signage solution where an administrator manages content, e.g., slide decks, to be displayed on one or more screens.
As a result of this exercise, I thought to share a high level perspective on each of the approaches.
Single Page Application (SPA)
My first approach was to develop a SPA (actually two) backed by a backend API. The source code is provided at:
GitHub - larkintuckerllc/futusign-spa
Contribute to futusign-spa development by creating an account on GitHub.
One big positive to this approach is that you start with nothing (literally a blank file) and bring in libraries / frameworks to achieve your goal; thus giving you a lot of flexibility.
Unfortunately, with flexibility comes complexity. First, you need to figure out which libraries / frameworks to use on the project and then you have learn to use them.
For example the backend API ended up using sixteen different packages and the frontend (admin) application used fourteen.
While I was writing the SPA, I happened to be working on WordPress theme for a client. It was this coincidence that led me to realize that the digital signage problem was just a content management problem (administrators managing content for broader consumption). As such, I determined that I could leverage the WordPress content management system (CMS) to build a digital signage solution. The source code is available at:
GitHub - larkintuckerllc/futusign-wordpress: WordPress plugin to manage and display digital signage…
futusign-wordpress - WordPress plugin to manage and display digital signage content
WordPress, being a CMS, provided a lot of ready-made functionality related to managing content, e.g.:
- Media Library: Ability to manage uploaded files.
- Custom Post Types: With the help of the Advanced Custom Fields plugin, one can easily create the administrative screens for inputting customized content.
- Content Management: Administrative screens for managing collections of content, e.g., filtering, deleting.
- Taxonomies: The built-in mechanisms that allow users to categorize post types can be leveraged to create relationships between post types.
WordPress has excellent documentation, both in the official WordPress Codex as well as in numerous answered questions in Stack Overflow.
Quite the opposite of the SPA approach, WordPress development is fairly simple as long as you are extending existing WordPress functionality (via PHP functions called hooks). Things, however, get significantly more complex as you try to implement completely new functionality.
About the same time that I was writing the WordPress plugin, I was invited to teach a 6 hour class on React / Redux at a Drupal event. I used that opportunity to spin up on Drupal development and create the following Drupal module:
GitHub - larkintuckerllc/futusign-drupal
Contribute to futusign-drupal development by creating an account on GitHub.
Drupal, like WordPress, is a CMS and such has much of the same benefits and issues that WordPress has. There are several benefits that Drupal provides over WordPress:
- Drupal, out of the box, allowed for simply creating administrative screens for inputting customized content.
- Drupal has direct support of relationships between content types.
- Much of the effort consisted of Drupal configuration (through the UI) and exporting functionality in the form of configuration files; made for quick and error-free development.
At the same time, there were several issues that I experienced:
- As there are big changes between v7.x and the recent v8.x; it was challenging to find relevant answered questions for v8.x.
- The official documentation was comparatively (to WordPress) confusing to me.
In the end, the WordPress Plugin ended up being the best development experience for this particular web application. WordPress’s CMS built-in functionality closely matched the application’s requirements and the data model was simple.
For content management web applications (administrators managing content for broader consumption) that have more complex data model, I can see where Drupal begins to shine.
For web applications that do not fit the content management pattern, I will continue to use single page applications (SPA) backed by a backend API.