Offline First for Everyday Developers, Quickly

Ray Daly
Offline Camp
Published in
5 min readFeb 23, 2017
Sunset hayride at Offline Camp California

Under the wide open blue sky in the mountains of western North America during Offline Camp California, our unconference session had no bounds. Bradley Holt and I discussed the question of whether developers can quickly build Offline First apps. The discussion was heavily influenced by previous sessions and the many one-on-one discussions that the camp environment promotes. Our conclusion was a qualified YES!

The topic was more difficult than expected because web apps go from simple to sophisticated; from no databases to large data sets; from calculators to complex medical apps with extreme security and privacy concerns. We came away from the session realizing that Offline First apps are any interactive web file that works for a user with no or poor network connections. The interactions may be on a screen, with voice, controlling IoT device or any input. Even given this broad definition, there are good solutions in many cases.

Templates and Quick Fixes

In our experience there are two projects to help build a database driven, Offline First app quickly. Hoodie provides the backend and you code the frontend to build an app. The people who created and maintain Hoodie originated the Offline First movement. The second is the App Template with Google’s Polymer Project. By adding the web components for either PouchDB or Firebase, one can have an Offline First app in production within a day. Google started promoting the PRPL Pattern at Google I/O 2016 and refers to Offline Apps as Progressive Web Apps. We can recommend that people look at these projects.

The other recommendation for creating an Offline First app is to use the PouchDB library. Everyone at camp recommended PouchDB. You could go library-less and write your own code using browser storage, but both syncing and browser data APIs are very, very hard. One of the participants had done this is a production app and now uses libraries instead. (Disclaimer: We had 3 very active members of the PouchDB community at Offline Camp California, including a current co-maintainer — though they were not in this session.)

Sunset hayride at Offline Camp California (Image credit: Aaron Ross)

Data Structure and Design

The limiting factor in determining if Hoodie, Polymer or PouchDB would be appropriate for a project is data structure, the amount of data and the freshness of data. For example, some apps require instant access and all of the data must fit in a device’s storage capacity. Other apps don’t need any external data.

Data is now a major area of work when developing any app. A pattern for building Offline First apps has emerged so data design moves to the forefront. A developer needs to understand their data to build a successful app. This gets to some of the fundamentals of computer science.

Two books came to mind that developers might want to explore when looking a data solutions. “Data Structures and Algorithms with JavaScript” by Michael McMillan examines arrays to graph data. It makes you look at your data in a different way and thus offer a better solution.

Seven Databases in Seven Weeks” by Eric Redmond and Jim R. Wilson explores the pros and cons of modern NoSQL databases. Even though it was written 5 years ago, it still informs on solutions to data problems. It should be noted that only one of the databases covered in this book, CouchDB, works well with PouchDB.

We did not have a recommended book for looking at data storage in the cloud. The IBM Cloudant DBaaS does have documentation online about using the service for Offline First. (Disclaimer: IBM was the foundational sponsor of Offline Camp.)

Common Cases

Finally, we discussed some common cases of Offline First apps:

  1. No database data. There are cases were the content of the app is hardcoded or files. Many calculator-like apps hardcode the formulas and work offline. Others operate more like books with the content being files of text, HTML, images or sound. An example is my United States Constitution App. In these case the content can be cached on the phone with the rest of the app’s code. This approach is often overlooked.
  2. Limited data. Often the amount of data an app requires is limited and infrequently, if ever, updated. In these cases, that data may be stored in a database but loaded as if it were a file. Think of stats for a previous year as an example. Again, these can be cached with the app’s code. Interactive news articles sometimes use this pattern.
  3. Database required with updates. These are the most common cases Offline First attempts to address. A simple example might be a weather app where the database returns different data based on a timestamp and location. Or a customer-based app might only return data for only one user. The user would then interact with and update the data to be sent back to the database. There are many more examples where the data works with a JSON format. These are the cases where CouchDB with Cloudant, Hoodie, and Firebase could be used. Depending on the data, a solution may be straightforward or require a deep understanding of the database’s limitations.
  4. Large data sets and security concerns. In some cases an app’s data is larger than can fit on a device. In these cases, for example, the dictionary data structure might work but require a backend beyond just a simple database. Related to this are security requirements like two-factor authentication where backend coding is required. In these cases, some of the above approaches may be used in combination with custom coding.

More Work Ahead

Other Offline First cases were discussed that require a custom solution, as far as we knew. We touched on non-structured data — like some scientific data — and graph databases. The first will almost always require a custom solution.

Graph data is a common requirement with IBM, AWS, Neo4j and others offering services. But we were not familiar with any libraries offering solutions for taking graph data offline.

We concluded that many developers can easily build an Offline First app quickly. However, the data requirements in some cases demands custom work. Our recommendation is that developers become familiar with these solutions.

Editor’s Note: This article recaps discussions we had at Offline Camp, a unique tech retreat that brings together the Offline First community. Join us at our next event or sign up for updates and cast your vote on where we should host future editions of Offline Camp.

Editor’s Note: This article recaps discussions we had at Offline Camp, a unique tech retreat that brings together the Offline First community. Join us at our next event or sign up for updates and cast your vote on where we should host future editions of Offline Camp.The Oak Creek Ranch, home of Offline Camp California, by night

--

--

Ray Daly
Offline Camp

Author of web apps. Speaker on JavaScript Journalism and creating with JavaScript. Formerly Washington Post IT.