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]
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
orionserver 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.