I absolutely despise Firebase Firestore (the database technology that was “hacked”). It’s like a clarion call for amateur developers, especially low rate/skill contractors who clearly picked it not as part of a considered tech stack, but merely as the simplest and most lax hammer out there. Clearly even DynamoDB with an API gateway is too scary for some professionals. It almost always interfaces directly with clients/the internet without sufficient security rules preventing access to private information (or entire database deletion), and no real forethought as to ongoing maintenance and technical debt.
A Firestore database facing the client directly on any serious project is a code smell in my opinion.
It’s like people learn how to make a phone app in React Native or whatever, but then come to the shocking and unpleasant realisation that a data-driven service isn’t just a shiny user interface - it needs a backend too.
But they don’t know anything about backend, and don’t want to, because as far as they are concerned all those pesky considerations like data architecture, availability, security, integrity etc are all just unwanted roadblocks on the path to pushing their shiny frontend.
And so when a service seemingly provides a way to build an app without needing to care about any of those things, of course they take it, with the minimum amount of thought.
And I get it, I really do. The backend usually is the genuine hard part in any project, because it’s the part with all the risk. The part with all the problems. The place where everything can come crashing down or leak all your data if you make bad decisions. That’s the bothersome nature of data-driven services.
But that’s why the backend is especially the part you can’t build anything decent without thinking about.
I think it’s less about the tech picked and more about developers with no sense of security and a poor understanding of networking. I’ve seen far too many web applications where the developer needed some sort of database behind it (MySQL, PostGres, MSSQL) and so they stood up either a container or entire VM with a public IP and whatever the networking layer set to allow any IP to hit the database port. The excuse is almost always something like, “we needed the web front end to be able to reach the database, so we gave the database server/container a public IP and allowed access”. Which is wonderful, right up until half of the IP addresses in Russia start trying to brute force the database.
I agree that this is ultimately a problem with developers lacking security knowledge and general understanding, but my issue with Firestore specifically is that it is a powerful tool that, while it can be adopted as part of a carefully considered tech stack, lends itself most naturally towards being a blunt force instrument used by these kinds of developers.
My main criticism of Firestore is that it offers a powerful feature set that is both extremely attractive to amateur or constrained developers while simultaneously doing a poor job of guiding said amateurs towards creating a secure and well designed backend. In particular, the seemingly expected use case of the technology as something directly interfaced with by apps and other clients, as evidenced by the substantial support and feature set for this use case, is the main issue. This no-code no-management client driven interaction model makes it especially attractive to these developers.
This lack of indirection through an API Gateway or service, however, imposes additional design considerations largely delegated to the security rules which can easily be missed by a beginner. For example:
Many examples of amateurs take an open-by-default approach, only applying access and write restrictions where necessary and miss data that should be restricted
Some amateurs deploy databases with no access or write restrictions at all
There is no way to only allow a “view” of a document to a request, instead a separate document and security rules containing the private fields needs to be created. This can be fairly simple to design around but seems to be a bit of a “gotcha”, plus if you have similar but non identical sets of data that needs to be accessible by different groups it must be duplicated and manually synchronized.
Since there is no way to version data models, incompatible changes require complicated workarounds or an increasingly complicated deserialization process on the client side (especially as existing clients continue to write outdated models).
Schema validation of data written by clients to the database is handled by security rules, which is seemingly unintuitive or missed by many developers because I’ve seen plenty of projects miss it
If clients are writing data directly, it can become fairly complex to handle and subsequently maintain their contributions, especially if the aforementioned private data documents are required or the data model changes.
All of these pitfalls can be worked around (although I would still argue for some layer of indirection at least for writes), but at this point I’ve been contracted to 2 or 3 projects worked on by “professionals” (derogatory) that failed to account for any of these issues and I absolutely sick to death of it. I think a measure of a tools quality is whether it guides a developer towards good practices by design and I have found Firestore to completely fail in that regard. I think it can be used well, and it is perfectly appropriate for small inconsequential (as in data leaks would be inconsequential) single developer projects, but it almost never is.
I absolutely despise Firebase Firestore (the database technology that was “hacked”). It’s like a clarion call for amateur developers, especially low rate/skill contractors who clearly picked it not as part of a considered tech stack, but merely as the simplest and most lax hammer out there. Clearly even DynamoDB with an API gateway is too scary for some professionals. It almost always interfaces directly with clients/the internet without sufficient security rules preventing access to private information (or entire database deletion), and no real forethought as to ongoing maintenance and technical debt.
A Firestore database facing the client directly on any serious project is a code smell in my opinion.
It’s like people learn how to make a phone app in React Native or whatever, but then come to the shocking and unpleasant realisation that a data-driven service isn’t just a shiny user interface - it needs a backend too.
But they don’t know anything about backend, and don’t want to, because as far as they are concerned all those pesky considerations like data architecture, availability, security, integrity etc are all just unwanted roadblocks on the path to pushing their shiny frontend.
And so when a service seemingly provides a way to build an app without needing to care about any of those things, of course they take it, with the minimum amount of thought.
And I get it, I really do. The backend usually is the genuine hard part in any project, because it’s the part with all the risk. The part with all the problems. The place where everything can come crashing down or leak all your data if you make bad decisions. That’s the bothersome nature of data-driven services.
But that’s why the backend is especially the part you can’t build anything decent without thinking about.
I think it’s less about the tech picked and more about developers with no sense of security and a poor understanding of networking. I’ve seen far too many web applications where the developer needed some sort of database behind it (MySQL, PostGres, MSSQL) and so they stood up either a container or entire VM with a public IP and whatever the networking layer set to allow any IP to hit the database port. The excuse is almost always something like, “we needed the web front end to be able to reach the database, so we gave the database server/container a public IP and allowed access”. Which is wonderful, right up until half of the IP addresses in Russia start trying to brute force the database.
I agree that this is ultimately a problem with developers lacking security knowledge and general understanding, but my issue with Firestore specifically is that it is a powerful tool that, while it can be adopted as part of a carefully considered tech stack, lends itself most naturally towards being a blunt force instrument used by these kinds of developers.
My main criticism of Firestore is that it offers a powerful feature set that is both extremely attractive to amateur or constrained developers while simultaneously doing a poor job of guiding said amateurs towards creating a secure and well designed backend. In particular, the seemingly expected use case of the technology as something directly interfaced with by apps and other clients, as evidenced by the substantial support and feature set for this use case, is the main issue. This no-code no-management client driven interaction model makes it especially attractive to these developers.
This lack of indirection through an API Gateway or service, however, imposes additional design considerations largely delegated to the security rules which can easily be missed by a beginner. For example:
All of these pitfalls can be worked around (although I would still argue for some layer of indirection at least for writes), but at this point I’ve been contracted to 2 or 3 projects worked on by “professionals” (derogatory) that failed to account for any of these issues and I absolutely sick to death of it. I think a measure of a tools quality is whether it guides a developer towards good practices by design and I have found Firestore to completely fail in that regard. I think it can be used well, and it is perfectly appropriate for small inconsequential (as in data leaks would be inconsequential) single developer projects, but it almost never is.
@EmilyIsTrans @lena
sounds like firebase itself is a hack.
I’m honestly embarrassed by my fellow devs more often than not these days.
What the fuck happened to craftsmanship? Or taking pride in your work?
oh right, techbro startup culture garbage ended it.