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
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, the development process, or any of our internal teams? If so, please note how you will 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?
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
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?
Will this PR introduce a change that impacts Forem members or creators, the development process, or any of our internal teams? If so, please note how you will share this change with the people who need to know about it.
- [ ] I've updated the Developer Docs and/or Admin Guide, or Storybook (for Crayons components)
- [ ] I've updated the README or added inline documentation
- [x] I will share this change in a Changelog or 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: please replace this line with details on why this change doesn't need to be shared
[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>
Top comments (15)
Any chance
/offlinecan direct to an online version of the page for doodling purposes? 😅We could potentially do that. I'd suggest creating a post on forem.dev to start that discusssion.
Posted 😊
forem.dev/terabytetiger/request-to...
dev.to/offline.html still works :)
you're one step ahead :D
You removed a feature that had limited value when it worked, often didn't work, and had serious maintenance costs...and you didn't have to wait 2-5 years to do so.
I, along with every other enterprise dev, are just going to live vicariously through you on this one.
I'm really glad to have your feedback on this subject. I also had a nightmare period with service workers (up to the point one mistake lead to one of my pet app to not be runnable anymore other than going in private browsing mode or to completely empty my cache, something that I knew my potential future users would not always be able to do for reasons).
And so I came to the conclusion Service Worker is like Peter Parker's powers. It puts so much pressure , and not enough benefits to justify this pressure imho. This is why I decided that I would never again use Service Worker other than providing offline backup (meaning I would only use the NetworkFirst strategy), which is the same thing you are deciding over there and I find this interesting.
I'm pretty convinced this technology has a long way to go until finally becoming mature enough to be reliably be considered as mainstream as an ordinary JS framework: easily removable, without any constraints or backfire.
I'm curious to know what other peers owning a Service Worker for their app (other than choosing this technology to deliver a product that could not be delivered without it) think about maintaining this piece 🧐
Interesting too that one browser (Safari) has caused the issues.
I totally get it. My C'YaPass PWA (progressive web app) Password Generator, worked on every browser platform except Safari. I had to add a button to allow the user to copy the password to her clipboard each time, even though every other browser will copy the password to the clipboard on. I also struggled to get it to work offline, but finally got it. All these browser vectors still create a lot of work for devs. 🤷
Safair is modern IE of old times.
That was an interesting read, thanks for sharing! I've had a few issues over the course of months on DEV with weird caching behaviour like seemingly resetting the theme, thinking I'm logged out or just having no styling whatsoever - all "fixed" by hard refreshing. Never raised an issue on it because I couldn't work out how to recreate it and each time it happened, I thought it was likely the last time (it was weeks between issues). Honestly sounds like my issues might have been with the service workers themselves given what you've said here.
Good work everyone involved with both identifying the issues, fixing the ones you could along the way and knowing when to try something else! 🙂
Had this issue too.
Wow, you're right about making tradeoffs. I liked the offline feature a lot that I was considering adding it to my job board, but now that I look back at the idea with this perspective, I think I'd very much not spend anymore engineering time on it. Especially if it's going to cause more trouble than it is worth potentially. Thanks for the writeup!
I think you should add a screenshot of the offline page as a souvenir :) it was great reading the way you and your team assessed the situation, rock on!
too bad .. now I have to find a better internet provider.
RIP offline page 😢 lol