Integrate firestore for our particles real-time data #29

New Issue

2026-03-16T19:15:36Z

talksik commented

2026-03-16 19:15:36 +00:00

(Migrated from github.com)

We are accepting not to implement #4 because there is far too much risk. It is smarter to ship quicker with firestore, since it will handle offline writes, reconnects, and multiplayer real-time. In addition, we will still utilize our orion server for all other concerns. Firestore will be purely used as a nosql database for particles, improving scalability of reads.

We are reducing the risk of lock-in by continuing to use terraform for things like firestore instance. We have the engineering skills to migrate off later, especially if we have a team. We do not need to use all of the bloat of firebase, as we have great infrastructure in our backend already.

By completing this issue, we should have a real-time application that works for multiple clients seamlessly. This should 10x our speed of developing features such as stream labels or #20. We also prefer to implement super dynamic experiences such as huddles without worrying about real-time implementation.

We also have lots of other problems such as #14 or #8 which will take more of our energy at this point in the game.

Another variable of this decision is that we are bootstrapped, and we could spend months on a sophisticated sync engine, but then lose steam for building a product business. We rather pay Google for the problem they solved, and march towards getting our product to a point of 10 teams loving it. We can most definitely get to 10,000 desks without needing to migrate off.

Create firebase project & firestore resource via terraform
Connect to firestore in our typescript client
Design how organization billing (networks) will work with external commz and being part of multiple networks / orgs. Can people be part of multiple networks? How will billing work?
Model our particle data in firestore; figure out details like permissions and hierarchy for fast reads. Ordering streams by latest activity at, unread count per user, particles "seen by", etc.
- We should decide on how we will list the streams in the root path [snapchat chats vs. stories]

We are accepting not to implement #4 because there is far too much risk. It is smarter to ship quicker with firestore, since it will handle offline writes, reconnects, and multiplayer real-time. In addition, we will still utilize our `orion` server for all other concerns. Firestore will be purely used as a nosql database for particles, improving scalability of reads. We are reducing the risk of lock-in by continuing to use terraform for things like firestore instance. We have the engineering skills to migrate off later, especially if we have a team. We do not need to use all of the bloat of firebase, as we have great infrastructure in our backend already. By completing this issue, we should have a real-time application that works for multiple clients seamlessly. This should 10x our speed of developing features such as stream labels or #20. We also prefer to implement super dynamic experiences such as huddles without worrying about real-time implementation. We also have lots of other problems such as #14 or #8 which will take more of our energy at this point in the game. Another variable of this decision is that we are bootstrapped, and we could spend months on a sophisticated sync engine, but then lose steam for building a product business. We rather pay Google for the problem they solved, and _march towards getting our product to a point of 10 teams loving it._ We can most definitely get to 10,000 desks without needing to migrate off. --- - [x] Create firebase project & firestore resource via terraform - [x] Connect to firestore in our typescript client - [x] Design how organization billing (networks) will work with external commz and being part of multiple networks / orgs. Can people be part of multiple networks? How will billing work? - [x] Model our particle data in firestore; figure out details like permissions and hierarchy for fast reads. Ordering streams by latest activity at, unread count per user, particles "seen by", etc. - [x] We should decide on how we will list the streams in the root path [snapchat chats vs. stories]

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: FlowyLabs/llink#29