FR Firestore - Manual cache manipulation, app wide offline with external backend

[Aetherall]

Operating System

not applicable

Environment (if applicable)

web/ios/android/react-native

Firebase SDK Version

11.3.1

Firebase SDK Product(s)

Firestore

Project Tooling

firebase-sdk-js
react
react-native
react-native-firebase
cloud functions
cloud run
firestore

Detailed Problem Description

App wide offline using firebase sdk as a backend for optimistic compensations

Firestore by itself is a great solution for apps with simple business rules.
By adding an external backend, a lot of us have been able to bring real time to more complex systems.

I am using firestore as a projection store for the read models of a CQRS system.
This has proven to be a really efficient way to keep great flexibility on our models,
while keeping compatibility with our mobile users while they run on previous versions.

When using a backend, you cannot use one of the best features for users: Offline

Multiple projects (including the one im working on) have to rely on complex systems to make up for that loss.
Online, people advise to use redux to store firestore data, and to add optimistic on top. I've also seen tanstack libraries recommended for that.
Effectively, using those solutions means re-implement in userland what firebase already does incredibly well.
(often using questionable techniques, impacting performances, and always using at least twice the storage).

Those approaches also require having 2 implementations for each queries.

• One for firestore.
• One for whatever additionnal storage solution you went with.

And even with good design decisions and a clear vision for the frontend architecture, on a big project, it often becomes impractical If you are still trying to replicate the extent of reactiveness no-backend firebase allows.

Why posting here ?

It seems firebase sdks are a few changes away from solving that particular problem.

Essentially, firebase could allow "cache" mutations, that are never sent to the server,
while still affecting cache, notifying listeners off affected queries.

I am not really sure about the best solution for it, but while trying to implement it myself, I found out some points of concern.

For it to be safe, it would probably need to block the dequeue of mutations sent to server.
The simplest way to avoid all conflicts would be a "readonly" mode on initialization.

Also, we need a way to discard that mutation, either because of a failure, or because we received a new snapshot that contains the results of the mutation, that has been produced by the external backend.

TLDR

How implementable would custom cache management be in firebase sdk ?
Would you consider exposing methods to allow a custom implementation of such system ?

Steps and code to reproduce issue

I could experiment pretty far by blocking write stream initialisation.
I got optimistic behavior working well, but It will decohere over time without allowing to manage cached mutations

    const client = db._firestoreClient;
    const store = client?._onlineComponents?.remoteStore;
    if (!store) return;
    for (const key in store) {
      const value = store[key as keyof typeof store] as unknown;
      if (typeof value !== "object" || value === null) continue;
      if ("constructor" in value) {
        if (value.constructor.name.includes("WriteStream")) {
          Object.defineProperty(value, "state", {
            get() {
              return 1;
            },
            set(v) {
              console.log(v);
            },
          });
        }
      }
    }

[milaGGL]

Hi @Aetherall, thank you for raising this feature request. I wonder if "disableNetwork" could fulfill your requirements. And if it doesn't, what could be the issue.

[Aetherall]

Hi @milaGGL , thanks for your answer 😄

Unfortunately, disabling network would not address this use case.

Users still need to read from the database, execute document reads, queries, and subscribe to documents and query changes.

The feature request is more about allowing interactions with the cache in order to maintain offline features.

In the snippet I provided, I showed an experimentation of disabling network for the write stream
( not the read stream, still need to make queries and listen to snapshots ).

In this experiment, I could make make writes and see the impact across multiple queries.
However, it cannot work in a real world scenario
Letting mutations pile up within the client without being able to prune/cancel/acknowledge them is the limitation

Hence the issue: It seems that firebase is pretty close to allow this use case. Cache mutations are already manipulated using a batchId internally. Exposing a function to insert cache only mutations, and delete them by id would do the trick.

Please dont hesitate to ask for more info :)

[milaGGL]

Hi @Aetherall, we have received similar feature requests in the past as well, and this is definitely something we would like to consider in the future. While we can't implement it immediately due to current capacity, we've added it to our backlog for future review. Internal users please see b/398891750.

I will keep this ticket open and update the thread if there are any changes.