This post was originally published on this site.
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 (rn) are flawless.
// building the raw multipart string
const boundary = 'sync_boundary_' + Date.now();
const delimiter = "rn--" + boundary + "rn";
const close_delim = "rn--" + boundary + "--";
const bodyString = delimiter +
'Content-Type: application/json; charset=UTF-8rnrn' +
JSON.stringify(metadata) + delimiter +
'Content-Type: application/jsonrnrn' +
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.
