Phased Migration from Resizer v1 to v2
Phased migration is a strategy that you can use if you want to take a phased approach to migrating your images from Resizer v1 to Resizer v2. Note that this approach is optional.
Why do a phased migration from Resizer v1 to Resizer v2?
When moving to Resizer v2, you want to be build confidence that your custom front-end code is correctly resizing images at scale in Production. Rather than switching all of your website’s image requests to Resizer v2 at the same time, you want to be able to test the Resizer v2 implementation on a limited segment of traffic first, and roll it out to more traffic over time.
Technical approach
Currently, PageBuilder requires that you designate one code bundle to be live at any given time. All website traffic is routed to this live bundle.
Therefore, you must incorporate business logic into your live bundle to decide which Resizer to use. One possible approach is to allow only articles in an approved list of sections to use Resizer v2, while all other image requests use Resizer v1.
At a very high level, the technical approach is:
- Keep existing code that uses Resizer v1
- Add new code that uses Resizer v2
- Add business logic to choose whether to use Resizer v1 or Resizer v2 based on what section the story is published in. The business logic is:
-
Detect which primary section the article is assigned to (for example,
/politics
)if ((!shouldUsev1 && shouldUsev2) ||isAllowSection({section:get(data, 'taxonomy.primary_section._id')})) -
Keep a list of which sections are allowed to use Resizer v2 (for example, only
/lifestyle
and/food
are allowed to use Resizer v2)export const isAllowSection = ({ section = ''}) => {const allowList = [/lifestyle,/food];} -
If the primary section is in the allow list, use the Resizer v2 code to resize the image
-
If the primary section is not in the allow list, use the Resizer v1 code to resize the image
- (in this example,
/politics
is not in the allow list, so it would use Resizer v1)
- (in this example,
-
- When you’re satisfied with the Resizer v2 implementation:
- Remove the business logic to choose between Resizer v1 and v2 to instead always use Resizer v2
- Remove the code that uses Resizer v1 (since it’s no longer being used)