Decoupled Drupal Front-End UI
Drupal can be set up to provide customized REST endpoints that can also authenticate users to provide curated results to a decoupled front-end UI, such as ReactJS or VueJS. This gives the front-end much more flexibility in design and customizability, since it is no longer tied to Drupal Regions, Blocks, Views, and Theming constraints. Taking your Drupal installation headless gives you much more freedom with your front-end design and implementation.
Drupal will still provide its default layout for content moderation, so you only have to build for what the end-user will be interacting with. You won’t have to rebuild the administration side, leaving that exposed to authorized users who have permissions to moderate content.
Mobile Applications and 3rd Party Consumption
Setting up a headless Drupal allows your CMS to provide its data to multiple sources, including Mobile applications. This means no more “duplicated” content across environments and systems. Create it once in Drupal and consume it everywhere immediately. When it needs to be updated, simply update in one place, and it too is available everywhere immediately.
This approach can apply to more than just mobile applications. If you have clients who regularly consume data from you, this can streamline that process. Permissions can be set up in Drupal to allow only a subset of users to access any specific content type, and filter down to the individual Node level, if needed. You can provide any subset of data to any third party or application based on User Roles and assigned User Credentials.
Business Intelligence
Business Intelligence is huge when it comes to determining which content users find useful, which will provide ROI, and many other useful metrics. Decoupling Drupal allows for two key factors to assist in BI data gathering.
Specific Endpoints can be set up to collect data from the front-end, such as user-based consumption, liking, favoriting, bookmarking, ratings, and many other metrics.
Another set of Endpoints can be set up to provide the collected data to an ETL or other requestor for integration with data lakes or other BI models.
This means no more writing custom queries against databases from your ETL. No more large, stored procedures needing to be maintained on your Drupal database. Simply set up your ETL or BI model to pull data from a REST endpoint and use it as desired, leaving your BI platform to do the more important work of turning it into communicable metrics.
What’s the Lift?
If you are already managing, curating, and serving data through Drupal, integrating REST Content Builder functionality is a relatively straightforward integration that doesn’t require any types of data migrations and can be built alongside existing functionality without touching or modifying the existing functionality. As functionality is moved to a new unified front-end, your Drupal footprint can be reduced by removing several pieces of complexity from Drupal that drive the front-end experience, including:
Views
Entity View Displays
Custom and Contributed Themes, including complex pre-processors and TWIG templates
Custom and Contributed Modules that manage, insert, or manipulate front-end libraries and features
This does become a bigger conversation if you are not currently using Drupal and depends on if you are looking for a new place for new content or looking to migrate existing content from another system to Drupal and serve it from there. Switching to Drupal can especially benefit an organization that has content distributed across multiple CMS’s, giving you one source of truth and one location for content moderation and curation, reducing the overhead of content management.
Security
Decoupling Drupal from the front-end provides an added level of security to the content provided by Drupal.
Obfuscation
Headless Drupal means the end-user likely doesn’t know what type of system the data is coming from, since all they will see is the front-end technology. They also won’t know where that data is located, since it will likely be sitting on a secured server behind a VPN that can only be touched from “white-listed” applications within a network. Even if a bad actor could figure out the endpoint being requested, they still wouldn’t know what that system is built on, making it harder to attack and penetrate.
Granular Content Permissions
Roles and Permissions in Drupal can be moderated at an organization level or even user level, and then those permissions are set on the content or content types. For example, if you are a B2B organization that serves multiple businesses, you might have content that is only available to specific clients. Roles and permissions can be set up and applied to specific users associated with each organization, and then Drupal will internally check content permissions before serving it up. You could even go one step further and give certain members within a specific organization more or less access than the rest of the organization, with additional permissions and roles. All this is made possible with the passing of a user-specific API-Key in the header of the request.
Custom Error Responses
In many cases, data leaks can occur from requesting endpoints with incorrect parameters, headers, etc. Setting up a Custom REST Content Builder allows catching all errors and, in a worst-case scenario, simply returning a generic error message without leaking any sensitive information to the potential bad actor, including operating systems, user or content information, or even that it is being served up by Drupal.
Conclusion
Making your Drupal CMS a valuable and integrated part of your distributed MVC Framework may not be as simple as flipping a switch, but it is far easier than long-term management of data across multiple subsystems and is highly preferable to Drupal’s default front-end experiences when it comes to customizability. When you consider that you can then plug in endless consumers, the sky is the limit. Ready to start or continue your Drupal journey with Improving? Reach out to us.
