77 lines
3.3 KiB
YAML
77 lines
3.3 KiB
YAML
|
uuid:
|
||
|
|
- value: c2ed3f01-0761-4b2a-a845-fccd30c84d57
|
||
|
|
langcode:
|
||
|
|
- value: en
|
||
|
|
type:
|
||
|
|
- target_id: daily_email
|
||
|
|
target_type: node_type
|
||
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
||
|
|
revision_timestamp:
|
||
|
|
- value: '2025-05-11T09:00:05+00:00'
|
||
|
|
revision_uid:
|
||
|
|
- target_type: user
|
||
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
||
|
|
revision_log: { }
|
||
|
|
status:
|
||
|
|
- value: true
|
||
|
|
uid:
|
||
|
|
- target_type: user
|
||
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
||
|
|
title:
|
||
|
|
- value: 'Drupal applications are modular monoliths'
|
||
|
|
created:
|
||
|
|
- value: '2024-10-21T00:00:00+00:00'
|
||
|
|
changed:
|
||
|
|
- value: '2025-05-11T09:00:05+00:00'
|
||
|
|
promote:
|
||
|
|
- value: false
|
||
|
|
sticky:
|
||
|
|
- value: false
|
||
|
|
default_langcode:
|
||
|
|
- value: true
|
||
|
|
revision_translation_affected:
|
||
|
|
- value: true
|
||
|
|
path:
|
||
|
|
- alias: /daily/2024/10/21/drupal-applications-are-modular-monoliths
|
||
|
|
langcode: en
|
||
|
|
body:
|
||
|
|
- value: |
|
||
|
|
<p>"Modular monolith" has been a popular phrase in the PHP community recently with talks, podcast episodes and courses released on the topic.</p>
|
||
|
|
|
||
|
|
<p>The idea is that instead of all the code being in one namespace, like App, it's split into different modules such as for payments or a blog - whatever is relevant and appropriate for that application.</p>
|
||
|
|
|
||
|
|
<p>Each module contains its own classes and structure instead of everything being mixed together.</p>
|
||
|
|
|
||
|
|
<p>If you want to change something about payments, you go to the payments module and you don't need to worry about anything else.</p>
|
||
|
|
|
||
|
|
<p>What's interesting is that this is how I've always built Drupal applications.</p>
|
||
|
|
|
||
|
|
<p>Each includes Drupal core and any contributed modules installed via Composer, and a specific directory for application-specific custom modules.</p>
|
||
|
|
|
||
|
|
<p>These modules can be separate and standalone or they can interact and have dependencies and sub-modules.</p>
|
||
|
|
|
||
|
|
<p>Each has its own routes, services, tests and more, making them easy to organise and maintain compared to having all the custom code in one large monolithic namespace or module.</p>
|
||
|
|
|
||
|
|
|
||
|
|
format: full_html
|
||
|
|
processed: |
|
||
|
|
<p>"Modular monolith" has been a popular phrase in the PHP community recently with talks, podcast episodes and courses released on the topic.</p>
|
||
|
|
|
||
|
|
<p>The idea is that instead of all the code being in one namespace, like App, it's split into different modules such as for payments or a blog - whatever is relevant and appropriate for that application.</p>
|
||
|
|
|
||
|
|
<p>Each module contains its own classes and structure instead of everything being mixed together.</p>
|
||
|
|
|
||
|
|
<p>If you want to change something about payments, you go to the payments module and you don't need to worry about anything else.</p>
|
||
|
|
|
||
|
|
<p>What's interesting is that this is how I've always built Drupal applications.</p>
|
||
|
|
|
||
|
|
<p>Each includes Drupal core and any contributed modules installed via Composer, and a specific directory for application-specific custom modules.</p>
|
||
|
|
|
||
|
|
<p>These modules can be separate and standalone or they can interact and have dependencies and sub-modules.</p>
|
||
|
|
|
||
|
|
<p>Each has its own routes, services, tests and more, making them easy to organise and maintain compared to having all the custom code in one large monolithic namespace or module.</p>
|
||
|
|
|
||
|
|
|
||
|
|
summary: null
|
||
|
|
field_daily_email_cta: { }
|