Local-first Software Architecture @ Glide Apps

• Done every role in a software org from developer to CTO, raising money, growing the team, driving go-to-market, you name it.
• Have made a lot of technical and architecture decisions, some of them really bad that I've had to pay for, some decent ones that compound like interest

About 3 years ago, I decided to pivot my career from bringing software to market to focus on driving forward the future of computing

• First half of my career was approaching computers as a set of existing capabilities, understanding the needs of a specific market, then rearranging those existing capabilities into a product, strapping on a business model, and bringing that software to market.
• Second half of my career is about inventing brand-new capabilities for computers

"My goal is to make the computer a more expressive medium so that humans and computers can think better, together."

• Tool for making / thinking
• Enable collaboration

Over the past three years, I see a generic architectural shape emerging for software that we consider to be "tools" - which, I would argue, Glide is a tool forge for making specific tools.

I'll call this emerging "architecture" local-first architecture b/c I don't currently have a better name.

• I noticed y'all have done some collaboration with Paul Sonnentag and Szymon Kaliski from Ink & Switch, so I'm guessing some of you have heard of Local-first Software?
  • If not, I won't go through it in detail, but go read the article, or watch this talk:

Building web/mobile apps in today's client-server architecture is solving a distributed systems problem where every team has to solve the problem themselves by putting together the components carefully.

• First rule of building distributed systems is don't build a distributed system.
  • Because they're hard
• We like to pretend that "everyone is online all the time" - ignore the distributed system.
  • Those who have productionized software have to face it down: database migration, transactions, event streams like Kafka, background jobs, optimistic updates in the UI
  • Clients are no longer just a projection of server state - they are rich, independent applications

Before I get to the architecture, I'll talk you through how I got there. Four different experiences:

• Croquet - real-time collaboration framework.
  • Events are transmitted to all of the peers in real-time.
  • Servers are just dumb "reflectors".
  • "Deterministic" computation where all systems stay in sync by design.
  • Building real-time collaborative apps was trivially easy with this client/reflector model. Reflectors applied timestamps to normalize the event stream.
  • Clients should just emit events - then we need a strategy for reconciling those events.
• Fission - decentralized identity, data, and compute.
  • Spent a year at Fission working on their decentralized protocols.
  • Also researching blockchains.
  • Fission has a full set of decentralized protocols to replace all the things you're used to:
    • OAuth -> UCAN
    • S3, blog storage -> WebNative File System, built atop IPFS
    • DB -> in development
    • "Serverless functions" -> in development, IPVM
  • Big take-aways
    • You don't need authoritative servers! Cryptography
      • Once again, clients/peers are enough to figure things out
    • Offline is not a degenerate case, it's the base case
      • By starting from a position assuming that work will be done offline and have to be merged in, you're forced to deal with the distributed computing problem from the beginning rather than pretending everything is synchronous
• What about the database?
  • CRDTs to the rescue
    • Did some work for a tablet company that required offline-first
    • There are good data structures built to handle conflicts gracefully
      • ...and they're effectively append-only logs of events with strategies for timestamping and resolving conflicts!
• DXOS is a framework: Rails for building local-first software
  • Importantly, DXOS wraps the CRDT (automerge) in a client-side database
  • DXOS solves the distributed systems problem at the framework level
  • Users own their own data - apps request access to it
  • Enables true application interoperability, like files on a filesystem, rather than sucking through the straw of a REST or GraphQL API