Why Local-First has better DX

Phillip van der Merwe — Tue, 20 Aug 2024 17:51:37 +0000

Local-first for FlutterFlow

Phillip van der Merwe — Tue, 23 Apr 2024 19:25:46 +0000

Local-first / offline-first is an application architecture where data is stored "close to the user", in a database on their client device, and synced with a backend database in real-time.

Some features of local-first:

📡 Real-time data streaming

⚡ Instantly reactive UI

💾 Simplified state management

🚫 Always available, offline-first functionality

This video guide provides step-by-step instructions for configuring PowerSync with your FlutterFlow project that has Supabase integration enabled:

Local database > cache 💸

Phillip van der Merwe — Wed, 16 Aug 2023 22:49:19 +0000

Most app developers don't really care about this argument, but they should. Here's why:

Users want delightful apps

We love products that take away mental overhead. The less thinking we have to do to get something done, the better. Using a cache will always require:

more thinking from users OR
more thinking from app developers to work around limitations that will require more thinking from users.

1. Caches are breadcrumbs, users want sandwiches

Caching works by persisting downloaded data. When users are offline, they can follow the trail back but they can't keep on exploring.

WIN #1 for local database: they let users explore parts unknown.

2. Caches are leaky buckets

Caches don't know how much data is on the way so they have to keep deleting data to make space available. Haven't accessed data recently? Too bad, you can't see it anymore.

WIN #2 for local database: all data is there for you no matter how dusty it's become.

3. Caches keep stale data, users want fresh data

Cached data needs to be redownloaded if it has been updated elsewhere. If offline users want to access data that hasn't recently been redownloaded, they can't.

WIN #3 for local database: background syncing keeps local databases fresh.

4. Caches can cause slowness 🦥, users want fastness ⚡

Because a cache introduces a secondary source of data, an app needs to run through logic to decide:

Am I online?
Can I request server data?
Did the request succeed?
Do I need to look for the data in the cache?

This is usually fine, but not when connectivity is still kind of available but very poor.

WIN #4 for local database: as the only source of data, apps don't waste time wondering where to fetch data.

Easy, we'll all just use local databases from now on

Not so fast! Big BaaS providers like Firebase don't have easy ways to do that. Why? Does it have something to do with how they charge for data transfer between your app and their cloud and if you had a local database you'd make fewer calls? I can't say. But sync and consistency is a hard problem to solve whether you're using Firebase or something else.

So what are you doing about it?

I'm working on an easy + (soon-to-be) open source way to solve sync and make using local databases easy for devs. Follow our progress on discord or check out powersync.co.

DEV Community: Phillip van der Merwe