Spike: Investigate Conditional CSS Loading with Fastly CDN for BoostLook Feature Flag System

[henryajisegiri]

Background

The new BoostLook implementation uses a feature flag to determine whether users see the
new or old site experience. However, the current Fastly CDN caching layer poses a problem:
pages cached with old CSS links won't dynamically switch to the new version when the flag
changes, and a hard browser refresh won't bypass Fastly's cache.

Goal

Understand and document a viable solution for conditionally serving the correct CSS version
based on the feature flag, without being blocked by Fastly's caching behavior.

Tasks

• Investigate how Fastly cache can be configured or bypassed for conditional CSS loading
• Explore other potential solutions as well
• Document the proposed conditional serving solution so it can be implemented and reviewed by the team
• Create a relationship diagram of the CSS pipeline to support team understanding and onboarding

Out of Scope

• Actual implementation of the solution
• Changes to the feature flag logic itself

Definition of Done

• A documented solution approach for conditional CSS loading through Fastly
• A CSS pipeline relationship diagram shared with the team

[sdarwin]

I would need to know more details about what is occurring.

Here are a few random comments.

1. If there are two different css files, such as boostlook.css and boostlookv3.css, then the cache wouldn't matter much, hopefully, since it would cache them separately, and each one would be correct. And different. No conflict.

2. If all css is stored together in one file, collectively, then it doesn't matter if the CDN caches it, because it's complete. It contains all the styles. For v2 and v3. Although maybe this makes no sense.

3. If there is one particular file that is problematic, it's not difficult to modify the caching rules in the account, to never cache the file, and always pass it through.

[sdarwin]

pages cached with old CSS links won't dynamically switch

Please explain more low level details: What is an exact affected URL? What should the css file be in each state? When using the feature flag, does that hide/show certain pages which would not be available to the general public, or does it modify the same page so it appears differently to different visitors? Or both?

Another fix: modify your local /etc/hosts file to bypass the CDN. This should be quite effective.

35.190.118.110 boost.org www.boost.org
34.111.60.243 www.cppal-dev.boost.org cppal-dev.boost.org
34.120.246.69 stage.boost.org www.stage.boost.org

[gregjkal]

When using the feature flag, does that hide/show certain pages which would not be available to the general public, or does it modify the same page so it appears differently to different visitors? Or both?

Both. Most existing pages will still exist, with new styling. In the flag ON state, we would use boostlookv3.css, otherwise boostlook.css.

What is an exact affected URL?

boost.org is one example 😊.

modify your local /etc/hosts file to bypass the CDN

That's fine for testing, but at some point, we will turn this on for everyone. I suppose we can just blow away the cache entirely at that point...

[sdarwin]

In the flag ON state, we would use boostlookv3.css, otherwise boostlook.css.

Thanks for the info.

I commented in Slack yesterday, the CDN is now set to skip caching for logged-in users. So this issue should be solved.

[gregjkal]

@jsiswickqa or @kattyode putting this in QA in case you want to try and verify the behavior when turning the flag off and on for your user on stage.

[jsiswickqa]

Verified that the CSS file updates correctly.