1097492785caf9ffeebffeb624202d8f?s=200 avatar

1097492785caf9ffeebffeb624202d8f?s=200

Prosper is a great speaker, community leader, open source hacker, technical consultant, and a fervent Developer Advocate. He is a full-stack software engineer who has worked on biometric, health and developer tools. Prosper recently co-founded a startup called Eden that’s focused on improving the quality of lives in Nigeria and currently leads the engineering team. He also co-founded forloop, the largest developer community in Africa.

Former Auth0 Employee

Prosper Otemuyiwa

Progressive Web Apps are the future. Learn how to make your mobile web app native-like by making it work offline, load instantly and send push notifications.

Introduction to Progressive Web Apps (Push Notifications) - Part 3

Progressive Web Apps are the future. Learn how to make your mobile web app native-like by making it work offline and load instantly.



---

**TL;DR:** Web development has evolved significantly over the years allowing developers to deploy a website or web application and serve millions of people around the globe within minutes. With just a browser, a user can put in a URL and access a web application. With, **Progressive Web Apps**, developers can deliver amazing app-like experiences to users using modern web technologies. In the [first part of this tutorial](https://auth0.com/blog/introduction-to-progressive-apps-part-one) we set up our progressive web app, cached the pages and made it work partially offline. This time, we'll make it load instantly and work offline fully.

---

## Recap and Introduction to Part 2

In [Introduction to Progressive Web Apps (Offline First)](https://auth0.com/blog/introduction-to-progressive-apps-part-one), we discussed how a typical progressive web application should look like and also introduced the service worker. So far, we've cached the application shell. The `index` and `latest` pages of our web app now load offline. They also load faster on repeated visits. Towards the end of the first part of this tutorial, we were able to load the `latest` page offline but couldn't get dynamic data to display when the user is offline.

This tutorial will cover:

* Caching the App data on the `latest` page to be displayed to the user when offline
* Using `localStorage` to store the App data
* Flushing out old App data and fetching updated data when the user is connected to the internet


## Offline Storage

When building progressive web apps, there are various storage mechanisms to consider like so:

* **[IndexedDB](https://developer.mozilla.org/en/docs/Web/API/IndexedDB_API):** This is a transactional JavaScript based database system for client-side storage of data. This database employs the use of indexes to enable high performance searches of the data stored in it. IndexedDB exposes an asynchronous API that supposedly avoids blocking the DOM, but some research has shown that in some cases it is blocking. I recommend that you use libraries when working with IndexedDB because manipulating it in vanilla JavaScript can be very verbose and complex. Examples of good libraries are [localForage](https://mozilla.github.io/localForage), [idb](https://www.npmjs.com/package/idb) and [idb-keyval](https://www.npmjs.com/package/idb-keyval).

  ![IndexedDB Browser Support](https://images.ctfassets.net/23aumh6u8s0i/3TAkSh1K0jquHYGmAIKlG0/177eb267243366d60a232f9b3b3e99c3/indexeddbsupport)

  _IndexedDB browser support_
* **[Cache API](https://developer.mozilla.org/en-US/docs/Web/API/Cache):** This is best for storing url addressable resources. Works with Service worker really well.
* **[PouchDB](https://pouchdb.com):** Open Source JavaScript database inspired by [CouchDB](http://couchdb.apache.org). It enables applications to store data locally while offline, then synchronize it with CouchDB and compatible servers when the application is back online, keeping the user's data in sync no matter where they next login. PouchDB supports all modern browsers, using IndexedDB under the hood and falling back to WebSQL where IndexedDB isn't supported. Supported in *Firefox 29+ (Including Firefox OS and Firefox for Android), Chrome 30+, Safari 5+, Internet Explorer 10+, Opera 21+, Android 4.0+, iOS 7.1+* and *Windows Phone 8+*.
* **[Web Storage e.g localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API):** It is synchronous and can block the DOM. The usage is capped at 5MB in most browsers. It has a simple API for storing data and it uses key-value pairs. 
  
  ![Web Storage Browser Support](https://images.ctfassets.net/23aumh6u8s0i/5t6F5vI9NFvk8MiYbFg0rs/c2804c91dc9d0c15279788ebcf9ec1c0/webstorage)

  _Web Storage browser support_

* **[WebSQL](https://www.w3.org/TR/webdatabase):** This is a relational database solution for browsers. It has been deprecated and the [specification](https://www.w3.org/TR/webdatabase) is no longer maintained. So, browsers may not support it in the future.

![Quota for Mobile Storage](https://images.ctfassets.net/23aumh6u8s0i/nDs06JOzFjU8L5N741a75/593af684f2f1ff25b050093afccf15dc/mobile)

_Mobile Storage Quota_

[Addy Osmani](https://twitter.com/addyosmani) has a comprehensive resource on [Offline storage for progressive web apps](https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c#.j7e7w3m7g). You should really check it out!

According to PouchDB maintainer, [Nolan Lawson](https://twitter.com/nolanlawson), do well to ask yourself these questions when you are using a database:

* Is this database in-memory or on-disk(PouchDB, IndexedDB)?
* What needs to be stored on disk? What data should survive the application being closed or crashing?
* What needs to be indexed in order to perform fast queries? Can I use an in-memory index instead of going to disk?
* How should I structure my in-memory data relative to my database data? What’s my strategy for mapping between the two?
* What are the query needs of my app? Does a summary view really need to fetch the full data, or can it just fetch the little bit it needs? Can I lazy-load anything?

You can check out [how to think about databases](https://nolanlawson.com/2016/02/08/how-to-think-about-databases) to give you a broader knowledge on the subject matter.


## Let's Implement Instant Loading

For our web app, we'll use `localStorage` . I recommend that you don't use `localStorage` for production apps because of the limitations I highlighted earlier in this tutorial. The app we are building is a very simple one, so `localStorage` will work fine.

Open up your `js/latest.js` file. We will update the `fetchCommits` function to store the data it fetches from the Github API in `localStorage` like so:

```js


 function fetchCommits() {
    var url = 'https://api.github.com/repos/unicodeveloper/resources-i-like/commits';

    fetch(url)
    .then(function(fetchResponse){ 
      return fetchResponse.json();
    })
    .then(function(response) {
        console.log("Response from Github", response);

        var commitData = {};

        for (var i = 0; i < posData.length; i++) {
          commitData[posData[i]] = {
            message: response[i].commit.message,
            author: response[i].commit.author.name,
            time: response[i].commit.author.date,
            link: response[i].html_url
          };
        }

        localStorage.setItem('commitData', JSON.stringify(commitData));

        for (var i = 0; i < commitContainer.length; i++) {

          container.querySelector("" + commitContainer[i]).innerHTML = 
          "<h4> Message: " + response[i].commit.message + "</h4>" +
          "<h4> Author: " + response[i].commit.author.name + "</h4>" +
          "<h4> Time committed: " + (new Date(response[i].commit.author.date)).toUTCString() +  "</h4>" +
          "<h4>" + "<a href='" + response[i].html_url + "'>Click me to see more!</a>"  + "</h4>";

        }

        app.spinner.setAttribute('hidden', true); // hide spinner
    })
    .catch(function (error) {
      console.error(error);
    });
};

```

With this piece of code above, on first page load, the commit data will be stored in `localStorage`. Now let's write another function to retrieve the data from `localStorage` like so:

```js

  // Get the commits Data from the Web Storage
  function fetchCommitsFromLocalStorage(data) {
    var localData = JSON.parse(data);

    app.spinner.setAttribute('hidden', true); //hide spinner

    for (var i = 0; i < commitContainer.length; i++) {

      container.querySelector("" + commitContainer[i]).innerHTML = 
      "<h4> Message: " + localData[posData[i]].message + "</h4>" +
      "<h4> Author: " + localData[posData[i]].author + "</h4>" +
      "<h4> Time committed: " + (new Date(localData[posData[i]].time)).toUTCString() +  "</h4>" +
      "<h4>" + "<a href='" + localData[posData[i]].link + "'>Click me to see more!</a>"  + "</h4>";

    }
  };

```

This piece of code fetches data from `localStorage` and appends it to the DOM. 

Now, we need a conditional to know when to call the `fetchCommits` and `fetchCommitsFromLocalStorage` function. 

The updated `latest.js` file should look like so:

_latest.js_

```js

(function() {
  'use strict';

  var app = {
    spinner: document.querySelector('.loader')
  };

  var container = document.querySelector('.container');
  var commitContainer = ['.first', '.second', '.third', '.fourth', '.fifth'];
  var posData = ['first', 'second', 'third', 'fourth', 'fifth'];

  // Check that localStorage is both supported and available
  function storageAvailable(type) {
    try {
      var storage = window[type],
        x = '__storage_test__';
      storage.setItem(x, x);
      storage.removeItem(x);
      return true;
    }
    catch(e) {
      return false;
    }
  }

  // Get Commit Data from Github API
  function fetchCommits() {
    var url = 'https://api.github.com/repos/unicodeveloper/resources-i-like/commits';

    fetch(url)
    .then(function(fetchResponse){ 
      return fetchResponse.json();
    })
    .then(function(response) {
        console.log("Response from Github", response);

        var commitData = {};

        for (var i = 0; i < posData.length; i++) {
          commitData[posData[i]] = {
            message: response[i].commit.message,
            author: response[i].commit.author.name,
            time: response[i].commit.author.date,
            link: response[i].html_url
          };
        }

        localStorage.setItem('commitData', JSON.stringify(commitData));

        for (var i = 0; i < commitContainer.length; i++) {

          container.querySelector("" + commitContainer[i]).innerHTML = 
          "<h4> Message: " + response[i].commit.message + "</h4>" +
          "<h4> Author: " + response[i].commit.author.name + "</h4>" +
          "<h4> Time committed: " + (new Date(response[i].commit.author.date)).toUTCString() +  "</h4>" +
          "<h4>" + "<a href='" + response[i].html_url + "'>Click me to see more!</a>"  + "</h4>";

        }

        app.spinner.setAttribute('hidden', true); // hide spinner
      })
      .catch(function (error) {
        console.error(error);
      });
  };

  // Get the commits Data from the Web Storage
  function fetchCommitsFromLocalStorage(data) {
    var localData = JSON.parse(data);

    app.spinner.setAttribute('hidden', true); //hide spinner

    for (var i = 0; i < commitContainer.length; i++) {

      container.querySelector("" + commitContainer[i]).innerHTML = 
      "<h4> Message: " + localData[posData[i]].message + "</h4>" +
      "<h4> Author: " + localData[posData[i]].author + "</h4>" +
      "<h4> Time committed: " + (new Date(localData[posData[i]].time)).toUTCString() +  "</h4>" +
      "<h4>" + "<a href='" + localData[posData[i]].link + "'>Click me to see more!</a>"  + "</h4>";

    }
  };

  if (storageAvailable('localStorage')) {
    if (localStorage.getItem('commitData') === null) {
      /* The user is using the app for the first time, or the user has not
       * saved any commit data, so show the user some fake data.
       */
      fetchCommits();
      console.log("Fetch from API");
    } else {
      fetchCommitsFromLocalStorage(localStorage.getItem('commitData'));
      console.log("Fetch from Local Storage");
    }   
  }
  else {
    toast("We can't cache your app data yet..");
  }
})();

```

In the piece of code above, we are checking if the browser supports `localStorage` and if it does, we go ahead to check if the commit data has been cached. If it has not been cached, we fetch, display and cache the app's commit data.

Now, reload the browser again, make sure you do a hard, clear-cache, reload else we won't see the result of our code changes. 

Now, go offline and load the `latest` page. What happens?

Yaaay!! it loads the data without any problem.

![Load Dynamic Data Offline](https://images.ctfassets.net/23aumh6u8s0i/36OIqp3X2ZgkuGhLrElTuo/59cb767fae6efe1286ae47c0311f0358/pwacommits)

Check the **DevTools**, you'll see the data been stored in `localStorage`.

![Store Data Locally](https://images.ctfassets.net/23aumh6u8s0i/7BqkhLztkyPWUy4r9kPNNG/ed3e4bfebb1a77f4cc3a518916aa4607/data-stored-locally)
_Store Data Locally_

Just look at the speed at which it loads when the user is offline....OMG!!!

![Loads From Service Worker](https://images.ctfassets.net/23aumh6u8s0i/3i5tSnwsD9hz4TSLCJhyCR/badb2a218fa38c57a507cb4c13a3eb63/load_from_service_worker)
_Loads from Service Worker when user is offline_

## One More Thing

Now, we can make the app load instantly by fetching data from the localStorage. How do we get fresh updated data? We need a way of still getting fresh data especially when the user is online.

It's simple. Let's add a refresh button that triggers a request to GitHub to get the most recent data.

Open up your `latest.html` file and add this code for the refresh button within the `<header>` tag.

```html

<button id="butRefresh" class="headerButton" aria-label="Refresh"></button>

```

So the `<header>` tag should look like this after adding the button:

```html

<header>
  <span class="header__icon">
    <svg class="menu__icon no--select" width="24px" height="24px" viewBox="0 0 48 48" fill="#fff">
      <path d="M6 36h36v-4H6v4zm0-10h36v-4H6v4zm0-14v4h36v-4H6z"></path>
    </svg>
  </span>
  <span class="header__title no--select">PWA - Commits</span>
  <button id="butRefresh" class="headerButton" aria-label="Refresh"></button>
</header> 

```

Finally, let's attach a `click` event to the button and add functionality to it. Open your `latest.js` and add this code at the top like so:

```js

document.getElementById('butRefresh').addEventListener('click', function() {
    // Get fresh, updated data from GitHub whenever you are clicked
    toast('Fetching latest data...');
    fetchCommits();
    console.log("Getting fresh data!!!");
});

```

Clear your cache and reload the app. Now, your `latest.html` page should look like so:

![PWA - Get Updated data](https://images.ctfassets.net/23aumh6u8s0i/MhrrMYrgjMApmPLbCbBdh/11496d354460a2d24895c74e73397b4c/latest_data)

_Get Updated data_

Anytime users need the most recent data, they can just click on the refresh button.


## Aside: Easy Authentication with Auth0

You can use [Auth0 Lock](https://auth0.com/docs/libraries/lock) for your progressive web app. With Lock, showing a login screen is as simple as including the **auth0-lock** library and then calling it in your app like so:

```js

// Initiating our Auth0Lock
var lock = new Auth0Lock(
  'YOUR_CLIENT_ID',
  'YOUR_AUTH0_DOMAIN'
);

// Listening for the authenticated event
lock.on("authenticated", function(authResult) {
  // Use the token in authResult to getProfile() and save it to localStorage
  lock.getProfile(authResult.idToken, function(error, profile) {
    if (error) {
      // Handle error
      return;
    }

    localStorage.setItem('idToken', authResult.idToken);
    localStorage.setItem('profile', JSON.stringify(profile));
  });
});

```

**Note:** If you want to use Auth0 authentication to authorize _API requests_, note that you'll need to use [a different flow depending on your use case](https://auth0.com/docs/api-auth/which-oauth-flow-to-use). Auth0 `idToken` should only be used on the client-side. [Access tokens should be used to authorize APIs](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/). You can read more about [making API calls with Auth0 here](https://auth0.com/docs/apis).

_Implementing Lock_

```js

document.getElementById('btn-login').addEventListener('click', function() {
  lock.show();
});

```

_Showing Lock_


![Auth0 Lock Screen](https://images.ctfassets.net/23aumh6u8s0i/ElPRQ0cfHgykYZStjyH3D/709b6df945b846607fee305380d134f5/nexthrone-auth0lock)

_Auth0 Lock Screen_

In the case of an offline-first app, authenticating the user against a remote database won't be possible when network connectivity is lost. However, with service workers, you have full control over which pages and scripts are loaded when the user is offline. This means you can configure your `offline.html` file to display a useful message stating the user needs to regain connectivity to login again instead of displaying the Lock login screen.

## Conclusion

In this article, we were able to make our app load instantly and work offline. We were able to cache our dynamic data and serve the user the cached data when offline. 

In the final part of this tutorial, we will cover how to enable push notifications, add web application manifest and our app to a user's homescreen.


Introduction to Progressive Web Apps (Instant Loading) - Part 2

Progressive Web Apps are the future. Implement offline functionality and make your mobile web app feel like a native app.

Introduction to Progressive Web Apps (Offline First) - Part 1

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Learn about the importance of creating an offline-first experience for app users and how to accomplish it easily with the Service Worker API

---

**TL;DR:** Serving web-app users a good offline experience can be tricky if they become disconnected from the internet. Providing offline functionality is important for UX, and some recent technologies make it easier for developers to accomplish it. In this article, we focus on the [**service worker API**](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) and find out how to use it with a library called [**UpUp**](https://github.com/TalAter/UpUp) to make our apps offline-first.

---

Application users are no longer restricted to devices that are always connected to the internet, so it's more important than ever that applications can handle poor or no network connection. Ideally, apps should still work when the network connection is lost, with a mechanism for local data storage synced with a remote database. This kind of functionality is familiar in many ways; native applications provide mechanisms to accomplish it easily. We can achieve the same effects in mobile hybrid apps, as well as web apps in general, with some relatively new technologies.

In this article, we'll explore the current state of offline-first applications and see what kind of approach to take to ensure a smooth user experience in our own apps, even when disconnected. We'll talk about [**service workers**](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) and how to use them either directly, or with a helper library called [**UpUp**](https://github.com/TalAter/UpUp).

## Service Workers for Offline-First Apps

We're all familiar with what happens when we become disconnected while using the web--we try to move forward on the page or in the app, and we're greeted with a message that tells us we can't. Most native mobile apps will still offer some functionality while offline, but a lot of web apps don't.

![offline-first](https://images.ctfassets.net/23aumh6u8s0i/1HI6dtci2sxJt7zp16vrwt/c6f8ec146c1c730639eac7d2fe8410ab/offline-first-1)

What we need, then, is a way for our app to detect when we don't have an internet connection, and then respond in a different and particular way. This is where the **service worker API** comes in. In fact, this technology’s main focus is making it easier for developers to provide users with good offline experiences.

A service worker is a bit like a proxy server between the application and the browser, and it has quite a bit of power. With a service worker, we can completely take over the response from an HTTP request and alter it however we like. This is a key feature for serving an offline experience. Since we can detect when the user is disconnected, and we can respond to HTTP requests differently, we have a way of serving the user files and resources that have been saved locally when they are offline.

<include src="TweetQuote" quoteText="With a service worker, we can completely take over the response from an HTTP request and alter it."/>

![service-worker](https://images.ctfassets.net/23aumh6u8s0i/5i0xfQoXvflydEZlnBvQLs/c3fd8767326bf6dee5ea144f422271bf/offline-first-diagram)

## Service Workers > AppCache

The service worker API is an attempt to replace the **HTML5 Application Cache**. Nothing is perfect, but AppCache has a host of issues that frustrate developers trying to create offline experiences. One of the biggest issues is that apps won't work at all unless AppCache is set up just right, which means debugging is very tricky. With AppCache, only same-origin resources can be cached, and when it comes to updating resources, it's all or nothing—we can't update cached items individually.

Service workers really shine when stacked up against AppCache. They give us a lot of fine-grained control, so we're able to customize the process of serving an offline experience. Some of this ability is because service workers use promises, which allow us to respond to both `success` and `error` conditions.

## Registering a Service Worker

So how do we make use of service workers? We can access them through the `navigator` API and hook up new service workers with the `register` method.

```js
if('serviceWorker' in navigator) {
  navigator.serviceWorker
    .register('sw.js', { scope: './'})
    .then(function(registration) {
      console.log('Service worker registered!');
    })
    .catch(function(error) {
      console.log('There was an error!');
    });
}
```

Service workers are tied to a particular scope, and the location of the service worker script in the project directory is important. If we want the above service worker to apply to any route in our application, we would need the `sw.js` script to be accessible at `http://example.com/sw.js`.

With the service worker registered, we need to define what happens when certain events, such as `fetch`, occur. Instead of rolling out a full example on our own, let's make use of a small library called [UpUp](https://github.com/TalAter/UpUp). This library provides a service worker abstraction that makes it easier to simply define which resources we want available when the user is offline.

## Offline-First Apps with UpUp

The first step is to create our app just as we would normally.

```html
  

  ...

  <nav class="navbar navbar-default">
    <div class="container-fluid">
      <a class="navbar-brand">UpUp App</a>
    </div>
  </nav>

  <div class="container">
    <form>
      <div class="form-group">
        <label>New Todo</label>
        <input type="text" class="form-control" placeholder="Enter a new todo">
      </div>
      <button type="submit" class="btn btn-default">Submit</button>
    </form>
  </div>

  ...
```

![offline-first upup](https://images.ctfassets.net/23aumh6u8s0i/6EB2gFmOq2cfikJhf9a3Ne/cf5cb40df46f021cf09be2647cb0023c/offline-first-2)

UpUp lets us define what we want to serve the user when they are disconnected. We do this with the `start` method and we can pass in the `content-url` and an array of `assets` that should be used.

```html
  

  ...

  <script src="upup.min.js"></script>
  <script>
    UpUp.start({
      'content-url': 'templates/offline.html',
      'assets': [
        'css/bootstrap.min.css'
        // Other assets like images, JS libraries etc
      ]
    });
  </script>

  ...
```

We can tell UpUp which specific template to use when the user is offline. The content we serve when when offline can be the same as when online, or we can customize it to let the user know they are disconnected.

```html
  

  ...

  <div class="alert alert-danger">
    You are currently offline, but you can keep working.
  </div>

  ...
```

![offline-first upup](https://images.ctfassets.net/23aumh6u8s0i/1d3EevnWzlu1fv2dKFY5fD/aa09b9e17cb7bb8914662be12882d628/offline-first-3)

> TIP: You don't need to unplug your modem to simulate being offline. Simply use the "Toggle Device Mode" with Chrome dev tools and select **Network: Offline**. ![offline-first service worker upup](https://images.ctfassets.net/23aumh6u8s0i/4rJmhKmN7uIO5145enVxj0/c39fc00bb7d75546e846bc432b0a73e7/offline-first-4)

If we need a framework for our app, we can bring in the necessary JavaScript within the `assets` array so that it is retrieved when offline.

So that works, but what exactly is UpUp doing to achieve this? Looking at the UpUp service worker will give us an idea.

```js
// src/upup.sw.js

self.addEventListener('fetch', function(event) {
  event.respondWith(
    // try to return untouched request from network first
    fetch(event.request.url, { mode: 'no-cors' }).catch(function() {
      // if it fails, try to return request from the cache
      return caches.match(event.request).then(function(response) {
        if (response) {
          return response;
        }
        // if not found in cache, return default offline content
        if (event.request.headers.get('accept').includes('text/html')) {
          return caches.match('sw-offline-content');
        }
      })
    })
  );
});
```

UpUp is listening for `fetch` events and first tries to return a request from the network. If that fails, it looks to the cache to resolve the request; if that fails too, it serves the offline content we registered.

The service worker itself is wired up with the `start` method we saw earlier.

```js
// upup.js

start: function(settings) {
  this.addSettings(settings);

  // register the service worker
  _serviceWorker.register(_settings.script, {scope: './'}).then(function(registration) {
    // Registration was successful
    if (_debugState) {
      console.log('ServiceWorker registration successful with scope: %c'+registration.scope, _debugStyle);
    }

...
```

## What About Data?

Native apps naturally provide ways for collecting data while the user is offline. This data can be synced with a remote database once a connection is re-established. When it comes to the web, however, data synchronization isn't as easy.

We might be inclined to roll our  own solutions, but dealing with timestamps, revisions, conflict resolution, and consistency can be a lot of work. Fortunately, there are some great solutions for collecting data locally for syncing later.

### PouchDB

[PouchDB](http://pouchdb.com/) is an open source local data storage library that can be set up with [CouchDB](http://couchdb.apache.org/) to automatically sync data. PouchDB emulates CouchDB very closely, so the API between the two looks and feels quite similar.

PouchDB makes it trivial to set up a local and remote database and to have them automatically sync with one another. Local databases use the browser's IndexedDB to store data.

```js

// Local databases are created by just providing a name
var local = new PouchDB('todos');

// Remote databases are created by providing a path to CouchDB
var remote = new PouchDB('http://localhost:5984/todos');
```

PouchDB uses a simple promise-based API for storing and retrieving documents.

```js

// Store a document
var todo = {
  "_id": "todo1",
  "name": "Go to the store"
}

local.put(todo);

// Retrieve a document
local.get('todo1').then(function(data) {
  console.log(data);
}).catch(function(error) {
  console.log('There was an error');
});
```

When it comes to syncing, we can have one-way or two-way sync, and we can choose to have the databases replicate continuously or just at a time we specify. In many cases, we'll set up live replication that accounts for a user dropping in and out of network coverage. To do this, we just need to tell PouchDB that we want it to retry syncing.

```js
local.sync(remote, {
  live: true,
  retry: true
});
```

<include src="asides/JavascriptAtAuth0" />

**Important API Security Note:** If you want to use Auth0 authentication to authorize _API requests_, note that you'll need to use [a different flow depending on your use case](https://auth0.com/docs/api-auth/which-oauth-flow-to-use). Auth0 `idToken` should only be used on the client-side. [Access tokens should be used to authorize APIs](https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/). You can read more about [making API calls with Auth0 here](https://auth0.com/docs/apis).

In the case of an offline-first app, authenticating the user against a remote database won't be possible when network connectivity is lost. However, with service workers and a library like UpUp, you have full control over which pages and scripts are loaded when the user is offline. This means you can configure your `offline.html` file to display a useful message stating the user needs to regain connectivity to login again instead of displaying the Lock login screen.

## Wrapping Up

With so many app users relying on mobile, and with spotty networks in many places, it's becoming more and more essential to give our users a decent offline experience. The [**service worker API**](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) helps greatly, and really outdoes **AppCache**, because we have much more control over what happens. While the service worker API is relatively straightforward to use, setting up an offline app is even easier with abstractions such as the one provided by [UpUp](https://github.com/TalAter/UpUp).

Focusing on the offline experience is not always feasible, perhaps because other features take priority. However, providing usability while offline is valuable and can even be a key differentiator between your app and others.

"service-workers"