Stack Overflow Blog2026年5月12日

Building a Google Drive Sync Engine that Survives MV3 Service Workers

8.5Score

TL;DR · AI Summary

This article discusses how to build a Google Drive sync engine that runs smoothly within the strict limits of MV3 service workers, focusing on in-memory state management, offline handling, and replacing the Google SDK with native Fetch.

Key Takeaways

MV3 enforces a strict disk-first model, saving all user actions immediately to l
Offline syncing pauses and queues states locally; manual merging occurs upon rec
Removing the official Google API client and using native Fetch improves performa

Outline

Jump quickly between sections.

§The Death of In-Memory State
MV3 enforces a strict disk-first model, saving all user actions immediately to local storage.
§Handling Offline Drops
Offline syncing pauses and queues states locally; manual merging occurs upon reconnection.
§Dropping the Google SDK for Native Fetch
Removing the official Google API client and using native Fetch improves performance and reduces dependency size.

Mindmap

See how the topics connect at a glance.

查看大纲文本（无障碍 / 无 JS 友好）

Google Drive Sync Engine
- In-Memory State
  - Disk-First Model
- Offline Handling
  - Manual Merge
- Native Fetch
  - Performance Improvement

Highlights

Key sentences worth saving and sharing.

MV3 will kill the service worker anytime to free up memory, so all user actions must be saved immediately to local storage.
— Section 1
⬇︎ 下载 PNG 𝕏 分享到 X
Offline syncing pauses and queues states locally; manual merging occurs upon reconnection.
— Section 2
⬇︎ 下载 PNG 𝕏 分享到 X
Removing the official Google API client and using native Fetch improves performance and reduces dependency size.
— Section 3
⬇︎ 下载 PNG 𝕏 分享到 X

#Chrome MV3#Service Worker#Google Drive#Sync Engine

Open original article

Building a Google Drive Sync Engine that Survives MV3 Service Workers - Stack Overflow

Blog

