GetDutchie / brick

An intuitive way to work with persistent data in Dart

Home Page:https://getdutchie.github.io/brick/#/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to use with Firestore.

rutaba1 opened this issue · comments

Hi, I was reading the readme file and apparently there was an example to use brick_cloud_firestore but it's very outdated and is not null safe. How can I add a a Firebase Provider in my Repository and models? Basically I want to use both RestProvider and FirebaseProvider. For reference I'm adding code for my repository implementation.

class Repository extends OfflineFirstWithRestRepository {
  Repository._(String endpoint)
      : super(
          migrations: migrations,
          restProvider: RestProvider(
            endpoint,
            modelDictionary: restModelDictionary,
          ),
          sqliteProvider: SqliteProvider(
            "Brick.sqlite",
            databaseFactory: databaseFactory,
            modelDictionary: sqliteModelDictionary,
          ),
          offlineQueueManager: RestRequestSqliteCacheManager(
            'brick_offline_queue.sqlite',
            databaseFactory: databaseFactory,
          ),
          autoHydrate: true,
        );

  factory Repository() => _singleton!;

  static Repository? _singleton;

  static void configure(String endpoint) {
    _singleton = Repository._(endpoint);
  }
}

Hey @rutaba1 thanks for using Brick. I can't speak to the viability of that package since it's not in the Brick core repo, but I agree that it does look unmaintained.

Firebase's first-party offering for realtime database and Firestore support offline caching natively without any additional configuration. Further, since it's document storage, it's a different querying method. So you'd be pulling from paths instead of from relations like you would with SQLite. This would complicate Brick's native caching methodology.

For using RestProvider and FirestoreProvider - both of these would be considered a type of remoteProvider. OfflineFirstRepository only supports one remote provider because, in good practice, you'd have a single source of truth as your backend. I would recommend against having two sources of truth. Theoretically you could do this, but you'd need to extend the OfflineFirstRepository, override all public/protected methods and transmit (and handle for unsuccessful responses/errors) your secondary remote provider, and potentially change the data transmission with a custom generator package that would be best building on the json_generator.