Offline-first web and mobile apps: Top frameworks and components
Offline-first is a fairly straightforward concept on the surface, yet implementation of Offline-first apps can present many challenges. Fortunately, there are a variety of tools available to help developers build offline-first apps.
Before we get into the tools available to developers, however, here's a bit of background on the offline-first movement. The first major introduction of offline-first was in a 2013 A List Apart article by Alex Feyerke:
When it comes to building apps, we often assume our users are very much like us. We picture them with the latest devices, the most recent software, and the fastest connections. And while we may maintain a veritable zoo of older devices and browsers for testing, we spend most of our time building from the comfort of our modern, always-online desktop devices.
With offline-first, we assume that, as a baseline, your app will not have a working network connection. Then, your app can be progressively enhanced to take advantage of network connectivity when available. This takes a shift in mindset to not assume that lack of connectivity is an error condition. Build your app to work without a connection. Get updated content, sync your data, or enable features that aren’t practical to make work offline when the app is connected. Let users still interact with your app when there’s no reliable connection available. Let's now take a look at both some high-level and low-level offline-first tools available to developers today.
High-Level Tools & Frameworks
Progressive Web Apps
If you're a web developer then you'll want to take a look at Progressive Web Apps if you haven't already. The basic idea of Progressive Web Apps is to combine the discoverability of web apps with the power of native mobile apps. As an end user, you browse to a Progressive Web App just like you would browse to any other website.
As you use the app more-and-more, it gains additional native-app-like capabilities. For example, installation to your home screen or the ability to send you alerts and notifications. Google is the biggest proponent of Progressive Web Apps, and there are growing number of Progressive Web Apps being built.
Progressive Web Apps are an opportunity for web developers to rethink how we approach building web apps. People have clearly demonstrated that they like the interaction model of native apps. There’s a lot that we can learn from how native apps are built. Don’t get me wrong, I’m a huge believer in the power of the open web.
I don’t think we should just turn web apps into native apps and call it done. I do think that we can incorporate some of the best parts of native apps into how we build web apps while not losing the soul of the open web.
Polymer App Toolbox
Ready to start building your first Progressive Web App? Then check out Polymer App Toolbox, "a collection of components, tools and templates for building Progressive Web Apps with Polymer." Polymer App Toolbox is part of Google's Polymer Project and features "offline caching as a progressive enhancement, using service workers."
The open source Hoodie project was probably the first framework to embrace the offline-first moniker and approach. Hoodie is "a complete backend for your apps: develop your frontend code, plug it into our API and your app is ready," which uses an "offline-first, no-backend architecture."
Ionic is a tool that allows you to create hybrid mobile apps using Angular. Ionic can deploy to native platforms (including iOS and Android) using Apache Cordova or PhoneGap, or you can deploy an Ionic app to the browser as a Progressive Web App. The Ionic blog has a post on Building an Ionic App with Offline Support. You can also extend the offline-first capabilities of your Ionic app by adding PouchDB to the mix (more on PouchDB further in this article).
Couchbase Mobile is a set of tools that can be used to take an offline-first approach to your data. Couchbase Lite provides an API to store data locally on iOS and Android platforms. Couchbase Sync Gateway allows for replication of data between an embedded Couchbase Lite database and Couchbase Server.
Realm Mobile Platform
The Realm Mobile Platform also allows you to take an offline-first approach to your data by enabling real time data sync between a Realm Mobile Database embedded in an iOS or Android app and the Realm Object Server. Realm says that this feature will be available soon for React Native and Xamarin apps as well.
Mapbox Mobile is an "open source SDK lets developers add beautiful maps and turn-by-turn navigation to their apps that can go offline." From Mapbox:
Maps no longer need a data connection. Both our Android and iOS SDKs can pre-cache maps to save bandwidth and data charges, optimize performance, and anticipate the lack of network access.
Low-Level Tools & Components
The newest and biggest development in offline-first for web developers is the Service Worker specification. You may remember the HTML5 Application Cache (AppCache), which was the first attempt at providing a browser mechanism for caching content and assets for offline usage. There were numerous issues with the AppCache and it has since been deprecated by most browsers.
Service Workers is a new approach that aims to solve the same basic problem, while avoiding the pitfalls of AppCache. Service Workers give you fine-grained control over caching content and assets for offline usage by intercepting client requests and returning previously-stored results when offline. Progressive Web Apps (referenced earlier) heavily leverage Service Workers. Service Workers were first introduced into Google Chrome. Firefox and Opera have also implemented Service Workers, and Microsoft Edge plans to support Service Workers as well.
Service Workers are great for enabling offline usage of content and assets. But, sometimes having an actual database can be helpful. This is where IndexedDB, WebSQL, or localStorage can be helpful. Or, at least they would be helpful if browsers implemented these standards consistently. The browser support and implementation quirks can make it very difficult to actually use these technologies. Fortunately there’s localForage, a wrapper for IndexedDB, WebSQL, or localStorage which provides a unified API.
While not as lightweight as localForage, PouchDB includes a bunch of awesome features that are probably worth the extra overhead. The most exciting feature of PouchDB is its ability to sync its data with anything that implements the CouchDB Replication Protocol. This, of course, includes Apache CouchDB. It also includes IBM Cloudant, a fully-managed cloud database that is based on CouchDB, as well as Couchbase Server.
If you prefer to build native mobile apps and would like to take an offline-first approach to your data then check out Cloudant Sync for iOS or Cloudant Sync for Android. While they have different APIs than PouchDB, these libraries, like PouchDB, store data locally on the device and can also sync with anything that implements the CouchDB Replication Protocol.
There are still many challenges to be addressed around offline-first. A common pattern for developers using PouchDB or Cloudant Sync is to create one database per user. Each user is given their own local database on their device, as well as their own database in the cloud with which only they can replicate. This works great if you have an app where each user's data is fairly well segmented. However, as soon as you want to allow a user to access another user’s data, or you want to create aggregate queries across multiple users’ data, the one-database-per-user pattern starts to break down.
Cloudant Envoy is an open source project that aims to provide the best parts of one-database-per-user without the pain of one-database-per-user. Cloudant Envoy is effectively a proxy which provides the illusion of one-database-per-user to the PouchDB or Cloudant Sync database on the user’s device, but it actually stores all of the data in one CouchDB or Cloudant database. An access control list is maintained by Cloudant Envoy which dictates who can access what data.