Sources Contact Advanced Search Tutorials

An Interest In:

Web News this Week

Search Archive

Some of Our Sources

View All Sources

Help Webnuz

Referal links:

March 17, 2021 05:53 pm GMT

Goodbye Offline Page

Dear DEV Community Members,

I wanted to bring you all up to speed on a decision the Forem team recently made to remove our Service Worker functionality, and thus, our offline page. This was not a decision we came to lightly.

Like many of you, we all thoroughly enjoyed drawing in our browsers using the DEV offline page whenever our internet fritzed on us. Recently however, the cost of maintaining the Service Worker became exceedingly high for our team. Over the past couple of months, we've been having to put out one emergency fire after another, all because of our Service Worker functionality.

A couple of weeks ago, I took a step back and assessed the situation. Given the fact that we lean heavily into edge caching, I figured that losing the Service Worker would not have a huge impact on performance and could save the Forem engineering team a lot of headaches. However, there still remained the question of the offline page. After chatting with @ben about our options, we decided to strip the Service Worker down so that its only function was to serve the offline page.

Reduce service worker functionality to minimal offline page #12834

benhalpern posted on Feb 26, 2021

What type of PR is this? (check all applicable)

[x] Refactor
[ ] Feature
[x] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description

This PR strips out some of our very cool ReadableStream service worker functionality because it has been causing too many bugs related to the deployment of new code.

The upside of this functionality is very instant initial page loads, but the downside to the current implementation is too many instances of difficult-to-predict deployment cache issues. These were always painful to deal with, but are exceptionally difficult in a Forem world where our devops cannot act quickly to fix production issues the same way we can with a single deploy.

The fundamental issue with our current implementation is just that it is not exhaustive in terms of dealing with certain scenarios, and dealing with edge cases creates a lot of complexity.

We suspect there are still UX benefits and SEO benefits to handling basic offline functionality...

And we still have our service worker lifecycle on top of which we may be able to methodically add back certain functionality that this PR removes, but we can do so with much more of an emphasis on ensuring all possible scenarios are accounted for so that we do not allow users to get caught in buggy situations.

One additional adjustment I made was just removing the "DEV" portion of the image on the offline page (and some code cleanup there)... We may want to offer a new fun way for Forem admins to customize this page, but I figured this small adjustment to make for a more minimal and generalized offline page made sense here.

Follow up

There is additional code that can be removed with this new approach, but due to the nature of how service workers run code already downloaded to user browsers (i.e. the cause of this complexity in the first place), it makes sense to wait at least a few weeks to remove some of the other code that is not needed anymore in case it could break old installs.

Related Tickets & Documents

https://github.com/forem/internalEngineering/issues/333

QA Instructions, Screenshots, Recordings

This is mostly an adoption of this functionality: https://web.dev/offline-fallback-page/

Eyeball the functionality and test different network conditions to ensure this does not cause new problems.

UI accessibility concerns?

This should not cause new a11y issues.

Added tests?

[ ] Yes
[x] No, and this is why: I'm not really sure how to test this.
[ ] I need help with writing tests

[Forem core team only] How will this change be communicated?

Will this PR introduce a change that impacts Forem members or creators, thedevelopment process, or any of our internal teams? If so, please note how youwill share this change with the people who need to know about it.

[x] I've updated the [Developer Docs]

[optional] What gif best describes this PR or how it makes you feel?

View on GitHub

We deployed and rejoiced thinking our woes were over.

We were wrong

A few days after this deploy, our emergency Slack channel was once again lit up with users who could not log in from Safari. We put together a fix (and then a follow up fix ) and shipped it. A few days after that, the emergency channel again popped up with a flood of log in problems being reported from users. Once again we shipped a fix. After the third day of this happening, I decided to turn to my engineering leaders to get their thoughts on the whole situation.

What are folks' thoughts on the continuing issues we are having with the Service Worker? Ben greatly reduced its functionality to only the offline page bc of all the issues it has been causing and the giant sink it has been for developer time but it doesn't feel like things have gotten much better. My heart can't take many more days of coming back to my Slack with #emergency lit up and a 100 reply thread.
Do we think things are going to get better once we have identified all the exception paths? OR do we still think it's going to be a landmine that will only continue to bite us? The cost of this offline page feature is getting pretty high and I am wondering if it's worth the cost.

My incredible team and @ben all jumped in with their thoughts.

But there was another complication thrown into the mix: our offline page was supposed to help our SEO rankings! However, we were not sure how much it was supposed to help. In the end, we weighed all our options and determined that the best course of action was to remove the Service Worker completely and monitor our incoming traffic using Google's Search Console.

Making engineering decisions is all about tradeoffs. In this case, the Service Worker feature was disruptive to both our users and to us as developers, which seemed to outweigh any benefits that it had provided. While removing the offline page is a bit disappointing, in the big scheme of things, it will make the Forem platform much more reliable and stable going forward.

For more details, check out the removal PR below.

Removed service worker #12974

nickytonline posted on Mar 11, 2021

What type of PR is this? (check all applicable)

[ ] Refactor
[ ] Feature
[x] Bug Fix
[ ] Optimization
[ ] Documentation Update

Description

This removes all of our service worker functionality with a self-destructing service worker which appears to be the best approach for unregistering a service worker. See https://github.com/NekR/self-destroying-sw#how-to-use.

Related Tickets & Documents

QA Instructions, Screenshots, Recordings

Test this in Chrome, Firefox, and Safari. Note in Safari, there may be no service worker registered due to the work done with the service-companion.js file. In that case, ensure that no errors are thrown in the console of the web dev tools in Safari.

Pull down latest of the main branch and deploy the site locally. Navigate to the home page and validate that the service worker is running by opening the developer tools and navigating to the developer tools.

Chrome

Firefox

Safari

Pull down the branch for this PR and deploy it locally. Refresh the browser window that is currently open and validate that the service worker gets unregistered.

Chrome

Firefox

Safari

UI accessibility concerns?

N/A this is front-end infrastructure

Added tests?

[ ] Yes
[x] No, and this is why: I've removed tests related to the service worker, so existing tests should continue to pass.
[ ] I need help with writing tests

[Forem core team only] How will this change be communicated?

[ ] I've updated the Developer Docs and/orAdmin Guide, orStorybook (for Crayons components)
[ ] I've updated the README or added inline documentation
[x] I will share this change in a Changelogor in a forem.dev post
[ ] I will share this change internally with the appropriate teams
[ ] I'm not sure how best to communicate this change and need help
[ ] This change does not need to be communicated, and this is why not: pleasereplace this line with details on why this change doesn't need to beshared

[optional] Are there any post deployment tasks we need to perform?

[optional] What gif best describes this PR or how it makes you feel?

</div><div class="gh-btn-container"><a class="gh-btn" href="https://github.com/forem/forem/pull/12974">View on GitHub</a></div>

Original Link: https://dev.to/devteam/goodbye-offline-page-5d98

Share this article:

View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To