[](https://stackoverflow.com/)[](https://stackoverflow.blog/feed)[](https://stackoverflow.com/users/email/settings/current)

Stack Overflow Business

**Stack Internal**: the knowledge intelligence layer that powers enterprise AI.**Stack Data Licensing**:decades of verified, technical knowledge to boost AI performance and trust.**Stack Ads**: engage developers where it matters — in their daily workflow.

May 12, 2026

Building a Google Drive Sync Engine that Survives MV3 Service Workers

Moving to Chrome’s Manifest V3 (MV3) isn't just a simple syntax update. It completely breaks how we used to build browser extensions.

For simple tools, the fix is easy. But when you are building an offline-first app that constantly talks to Google Drive, MV3 forces you to scrap everything you know about state management, network drops, and dependencies.

Here is a look at the trade-offs I had to make to get a cloud sync engine running smoothly inside the strict limits of an MV3 Service Worker.

1. The Death of In-Memory State

Back in the MV2 days, keeping a sync queue inside a background script variable was standard practice. You can't do that anymore. MV3 will kill your Service Worker whenever it wants to free up memory. If a user clips a webpage and the worker dies before the upload finishes, that data is gone forever.

You have to move to a strict disk-first model. chrome.storage.local becomes your only source of truth.

I had to wire the app so that any user action—clipping text, typing a note, or using voice input—saves directly to local storage right away. Syncing to the cloud happens strictly in the background as an afterthought. Because the Service Worker holds zero state, the browser can wake it up, it checks local storage for pending syncs, fires off the upload, and dies. No data gets lost in the process.

2. Handling Offline Drops

You can never trust the network, especially for a browser extension running on flaky Wi-Fi or a laptop going to sleep.

If the user drops offline, the extension immediately halts syncing and queues the state locally. The tricky part is coming back online. If you just blindly push local changes to the cloud, you risk wiping out updates the user made from another laptop.

I ended up writing a quick script to merge things manually. When the connection comes back, the code pulls the existing JSON from the appDataFolder in Drive. Then I just toss the local notes and the remote notes together into a Map. Since my note IDs are basically just timestamps, sorting them is super easy and handles duplicates naturally. Once everything is merged into a single array, I upload it back to Google. It's a bit hacky, but it completely stops accidental overwrites—even if Chrome shuts down the background script right in the middle of syncing.

3. Dropping the Google SDK for Native Fetch

The biggest tradeoff I made was stripping out the official Google API client entirely.

Sure, SDKs make life easier, but they are huge. Shoving a massive dependency tree into an MV3 Service Worker slows down execution time and bloats the bundle size. It completely defeats the performance goals of the new manifest.

So, I stuck strictly to the native fetch API to talk to the Google Drive v3 REST API. It keeps the extension ridiculously fast and lightweight. The catch? You have to build multipart/related HTTP bodies by hand if you want to upload metadata and file content in the exact same request.

That means manually wrangling string boundaries in vanilla JavaScript and making sure your carriage returns (\r\n) are flawless.

javascript

// building the raw multipart string
const boundary = 'sync_boundary_' + Date.now();
const delimiter = "\r\n--" + boundary + "\r\n";
const close_delim = "\r\n--" + boundary + "--";

const bodyString = delimiter + 
    'Content-Type: application/json; charset=UTF-8\r\n\r\n' + 
    JSON.stringify(metadata) + delimiter + 
    'Content-Type: application/json\r\n\r\n' + 
    JSON.stringify({ notes: localData }) + close_delim;

Writing raw HTTP requests like this is honestly pretty annoying, especially when you know drive.files.create() is just one line of code in the SDK. But shedding all that dependency weight makes the extension snap instantly, so it's a trade-off I'd make again.

Engineering for Constraints

Manifest V3 feels restrictive at first. However, treating it as a hard constraint forces better design. By accepting that state will die, writing defensive offline checks, and dropping heavy libraries, you can build cloud integrations that actually feel native to the browser.

Interested in contributing? Submit an idea for an article and we may reach out to you in the future.

Author s

Najmul Alam Miraj ![Image 1: Image of Najmul Alam Miraj Najmul Alam Miraj is a Bangladesh-based tech product developer focused on building meaningful digital solutions with modern UI/UX and offline-first architecture. He has worked as a front-end developer, front-end development instructor, and senior graphics designer.…](https://stackoverflow.blog/author/najmul-alam-miraj/ "View full bio and posts")

The Heap programming

Add to the discussion

Our Stack

Company

Support

Elsewhere

Blog
Dev Newsletter
Podcast
Releases
[Dev Survey](https://survey.stackoverflow.co/ "Annual Developer Survey")

Light Dark Auto

[](https://linkedin.com/company/stack-overflow/ "LinkedIn")[](https://x.com/stackoverflow/ "Twitter/X")[](https://www.threads.net/@thestackoverflow "Threads")[](https://www.instagram.com/thestackoverflow/ "Instagram")[](https://www.youtube.com/c/StackOverflowOfficial "YouTube")

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Accept all Necessary cookies only

Customize settings

Cookie consent preference center

When you visit any of our websites, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and manage your preferences. Please note, blocking some types of cookies may impact your experience of the site and the services we are able to offer.

Cookie policy

Manage consent preferences

#### Strictly Necessary Cookies

Always Active

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.

#### Functional Cookies

[x] Functional Cookies

These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

#### Targeting Cookies

[x] Targeting Cookies

These cookies are used to make advertising messages more relevant to you and may be set through our site by us or by our advertising partners. They may be used to build a profile of your interests and show you relevant advertising on our site or on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device.

#### Performance Cookies

[x] Performance Cookies

These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.

Cookie List

Clear

- [x] checkbox label label

Apply Cancel

Consent Leg.Interest

[x] checkbox label label

[x] checkbox label label

[x] checkbox label label

Necessary cookies only Confirm my choices