Upload
rogue-wave-software
View
356
Download
3
Embed Size (px)
Citation preview
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