Going offline with IndexedDB
Tags: indexeddb, offlinefirst, firebase, serviceworkers
Published: 2019-10-20 17:32:45

---
title: Going offline with IndexedDB
published: true
description: I'm ditching FireBase, and going fully offline-first with IndexedDB and Service Workers.
tags: indexedDB, offline-first, firebase, service workers
---

This is a repost from my personal blog [michielnuyts.com](https://www.michielnuyts.com/)

# Going offline with IndexedDB

Over the past week, I have refactored my app from using FireBase to IndexedDB. This brings a new set of tradeoffs. Some cool benefits are that I can now provide all services of the app without a user needing to make an account. A potential user stumbles upon the landing page, clicks on the Call-To-Action button and can immediately start using the app. All data is saved locally in the browser in IndexedDB, which is provided in all browsers. So even without an internet connection, the app can be fully used by the user. This works because I'm using a service worker, which installs itself the very first time a user starts using the app.

One of the biggest downsides is that when the user clears his browser data, the app data in IndexedDB will also be cleared. I'm fixing this by providing a syncing ability through Google Drive, Dropbox, and other major cloud storage providers. 

I think this is a cool direction for my app because all data is just locally on the user's machine, queries and mutations are really fast! There is no more latency when you don't need to talk to a server somewhere far away from the user's location. The key here will be to make the syncing between IndexedDB and the cloud storage work really well, especially when the user switches often between devices. I still need to think this through, it's probably the most complex new issue when choosing this route. 

At least I'm avoiding a lot of complexity as well, it's often easier to query and do mutations in IndexedDB than in FireBase. I'm also avoiding a lot of financial worries. FireBase has a pay-for-what-u-use model. I'm also avoiding vendor lock-in. Google can always ramp up their prices or just abandon the service as they have done with other services already in the past. This also benefits the user, because I can just keep the App free to use. I only have to pay for the hosting of the client application, which I'm doing at [zeit.co](https://zeit.co)

I'm aiming to launch a first beta version on November 20. Still, I have some stuff to figure out, but isn't that the best part about software development? Yep.

If you ever find yourself tinkering with IndexedDB and want to really use it to build something, even if it's just for prototyping, have a look at [Dexie](https://dexie.org/docs/Tutorial/Getting-started). Which is a wrapper around the IndexedDB API and makes it a lot more usable. I'll definitely write more about using IndexedDB in a production App soon, for now here are some more resources to check out if you are interested in this direction for your own App.

- [Google Workbox](https://developers.google.com/web/tools/workbox)
- [IndexedDB Best Practices](https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/indexeddb-best-practices)
- [Dexie](https://dexie.org/docs/Tutorial/Getting-started)