This isn't about best practices, this is about the messy reality of working on someone else's project that grew organically without planning over 10 years.
Dev: You're not supposed to use a document database as a relational DB, but ... it's already there! We already have the client set up in our ancient Python 3.5 app, so what's the harm in |product requirement for putting relational data in NoSQL|?
What is the harm in using Firestore as a relational database? It's hard to ask this question of The Internet.
I'm curious about the messy job of inheriting systems that grew organically over 10 years without anyone thinking about sustainable architecture.
Do you have data in your Firestore/NoSQL DB that would be very comfortable in a relational database? What happened to get you there? What are the pain points? Is it even a problem?
If you've built things before, you have started with something small and manageable and watched it grow. You just needed a few entities in Firestore, but now your customers are asking for reports!
My recent experience on a project
- How many items had the customer ordered in the past 6 months? Sure, that's easy!
- Fetch all of the OrderVendor-specific webhook configurations for all orders for Customers from ParentCompany XYZ. Okay... let's write some code.
- Accounting just called and there was a mistaken price correction on "beef jerky" on September 1st before our annual sale, so please update all OrderLineItem.Price where Product.name == "beef jerky" and Order.Date is after Sept 1st. Okay... let's write some code.
In my experience, Firestore seems like a great idea until you have to go and do the normal, messy job of working on a system designed.
The outcome is that my team spends an inordinate amount of time building reports in Python that should be SQL queries.
Top comments (0)