What is Headless Drupal?
Comparison
Basic Drupal Setup
Drupal is usually used to manage content, no big deal. A typical Drupal use case involves having your frontend and backend on the same directory where you can manage them easily. This model is sometimes referred to as a monolithic structure which Drupal has been for the longest time. And it has been very effective in it’s uses but this model does not always fit to a particular project’s needs.
Decoupled Drupal
Advancements in technology have led to different needs and the same advancement has led Drupal to evolve. Headless, also known as decoupling or decoupled drupal is a method wherein Drupal is strictly used as a content management system. Drupal handles all the backend stuff while a different framework handles the frontend. This opens a whole new meaning in software development where the sometimes blurry lines between backend and frontend are made visible.
Some of the Benefits
Easy to upgrade
If you’ve been developing with Drupal, you may have already encountered a situation where you upgrade a backend related module but then it affects the frontend display. You scratch your head for hours only to find out that the module’s template is used by your teammate to style his contact form but the module update involves deprecating the functionality. Yes, we had those experiences.
With a decoupled drupal, you never worry about frontend when performing upgrades. Sure, it could probably still affect the admin theme or what not but what your customer sees is all taken care of by your frontend team. This is because what is transmitted to your frontend is only content data and no styling. You get to focus on backend functionality as you upgrade a backend related module.
Easy to troubleshoot
It’s also easier to troubleshoot in case of failure. Because there is a clear line between frontend and backend you will know right away where it failed. In most cases the frontend is hosted on a separate server from the backend. This is because your front end might be a framework which has different needs compared to your backend. The css and js are visible but there’s no content showing on the page? Then you can already know that it’s not a front end related issue.
Cost Effective Upgrades
Clients are different depending on the businesses they are in. For example a company that sells products to consumers are the ones who are frequently updating how their products are presented on their website. Their focus is more on the presentation side rather than on data processing. A conventional Drupal setup would require someone with both frontend and backend experience to work on updating the theme. In contrast however, a decoupled drupal allows you to deploy your new hires who have just learned basic html, css and javascript while your experienced staff are handling bigger projects at the same time.
Who’s going to work on it
How do you access the data?
Processing your data is the most important part of decoupling. If you do not have a team that has experience with both frontend and backend then it may be difficult to develop a decoupled system. This type of structure requires communication between the frontend framework and the backend. In recent updates, Drupal has introduced JSON API into it’s core which makes it more friendly to most frontend frameworks available but still you need at least one person who can plan the interconnectivity and security of these connections.
Hosting Provider
Another thing you need to consider is the hosting provider. Sure you’ve worked with Drupal but does your hosting provider allow the packets you request from another hosting provider to cross their network? Communicating to these service providers to ask for information will require someone from your team to be knowledgeable enough with networking and network security. That person doesn’t need a college degree, he/she just has to have a clear understanding of network security works. You can always hire a third party though but it’s an extra cost. It’s better just to find hosting providers that can host both your frontend and backend.
Filtering Content
If you have been this far, then I assume you have been developing with Drupal for quite some time. You probably have used the views contextual filter a lot which is really handy. When you’re decoupling, you will need to have someone who knows how to filter certain contents on the frontend side. There may be information from your backend that you don’t want to be shown on the frontend for some instances. Your frontend team must not only know how to implement designs but has to be very good with how to handle data fetched from the backend. Well, this is of course assuming that you have separate teams for frontend and backend but if not, this is no big deal.
SEO
The last and maybe the most important part is SEO. I’m not that knowledgeable with SEO yet so please bear with me. For your website to be known and rank first on search results, search engines must crawl your website for any information or keywords that they will gather to generate search results. But in a decoupled scenario, your frontend will most likely only contain static information about your site and that is the only information that search engines can gather. We have had experience with using metatags on most of our Drupal projects and as far as I know, javascript generated tags are not accepted by most engines. You need to have someone who can give you expert advice when it comes to SEO.
Do you need to decouple?
In conclusion, it all boils down to your needs or your client’s needs. There are great things you can achieve when you go decoupling but there are also drawbacks depending on the project you are working on.
You will need to decouple if you or your client is anticipating a frequent update on the frontend or if your application needs to be able to deliver the same contents to different platforms.You must have a team who are either experienced with decoupling or different frameworks or a team of developers who are open to learning new technologies.
Overall, decoupling opens a wide variety of possibilities but it is more efficient to handle decoupling with a team of developers rather than doing it alone unlike the conventional way of reducing the number of developers working on a single application which is what Drupal was originally designed for.
