100 lines
4.5 KiB
YAML
100 lines
4.5 KiB
YAML
uuid:
|
|
- value: dab1657a-80c4-4b6c-b7c5-28b874fff857
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T08:59:58+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: 'Dealing with different API versions'
|
|
created:
|
|
- value: '2025-04-05T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T08:59:58+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/04/05/strategies
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>I've recently developed a new custom module for a Drupal project.</p>
|
|
|
|
<p>It pulls in an initial set of data from an API, builds a block that includes a form, makes another API request based on the form selections and displays the result to the user.</p>
|
|
|
|
<p>Part of the API base URL is <code>v1</code> so I assume that, at some point, there could be breaking changes in the API response and the endpoint will change to be <code>v2</code>.</p>
|
|
|
|
<p>If this happens, I don't to have to change the existing code to make it work with a new version of the API.</p>
|
|
|
|
<p>I want to be able to write new code to work with the new version.</p>
|
|
|
|
<p>For the version 1 of the API, I've written a <code>V1ApiClient</code> that makes and processes the response from the v1 endpoint.</p>
|
|
|
|
<p>If we move to version v2, I'll write a <code>V2ApiClient</code> that will work with the version 2 response.</p>
|
|
|
|
<p>Each implementation will have its own logic but implement a <code>ClientInterface</code> to ensure both have the same required methods to make them interchangeable.</p>
|
|
|
|
<p>Then I can switch between implementations as needed and not have to change the existing code.</p>
|
|
|
|
<p>Similar to feature toggles, this allows me to deploy new code without making it immediately active.</p>
|
|
|
|
<p>I don't need to hold back merging changes until I'm ready to change the API version.</p>
|
|
|
|
<p>The same approach works in other situations, like payment gateways.</p>
|
|
|
|
<p>What if you need to switch to a different payment gateway or map service?</p>
|
|
|
|
<p>Instead of tightly coupling to one implementation, creating different implementations and strategies makes the code more flexible and easier if you need to change implementations or support multiple implementations at once.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>I've recently developed a new custom module for a Drupal project.</p>
|
|
|
|
<p>It pulls in an initial set of data from an API, builds a block that includes a form, makes another API request based on the form selections and displays the result to the user.</p>
|
|
|
|
<p>Part of the API base URL is <code>v1</code> so I assume that, at some point, there could be breaking changes in the API response and the endpoint will change to be <code>v2</code>.</p>
|
|
|
|
<p>If this happens, I don't to have to change the existing code to make it work with a new version of the API.</p>
|
|
|
|
<p>I want to be able to write new code to work with the new version.</p>
|
|
|
|
<p>For the version 1 of the API, I've written a <code>V1ApiClient</code> that makes and processes the response from the v1 endpoint.</p>
|
|
|
|
<p>If we move to version v2, I'll write a <code>V2ApiClient</code> that will work with the version 2 response.</p>
|
|
|
|
<p>Each implementation will have its own logic but implement a <code>ClientInterface</code> to ensure both have the same required methods to make them interchangeable.</p>
|
|
|
|
<p>Then I can switch between implementations as needed and not have to change the existing code.</p>
|
|
|
|
<p>Similar to feature toggles, this allows me to deploy new code without making it immediately active.</p>
|
|
|
|
<p>I don't need to hold back merging changes until I'm ready to change the API version.</p>
|
|
|
|
<p>The same approach works in other situations, like payment gateways.</p>
|
|
|
|
<p>What if you need to switch to a different payment gateway or map service?</p>
|
|
|
|
<p>Instead of tightly coupling to one implementation, creating different implementations and strategies makes the code more flexible and easier if you need to change implementations or support multiple implementations at once.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|