opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

Add daily email for 2025-01-27

Browse source 
Should you have a separate front-end for your Drupal website?
This commit is contained in:
Oliver Davies 2025-02-04 20:35:18 +00:00
parent 84c0906917
commit f62504aa8d
2 changed files with 34 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
source/_daily_emails/2025-01-26.md
View file

@ -20,7 +20,7 @@ The administration page usually looks nothing like what the page will look like
There is a page preview option, but this only works once the forms have been completed and requires the user to be able to "see" how the page will look beforehand and know what content will appear where.
This has only become trickier with the use of Paragraphs and entity reference fields, where the editor only sees the title of the content they want to reference but not what they will see or how it will look.
This has become trickier with the use of Paragraphs and entity reference fields, where the editor only sees the title of the content they want to reference but not what they will see or how it will look.
As well as being difficult to create content, it also makes it difficult to edit it.

33
source/_daily_emails/2025-01-27.md Normal file
View file

@ -0,0 +1,33 @@
---
title: Should you have a separate front-end for your Drupal website?
date: 2025-01-27
permalink: daily/2025/01/27/separate-front-end
tags:
- software-development
- drupal
- front-end
cta: ~
snippet: |
Should you have a separate front-end for your Drupal website?
---
A few years ago, "decoupled" or "headless" Drupal was a popular approach, leveraging Drupal's built-in JSON:API module to expose its data via an API which can be consumed by a separate front-end application.
The front-end application would retrieve the data from Drupal via the API and generate the appropriate HTML.
It's an approach I've used in the past and [spoken about at conferences][0], but it comes with pros and cons.
In theory, as the Drupal (or back-end application) and front-end are completely separate, there can be two separate and independent teams working on them.
This adds overhead and complexity and I've found that one team will commonly be blocking the other instead of both being able to work in parallel.
As I said yesterday, [previewing content in Drupal can be an issue][1] - particularly with a decoupled approach which needs a front-end to be rebuilt before the changes can be seen.
If you have a separate front-end, you'll need to create everything from scratch, such as writing accessible HTML markup and othe standard features that would normally be provided by Drupal and, because you've got two separate front-end and back-end applications, you've got twice the amount of maintenance.
You could also be excluding yourself from any new features that will be available in future versions of Drupal or Drupal CMS, such as the new Experience Builder.
Whilst decoupled/headless builds are a viable option and can work well in some situations, it's not something I recommend often.
[0]: {{site.url}}/presentations/decoupling-drupal-vuejs
[1]: {{site.url}}/daily/2025/01/26/layout-builder