Firebase without the fuss.
Define fields once, then just .write()
, .read()
, .delete()
.
Type-safe. Clean. Fast. Easy. No string keys. No casting. No boilerplate.
Supports: Firestore
, Realtime Database
(in progress)
Coming soon: Auth, Storage, Remote Config, App Check, Functions, and more.
๐ Roadmap
x
Core Functionalityx
Firestorex
Realtime Database
Philosophy
Firefast was built out of real-world frustration:
- Constantly using string keys everywhere (prone to typos and errors).
- Repeating serialization and parsing code again and again.
- Handling different data types manually across Firestore, Realtime Database, and others.
- Struggling to maintain clean separation of concerns.
Firefast solves this by letting you define fields once โ type-safe, clean, and automatic โ and then just call .write()
, .read()
, .delete()
without worrying about anything else.
No more messy strings, no boilerplate serialization, no manual conversions.
You define your data model once โ the fields know how to serialize, deserialize, validate, adapt, and fetch themselves.
And that's it.
Why no await read()
returning data?
In Firefast, when you call:
await document.read();
it does not return anything.
Because everything was already defined beforehand โ what to read, how to adapt it, where to save it, how to validate it.
You don't need to "handle the result" manually.
It's clean. It's safe. It's scalable.
Fields First: Define Once, Use Everywhere
You define fields using FireValue<T>
objects โ strongly typed and automatically adapted to any database.
โ
Native Dart types:
int
, bool
, double
, String
, DateTime
, Uint8List
, Map<String, dynamic>
, etc.
โ
Database Adaptation:
Bytes? Automatically become Firestore Blob
s or encoded for Realtime DB.
DateTime? Automatically mapped as timestamps.
Maps? Automatically stored as JSON or object fields.
โ
Events:
Define what happens when a new value is fetched โ once.
โ
Guards (Optional):
Add permission checks, rate limits, or other conditions without touching your database logic.
Small Example: First Field
final nameField = FireValue<String>(
'name',
toFire: user.name.toFire(),
// fromFire: optional
);
Now this field knows:
- Its name ("name")
- Its type (
String
) - How to pull the data locally when writing to the database
- (Optionally) how to handle new data when reading from the database
You can define fields with only toFire
, only fromFire
, or both.
You can also easily use .toFire()
on simple values without custom logic:
final ageField = FireValue<int>(
'age',
toFire: 30.toFire(), // send to fire
);
Or use full control if needed:
final backupField = FireValue<Uint8List>(
'dataBackup',
toFire: ToFire(generateBackup), // send to fire
fromFire: FromFire(restoreBackup), // get from fire
);
Node / Document: Build Once
Now you link your fields to a document or a realtime node:
final userDoc = nameField.firestoreNewDoc("users", userId);
Or with multiple fields:
[nameField, ageField].firestoreNewDoc("users", userId);
Then, Just Use It
Write:
await userDoc.write();
Read:
await userDoc.read();
Delete:
await userDoc.delete();
And you're done. No parameters. No strings. No casting. No parsing. All defined once.
Firefast is About
- Type safety โ
- One-time field definition โ
- Automatic adaptation to any database โ
- Built-in event handling โ
- Optional validation & permission guards โ
- No runtime string keys, no runtime parsing โ
- Clear separation between business logic and database operations โ
๐ฏ Why Firefast?
โ
Minimal Boilerplate โ define once, reuse anywhere
โ
Separation of Concerns โ field logic lives in the field
โ
Type Safety โ avoid runtime errors and dynamic
โ
Composable โ easily construct documents, subcollections, fields
โ
Scalable โ works across all Firebase services (Firestore, RTDB, and more coming)
โ
Clean API โ no manual set()
, get()
, or Map<String, dynamic>
juggling
๐ง Under the Hood
- Built on a modular path system (
col().doc().withFields()
) - Abstracted data sources (
FastDataPathSource
) allow plug-and-play with Firestore, Realtime DB, Remote Config, etc. - Extensible caching system (
FireCacheBox
) with cooldowns and offline strategies (coming soon)
๐ฆ Installation
dependencies:
firefast: ^latest
Contribute
Pull requests, feedback, and ideas are welcome!
Help shape a better Firebase developer experience.
โคด๏ธ Back -> Table of Contents
Libraries
- core/adapters/fire_adapter_map
- core/adapters/fire_adapters
- core/adapters/list_fire_adapters
- core/fire_port/fire_port
- core/fire_port/fire_port_operation
- core/fire_port/from_fire
- core/fire_port/from_fire_extensions
- core/fire_port/map_entry
- core/fire_port/path_operator
- core/fire_port/to_fire
- core/fire_port/to_fire_extensions
- core/fire_value/fire_value
- core/fire_value/output
- core/fire_value/typedefs
- core/fire_value/values_container
- core/guards/base_value_guard
- core/guards/cooldown_guard
- core/guards/empty_value_guard
- core/guards/fire_guards
- core/guards/fire_value_guard
- core/guards/guarded_operator
- core/guards/operation_guard
- core/guards/operation_guard_status
- core/guards/operation_limiter_base
- core/guards/rate_limiter_guard
- core/path/data_source
- core/path/extensions
- core/path/operatable_object
- core/path/operations
- core/path/operations_no_params
- core/path/path_segment
- core/path/usecases
- firebase/firestore/adapters/adapters
- firebase/firestore/extensions/fire_values
- firebase/firestore/extensions/path
- firebase/firestore/extensions/path_segment
- firebase/firestore/models/datasource
- firebase/firestore/models/firestore_document
- firebase/firestore/models/output
- firebase/firestore/models/path
- firebase/realtime/extensions/fields
- firebase/realtime/extensions/path_extensions
- firebase/realtime/extensions/path_segment
- firebase/realtime/models/datasource
- firebase/realtime/models/realtime_node
- firebase/realtime/models/realtime_node_path
- firefast_core
- firefast_firestore
- firefast_realtime