Skip to content(if available)orjump to list(if available)

Building Local-First Flutter Apps with Riverpod, Drift, and PowerSync

hosh

Let's be clear. This post describes an architecture that is offline-first, not local-first.

One of the main goals of local-first is so that the user of a local-first application owns their own data. (See Martin Kleppmann's paper on this).

As such, local-first applications don't necessarily have a concept of a central server. `git` is local-first, though most teams synchronize to a hub such as Github or Gitlab. This is a design principle to get away from having to sync to the cloud, making it more difficult to monetize as a SAAS. There seems to be a growing trend of people promoting offline-first applications as local-first, but structuring it to still lock people's data into their SAAS. (If you want to lock them in, then say so -- call it offline-first).

A true local-first mobile app would allow me to collaborate with someone in the same room using Bluetooth, even out somewhere where I don't have wifi, cell service or Starlink

See:

- https://martin.kleppmann.com/papers/local-first.pdf

- https://www.inkandswitch.com/essay/local-first/ (Same, but in html)

doawoo

As a newer user of Flutter I found Riverpod to be extremely heavy and have a lot more mental overhead than using stateless widgets with Hooks.

Any particular reason you personally prefer Riverpod?

dinko7

Hi, author of the article here.

Any state management approach requires you to adapt your way of thinking, whether that be BLoC, Riverpod, Redux or anything you want to use.

Rivepod gained popularity because it's really simple to pick up: create a Notifier, create a Provider for it, and observe, while some other approaches require additional boilerplate, setup, and understanding.

Your approach would work if you are only observing that state from a single widget, which might not always be the case. Additionally, assuming useState is using setState under the hood means it will rebuild the whole widget on change, while with Riverpod, you have the flexibility to wrap any part of a complex widget into a Consumer or listen to only part of the exposed state on the Notifier with .select().

To put it simply: - Notifiers are used for app state - Hooks are used for ephemeral state (local widget state)

Hope this clears it bit for you.

doawoo

Great summary, it does indeed! Thanks for taking the time to reply

vin047

Riverpod does a lot more than just state management - it also handles dependency injection and reactive caching.

Here’s a great guide on using Riverpod: https://codewithandrea.com/articles/flutter-state-management...

zerr

I wonder why Flutter didn't gain traction in US. It seems to be more or less popular in poor countries and even less in Europe. But in US it seems to be quite a no name. Why US is so JavaScript-centric?

vin047

There are a lot more JS and Native developers compared to Flutter/Dart developers in the West. Plus fear-mongering around Google dropping development of Flutter.

dleeftink

> poor countries

Ah yes, those fluttering countries and their fluttery ways

sgt

Would this work with Flutter Web as well?

kobieps

Yes

sgt

Flutter Web used to be pretty slow but I note that it has improved substantially in the last 2 years.

null

[deleted]

account-5

Why not just use sqlite instead of drift?

kobieps

Probably easier to ask an LLM, but here goes: drift gives you type-safe queries which lets you catch any errors at compile time instead of runtime (which is the case with sqlite). There are other benefits but that's probably the main one.

taormina

It’s still SQLite. Drift as an ORM they are using on top of SQLite.