1© 2015 Rogue Wave Software, Inc. All Rights Reserved. 1

Easy offline-first mobile and desktop web apps with PouchDB

Rod Cope, CTO

Dog event administration on-site

• Change, cancel, or add runs– May take payment or provide refunds

• Record results– Pass/fail, scores– Must be mailed to AKC after event is finished

My use case: replace paper forms

• Devices: laptops, some tablets and phones• Challenges

– Little or no Internet access– Users are NOT technical

• Most are 50-75 years old• Copy/paste is hard• Don’t understand “synchronization”

Offline-first

• Offline!

Offline-first

• Latency– Multiple round trips

Offline-first

• Offline!• Latency

– Multiple round trips• WiFi

– Bad/slow connection

Your site name here

Offline-first

• Offline!• Latency

– Multiple round trips• WiFi LieFi

– Bad/slow connection

Your site name here

use an offline-first app!

Synchronization options

Offline-first challenges

• User experience• Security• Data management

Offline-first challenges

• User experience• Security• Data management

User experience (UX)

• Implications of offline-first:– No “make this available offline”– Internet access is a feature– Usually sync data eventually

User experience (cont.)

• Users don’t understand online/offline/sync– Getting a ”web” page means “online”– Automatic and seamless sync

• Remind users to sync– Online-only features

• Indicate online status

UX: Online/offline indicators

https://github.com/hubspot/offline

Make sure you need them!

Offline-first challenges

• User experience• Security• Data management

Security: authentication/authorization

• Online client– Must be online first– Auth with server, store login token

• Offline client– Local auth– Assume all users are admins

• Back online client– Auth with stored token– Bi-directional synchronization of changes

Online security flow

Offline security flow

• Local authentication (optional)– Password, token, device-specific, OS, 2FA

• Local authorization (optional)• Can’t prevent authentication/authorization

– User has physical control of device– Don’t store sensitive server data

• No private server passwords, keys, tokens!

Security: offline changes

• Save changes to local storage• Prevent online-only changes

Security: offline changes (cont.)

• Server can’t trust offline changes– Never trust user input in any form– Authenticate and authorize– Validate and normalize data

• Data format migration• Apply accepted changes to master data store

• Communicate results back to client

Back online security and data flow

Offline-first challenges

• User experience• Security• Data management

Data: offline queries

– Okay to query client-side cache• Example: show user profile and preferences

– Inform user if data may be missing• Example: event search results

Data: offline changes (mutations)

• User-private or “lightly shared” data– Create transactions & prepare for submission

• Example: shopping, enter dog event results

– Inventory or dynamic pricing might be a problem

Data: e-commerce example

Data: offline changes (mutations)

• Shared data– Admin can change price or description– Can resolve conflicts automatically

• Example: sequence number, date, user id– May need user to resolve conflicts

• Example: Original price: 10

Your price: 11 Other price: 12

Make new price 11 Make new price 12

Data: offline and online

• Offline– Save all changes on the client

• Online– Still save changes on the client first– Bi-directional sync with the server– Conflict detection & resolution

Offline data options: AJAX

• The default option: retry or show error• Complex logic to retry failed REST calls• 5xx errors, timeouts, network errors• User closes browser/tab, browser crash, machine crash

– What state is the transaction in if the browser tab hangs or the browser crashes after the user clicks “Purchase”?

• Probably bad user experience• Definitely bad developer experience!

Pyramid of Doom

Promises

• It’s better with promises, but…– 5xx errors, timeout, network error, user closes browser/tab, browser crash, machine crash

• What state is the transaction in if the browser tab hangs or the browser crashes after the user clicks “Purchase”?

Offline implementation options

Progressive Web Apps

Offline data options: SW and PWA

• Service Workers and Progressive Web Apps• JavaScript-based proxy between your client-side code and the browser

• Good for caching patterns and offline support• No support today in Safari/iOS Safari, IE/Edge• “In development” for Edge• “Under consideration” for WebKit (Safari)• Powerful option for the future, but not ready today unless your audience only uses Chrome or Firefox

Offline data options: PouchDB!

• JavaScript, Apache 2.0 license• “The database that syncs!” • Replicates with PouchDB or CouchDB

– Local or remote– Uni- or bi-directional (master-master)– Automatic conflict resolution– HTTP (easy testing with curl)

Offline data options: PouchDB (cont.)

• Change stream– Observe add/change and delete

• Backing stores– Browser: IndexedDB, WebSQL, memory– Node.js: options below, memory, and more

PouchDB platforms

Web app languages

Web app frameworks

Desktop apps

Desktop apps… with web technology!

React desktop – Mac and Windows

Key packages

Client• React, React Native, React Desktop + Electron

• Redux– Maintains client state

• GraphQL/Apollo Client (optional)

• PouchDB

Server• Express• GraphQL/Apollo Server (optional)

• node.js• PouchDB or CouchDB

Client: React and friends for UI

• React for responsive web app• React Native for native mobile UI• React Desktop for native-looking desktop UI

• React Router for URL management

Client: React and friends for data• Redux for client state management• Redux/PouchDB

– Bi-directional state sync with local database

• Pouch Websocket Sync– Bi-directional sync: local/remote DB’s

• PouchDB– Uses IndexedDB or WebSQL in browser

• Optional: GraphQL integration with PouchDB

PouchDBRedux

ServerPouchDB/CouchDB

Server: React, PouchDB, and friends

•React SSR (Server-Side Rendering)–Include initial Redux store state

•Pouch Websocket Sync for sync with auth & reconnect

•PouchDB on LevelDB (from Google)–Could also use CouchDB, Cloudant, Couchbase

•Pouch Clerk for (async) transaction state machine

http://blog.yld.io/2016/06/24/how-to-build-a-reliable-transaction-experience-for-your-customers

Server (continued)

• Don’t have to use PouchDB/CouchDB on server• Example: my app is based on Meteor and MongoDB

– PouchDB synced with MongoDB on server– Pouch Clerk calls Meteor method which updates MongoDB

– Pouch Clerk updates PouchDB with results– One server-side PouchDB per dog event

Conclusions

• Offline-first leads to a better user experience• PouchDB enables offline-first

– Runs everywhere– Synchronization with conflict resolution

• Build web, mobile, and even desktop apps with one architecture, language, and framework family

– JavaScript, React, Electron

Questions?

Rod Cope, CTO

Rogue Wave Software

@RodCope

68© 2015 Rogue Wave Software, Inc. All Rights Reserved. 68