Offline-First Apps: Why Should Apps Be Made to Work in an Offline State?

Back when I used Spotify, I would navigate to where I needed to be while I had wifi to prepare for when I had no signal, like before a run or plane flight. Else it would often just fail to load at all.

Youtube and Youtube Music at least have a deliberate "Downloads" tab which is what I want when I know that I'm offline and want to browse my downloaded media.

But it does still suck. I'd imagine the main reason Spotify choose to limit it like that is some requirement put on them by the music labels.

The whole app is basically unusable with a spotty connection though. It is constantly attempting to do network things that block the ui.

I download music on Spotify so I can use it on the tube with no internet connectivity.

So why does the page for any downloaded album seemingly require connectivity to load FFS? How am I supposed to click on the song?

(Randomly, after half an hour often, it just works. I have no idea how or why.)

Plus, you frequently don’t want to architect your client code the same as your server code (you’re not going to run a bunch of micro services on the client side for example)

Maintaining multiple sources of truth is hard, especially if multiple people are working on the same data.

What was the user load like? Performance / latency?

[0] http://breeze.github.io/doc-js/

You might be at a remote site, or on a plane with no Wi-Fi.

But, yeah, if those are common use cases for your app, you should absolutely be designing for offline.

You can absolutely implement offline in a web application (Google drive does this). Obviously, you need to be online to get the app in the first place, but once it’s cached, you should be good to go.

Again, it’s a cost-benefit analysis for the business.

One of the decision trees is you often have some API needs and can't just live within the pouch db database. Particularly account creation and such. It may need to plug into other services and initiate them, you could use a database as a message queue, but it's awkward compared to an API.

The couch/pouch models gets somewhat more complex when you leave the one db per user model. If there are shared data buckets, the database access patterns require a good deal of thought and experience with the couch db auth model. Particularly it's limitations.

Offline access also requires thought around sensitive data. If a user has had their access revoked, an offline first app may preserve it which can rub against security requirements.

Initial sync can be very slow if you're dealing with a lot of data. This can be a poor experience if you make a new user wait minutes to get started. Or you can also build a backend so they can start immediately and then switch to the local copy after replication. I've build this kind of system before.

There are advantages to the route. Minimal data transfer from the server can represent lower load for your services. You can also do an offline only model for data, potentially lowering cloud costs for the number of users you serve - a definite boon for free tiers.

The replication is pretty slick and quick, web socket like snappy data without web sockets. Using tools that do most of the heavy lifting for you and you mostly have to just plumb correctly.

Ditto is both an embedded + cloud database + a mesh network, it's really 2 startups in 1.

A) If you're looking for just offline-first and data sync, there are some company's that have done this

1. Realm (MongoDB) - this is the company that my CoFounder and I came from. 2. Firebase (Google) - one of the biggest inspirations for me personally in data sync. 3. Supabase - a very popular growing open source Firebase alternative 4. All the GraphQL Backend-as-a-Service like Prisma, Hasura etc... These have offline caching with a lot of the GraphQL client libraries. I don't think actually have a database underneath the hood that you can query.

B) If you're looking for just mesh networks:

1. Build it yourself using Bluetooth Low Energy, Local Area Network, P2P Wi-Fi Direct, Apple Wireless Direct, Wi-Fi Aware APIs that come with most of your device frameworks. Build an advertising system, a common communication protocol, and add your identity security system. If you want multi-hop, you'll need to create a dynamic routing and presence system on top of it. After that design an API to send data around, respond to errors. If you want offline-first you should research CRDTs and try to build a database replication system using the mesh network. 2. You could use Apple's Multipeer Connectivity framework: this is iOS, MacOS devices only. No multi-hop here but you can build a system on top if it. One thing I've noticed is Apple's framework is a ruthless battery drainer. My phone gets very hot after a minute. It doesn't look like it uses Bluetooth Low Energy and it's advertising system seems to be extremely aggressive 3. Google has an abstraction called Nearby Messages that uses Bluetooth Low Energy. It isn't very stable but you could try to trick it to re-establish connections. After that you'll want to investigate how to pull off multi-hop. It's the same as step 1 and 2 https://developers.google.com/nearby/messages/overview 4. There was a company called Hypelabs that offered mesh network solution, but not the offline-first part. I'm not sure what's up with them 5. There's another company called Bridgefy https://bridgefy.me/ that built a chat app used in some of the Hong Kong protests 6. Open Garden also had Firechat in 2014

