English for Triplit Developers

Triplit is a local-first database that syncs automatically between client and server, so conversations about it revolve around a different mental model than typical request-response apps: data lives locally first, and the network is treated as an enhancement rather than a dependency.

Key Vocabulary

Local-first — an architecture where the application reads and writes to a local store first, treating the network sync as a background concern rather than something the UI blocks on. “The UI shouldn’t wait on a network round trip for this — local-first means we write to the local store immediately and let sync happen in the background.”

Optimistic update — a UI change applied immediately based on the assumption that a write will succeed, then reconciled or rolled back if the server later rejects it. “The list updates instantly because we’re doing an optimistic update — if the sync later fails, we roll the UI back and surface an error instead of blocking upfront.”

Conflict resolution — the logic that determines how two changes to the same data, made concurrently by different clients while offline, are merged once both come back online. “These two users edited the same record while offline — conflict resolution decides which change wins, or whether we need to merge both.”

Live query — a query subscription that automatically re-runs and updates its result set whenever the underlying data changes, without the developer manually invalidating or refetching. “We don’t need to manually refetch this list after a mutation — it’s a live query, so the UI updates automatically the moment the underlying data changes.”

Sync engine — the background process responsible for reconciling local and remote state, retrying failed writes, and propagating changes to other connected clients. “If updates aren’t showing up on other devices, check whether the sync engine actually reconnected after the network drop, rather than assuming the write itself failed.”

Common Phrases

• “Does this need to block on the network, or can we make this a local-first, optimistic update?”
• “What’s our conflict resolution strategy if two offline clients edit the same row?”
• “Is this a live query, or do we still need to manually refetch after this mutation?”
• “Did the sync engine actually reconnect, or is this a write failure we need to handle separately?”

Example Sentences

Explaining the architecture to a new engineer: “Unlike a typical REST app, we’re not waiting on the server for every read — this is local-first, so the local store is the source of truth the UI renders from immediately.”

Debugging a sync issue: “The data looks correct locally but isn’t propagating to other clients — that points to the sync engine, not the local write itself.”

Discussing a merge conflict: “Both of these edits happened while offline, so we need a conflict resolution rule here — last-write-wins might not be good enough for this particular field.”

Professional Tips

• Introduce local-first early when onboarding engineers from a traditional client-server background — it changes how they should think about loading states and error handling.
• Be specific about optimistic update rollback behavior in code review — an optimistic update without a clear failure path can leave the UI showing stale, incorrect state.
• Document the conflict resolution strategy per data type explicitly — assuming a single global strategy (like last-write-wins) works everywhere is a common and costly mistake.
• Rely on live query subscriptions instead of manual refetch logic wherever possible — reintroducing manual refetching defeats much of the point of a local-first sync engine.

Practice Exercise

1. Explain to a developer from a traditional REST background what “local-first” changes about how the UI should be built.
2. Describe a scenario where an optimistic update needs a rollback path.
3. Write a sentence describing a conflict resolution rule for a specific field, and why last-write-wins might not be appropriate for it.