Building an offline-first service

We look at one approach to build offline-first mobile applications using React Native, Redux, Scala, Akka persistence and Event-sourcing, CQRS concepts.

Transcript

1. Building an offline-first service Akos Krivachy
2. Removed for speakerdeck: <Screencast of web-view mobile app: no offline support>
3. Removed for speakerdeck: <Screencast of native mobile app: no offline support>
4. Removed for speakerdeck: <Screencast of twitter mobile app: partial offline support>
5. Removed for speakerdeck: <Screencast of The Guardian mobile app: quite good offline support>
6. How do we build apps that are more like the Guardian?
7. Our story
8. Requirement: offline-first mobile app from day one
9. Frontend: React Native + Redux
12. Request action: isLoading bit set Response action: data
13. Request action: isLoading bit set Response action: data
15. Errors? Undo the optimistic action
17. Command: intent or request Can be refused!
18. Event: statement of fact
20. Command refusal? Store extra information: • Error text • Navigation key
21. Event: statement of fact
22. Command format { command, optimisticAction, undoAction, errorTitle, errorInformation, errorNavigationState }
23. Backend
24. REST? • POST /users • GET /users/123 • PATCH /users/123 • DELETE /users/123
25. Issue: out-of-sync local cache • GET /users/123 followerCount: 5 • Go offline • Navigate to followers screen: Only 4
26. Issue: truly offline - is everything local? • Have x resources: • /users, /posts, /posts/comments, /feed, /profile, etc. • How do you refresh all your data when online? • Possible solutions: E-Tags/If-Modified- Since, only get changes/diffs
27. Backend: Scala (Akka) + Event-driven
28. API • POST /commands • GET /events?sequenceId=123
30. Look familiar? Flux loop in the backend
31. Command Actor • One Actor per entity (aggregate root) • State is in memory • Validate commands • Persist events
32. Command Payload final case class ClientCommandJsonEnvelope( commandId: CommandId, `type`: String, timestamp: DateTime, payload: JsValue)
33. Event Payload final case class ClientEventJsonEnvelope( eventId: EventId, sourceCommandId: CommandId, sequenceId: Long, `type`: String, timestamp: DateTime, payload: JsValue)
34. Schema CREATE TABLE IF NOT EXISTS journal ( ordering SERIAL, persistence_id VARCHAR(255) NOT NULL, sequence_number BIGINT NOT NULL, deleted BOOLEAN DEFAULT FALSE, tags VARCHAR(255) DEFAULT NULL, message BLOB NOT NULL, PRIMARY KEY(persistence_id, sequence_number) );
35. And millions of events?
37. Closing thoughts
38. Advantages App experience much better Rock solid API Backend availability requirements lower Free audit log, immutable events
39. Disadvantages More engineering New way of thinking: how will this work offline? App can’t store everything (infeasible amount of data) UX needs to be extremely good
40. Other options Firebase, PouchDB, Realm, Horizon, Rethink Make it work with REST – not impossible WebSockets for protocol GraphQL (view side)
41. Think offline-first!
42. Resources • Immutable User Interfaces, Lee Byron https://vimeo.com/166790294 • CQRS, not just for server systems, Greg Young https://skillsmatter.com/skillscasts/1980-cqrs-not-just-for-server- systems • http://offlinefirst.org/ https://github.com/offlinefirst/research/blob/master/links.md