Ditto is a combination of both families of problems, it's basically creating 2 startups at the same time (mesh + distributed database):

* Offline first embedded mobile, web, IoT database called the small peer * A large distributed database in the cloud called the Big Peer (this is new and what we need to operationalize for general avaiability pricing) * A replication engine that uses our mesh network powered by Bluetooth Low Energy, Local Area Network, P2P Wi-Fi Direct, Apple Wireless Direct, Wi-Fi Aware

The problems that we have to tackle are so crazy; network optimizations, compression, multi-plexing, conflict resolution, scaling on the edge and cloud etc.... It's like the product that we're trying to create is teaching us as we build. For example one of the challenges that we have now with multi-hop is scaling performance. A large mesh of 1,000 devices may chatter so much just on the distributed routing table that it can cripple the replication of the actual data! So we are trying novel ways to dynamic route data by also incorporating special characteristics of CRDTs so that chatter is reduced and performance increases. Other major things we will improve are ways to prevent denial-of-service attacks even with trusted actors, decentralized access control of data, graph centrality theory etc...

Regarding use cases?

1. Well anything that's latency sensitive is perfect for us. Think controlling robots, syncing whiteboard pen strokes across devices, games, VR+AR. 2. Industry wise, any place where _any_ issue to internet connectivity means a loss of money, life, user experience: aviation, hospitals, point of sale, education, manufacturing, defense. A lot of our customers have internet 99.9% of the time but even that 0.1% is a nightmare that causes great issues.

There are expressive CRDT libraries like Yjs and Automerge but these don’t give you persistence.

There are mature databases out there that include CRDTs, like Redis and Postgres EDB, but these have very limited semantics.

Ditto is a proper database with a rich set of CRDTs. It’s well engineered, the team are great and it has a compelling DX / realtime APIs.

Source: working with CRDTs at Vaxine.io

I'm not sure if you know what CRDTs are but they're a family of data types that allow different actors in a distributed system to edit data concurrently even during network partitions. If enough data is shared, they will deterministically agree on the same value. They kind of give that "google docs" behavior if you're looking for an analogy. They're perfect for peer to peer and offline-first systems.

However there is actually more to it, and a much more detailed write up is coming soon. Ditto is a distributed database, each peer has it's own database. The database is organized into collections and each collection is a Ditto Document (this does not work like most NoSQL document databases). Each property of the document is it's own CRDT, you as the user can pick which CRDT you'd like to use, our current catalog includes:

* Registers (Causal Last Write Wins) * Counters (sums of each writer's numeric values) * Binary Attachments (same as a Register but you can put large arbitrary data like say video files, images, PDFs whatever) * AddWinsMaps (coming soon) - This type allows for concurrent upserting and removing of values based on a key. * ReplicatedGrowableArray - this is an array type that allows for concurrent insertions while preserving some semblance of order. It behaves rather closely to a collaborative text editor merge behavior.

Our AddWinsMap and ReplicatedGrowableArray are more special than you might think. They can actually host nested CRDTs. Think of it like a folder within a folder in Google Drive that can hold synced documents nested within.

I'd love to show you over perhaps a call! We tend to be perfectionist when it comes to documentation and have been so busy that we haven't fleshed it all out. Perhaps we might just open source our CRDT system.

Email is in my profile, I love chatting and sharing about this stuff!

This is what is required to build an app where any instance (node) can be offline for an arbitrary amount of time, but still be able to share state with the rest of the nodes when it's reconnected.

To implement this, every application node keeps a vector clock per register (an atomic piece of shared state). The vector clock allows any node the compare its own version of the register with the state received from any other node. Two values of a vector clock can either be causally related (in which case the most recent write wins) or concurrent. However the concurrency is from the system's perspective, but not necessarily from the user's perspective. An extra physical timestamp can be kept at the register level to order concurrent updates in a way consistent with the user's time perception.

Now, having the hybrid clocks in place to version each register on each node, the system must implement a protocol to ship every register update to all nodes (reliable broadcast).

Once all updates are shipped to all nodes, it's guaranteed that all nodes have the same (most recent) state.

(I built an offline-first product and had to roll my own protocol)

A big aspect of this is data collection. Microsoft office has tons of features that could easily be local buy that it wants to be "connected services" that are subject to their own TOS so they can steal your data. Based on the lag, it seems like all spell and grammar checks go through some server somewhere, almost certainly with the primary goal of scraping as much info as they can from what you're doing. Online first is all about data harvesting, much less so ease of operation and certainty not customer experience.