Package selection guidance compiled from public package information, community data, and project usage.
A Flutter package that implements an offline-first data strategy using Brick, routing data requests through local storage providers before accessing Supabase. This ensures seamless user experience even without internet connectivity by prioritizing cached data and synchronizing with Supabase when available. It integrates smoothly with Supabase’s PostgreSQL database for persistent, real-time data handling across platforms.
Use cases
Offline-first mobile applications
Real-time data sync with Supabase
Cross-platform data persistence
Apps requiring reliable local data access
Seamless fallback during network outages
Key features
Local-first data routing
Supabase integration
Automatic sync on connectivity
Persistent SQL storage
Cross-platform support
Built-in caching layer
Suitable for
Developers building resilient apps
Teams using Supabase as backend
Projects needing offline functionality
Flutter apps targeting multiple platforms
Applications requiring real-time data updates
Considerations
Requires understanding of Brick architecture
Supabase account needed for full functionality
Additional setup for sync logic
May increase app size due to local storage
Network state handling required for optimal sync
Original README
Original README snapshot from the linked source repository. Visit the repository for the latest content.
An intuitive way to work with persistent data in Dart.
Brick is an extensible query interface for Dart applications. It's an all-in-one solution responsible for representing business data in the application, regardless of where your data comes from. Using Brick, developers can focus on implementing the application, without concern for where the data lives. Brick was inspired by the need for applications to work offline first, even if an API represents your source of truth.
Quick Start
Add the packages:
dependencies:# Or brick_offline_first_with_graphql# Or brick_offline_first_with_supabasebrick_offline_first_with_rest:sqflite:# optionaldev_dependencies:# Or brick_offline_first_with_graphql_build: any# Or brick_offline_first_with_supabase_build: anybrick_offline_first_with_rest_build:build_runner:
Configure your app directory structure to match Brick's expectations:
mkdir -p lib/brick/adapters lib/brick/db;
Add models that contain your app logic. Models must be saved with the .model.dart suffix (i.e. lib/brick/models/person.model.dart).
Run dart run build_runner build to generate your models and sometimes migrations. Rerun after every new model change or dart run build_runner watch for automatic generations. You'll need to run this again after your first migration.
And generate (de)serializing code to fetch to and from multiple providers:
$ (flutter) pub run build_runner build
Fetching Data
A repository fetches and returns data across multiple providers. It's the single access point for data in your app:
classMyRepositoryextendsOfflineFirstWithRestRepository{
MyRepository();
}
final repository = MyRepository();
// Now the models can be queried:final users = await repository.get<User>();
Behind the scenes, this repository could poll a memory cache, then SQLite, then a REST API. The repository intelligently determines how and when to use each of the providers to return the fastest, most reliable data.
// Queries can be general:final query = Query(where: [Where('lastName').contains('Muster')]);
final users = await repository.get<User>(query: query);
// Or singular:final query = Query.where('email', 'user@example.com', limit1: true);
final user = await repository.get<User>(query: query);
Queries can also receive reactive updates. The subscribed stream receives all models from its query whenever the local copy is updated (e.g. when the data is hydrated in another part of the app):
final users = repository.subscribe<User>().listen((users) {})
Mutating Data
Once a model has been created, it's sent to the repository and back out to each provider:
final user = User();
await repository.upsert<User>(user);
Associating Data
Repositories can support associations and automatic (de)serialization of child models.
classHatextendsOfflineFirstWithRestModel{
finalString color;
Hat({this.color});
}
classUserextendsOfflineFirstWithRestModel{
// user has many hatsfinalList<Hat> hats;
}
final query = Query.where('hats', Where('color').isExactly('brown'));
final usersWithBrownHats = repository.get<User>(query: query);