5 ms·

Please go into some details. I'm on a committee evaluating firebase and I'm curious how it fails at scaling.

pier25 7y ago
The biggest pain is that both DBs are extremely limited. You can't search for example. No joins, relations, or anything remotely fancy. There are some very very basic filtering capabilities but other than that you either load all the data in the client and do your work there, or you use a proxy (cloud function, node server, etc) and lose realtime and sync. Or maybe use Elastic on top [1]. Most of your Firebase logic will live in your client(s). If you have multiple clients (web, iOS, Android, etc) you will have to write and maintain the same logic multiple times in different languages. And since the DBs are so barebones you will need a lot of logic to read and write. Pretty much all the business logic you'd have in a server will be in your client(s). You also have cloud functions which have the worst dev experience I've seen with serverless. Deploying takes forever, sometimes as high as 2-3 mins, and you will need to deploy very often as most of your functions won't run locally [2]. Debugging is done via the Firebase console which is a painfully slow Angular 1 app. For websites the complete Firebase SDK is 215kB gzipped and you will need most of it [3]. You can define database rules using a JSON-like language for permissions and schema but it will get super messy as your project grows and become unmaintainable. Unless you are doing a small project or a prototype get as far away as you can from Firebase. If you do need a serverless DB look into Fauna DB which gives you everything you expect from a serious DB. Or if you're looking for a zero-config backend look at Hasura like I've mentioned earlier. [1] https://medium.com/joolsoftware/extending-firebase-with-cloud-functions-elasticsearch-129fbbb951e0 https://medium.com/joolsoftware/extending-firebase-with-clou... [2] https://firebase.google.com/docs/functions/local-emulator https://firebase.google.com/docs/functions/local-emulator [3] https://bundlephobia.com/result?p=firebase@7.14.2 https://bundlephobia.com/result?p=firebase@7.14.2
- noahtallen 7y ago
  Another issue is environments. It is generally a good idea to have a non-prod database agains which to test new queries and changes. This is impossible with firebase/firestore without some hacks. In a previous job, we had two entirely separate firebase projects, one for dev and one for prod because it became untenable to test new database structure and changes against the prod DB.
  - pier25 7y ago
    Oh yes Jesus that's really bad too.
  - databrecht 7y ago
    Good to know in that case, that you can create as many databases as you want in one FaunaDB account and even create databases in databases (parent keys get access to child databases) and probably won't get these issues. e.g. I run integration tests and create/destroy a child db for each test suite. Disclaimer: I'm a dev advocate there so I'm obviously biased

The biggest pain is that both DBs are extremely limited. You can't search for example. No joins, relations, or anything remotely fancy. There are some very very basic filtering capabilities but other than that you either load all the data in the client and do your work there, or you use a proxy (cloud function, node server, etc) and lose realtime and sync. Or maybe use Elastic on top [1]. Most of your Firebase logic will live in your client(s). If you have multiple clients (web, iOS, Android, etc) you will have to write and maintain the same logic multiple times in different languages. And since the DBs are so barebones you will need a lot of logic to read and write. Pretty much all the business logic you'd have in a server will be in your client(s). You also have cloud functions which have the worst dev experience I've seen with serverless. Deploying takes forever, sometimes as high as 2-3 mins, and you will need to deploy very often as most of your functions won't run locally [2]. Debugging is done via the Firebase console which is a painfully slow Angular 1 app. For websites the complete Firebase SDK is 215kB gzipped and you will need most of it [3]. You can define database rules using a JSON-like language for permissions and schema but it will get super messy as your project grows and become unmaintainable. Unless you are doing a small project or a prototype get as far away as you can from Firebase. If you do need a serverless DB look into Fauna DB which gives you everything you expect from a serious DB. Or if you're looking for a zero-config backend look at Hasura like I've mentioned earlier. [1] https://medium.com/joolsoftware/extending-firebase-with-cloud-functions-elasticsearch-129fbbb951e0 https://medium.com/joolsoftware/extending-firebase-with-clou... [2] https://firebase.google.com/docs/functions/local-emulator https://firebase.google.com/docs/functions/local-emulator [3] https://bundlephobia.com/result?p=firebase@7.14.2 https://bundlephobia.com/result?p=firebase@7.14.2

noahtallen 7y ago
Another issue is environments. It is generally a good idea to have a non-prod database agains which to test new queries and changes. This is impossible with firebase/firestore without some hacks. In a previous job, we had two entirely separate firebase projects, one for dev and one for prod because it became untenable to test new database structure and changes against the prod DB.
- pier25 7y ago
  Oh yes Jesus that's really bad too.
- databrecht 7y ago
  Good to know in that case, that you can create as many databases as you want in one FaunaDB account and even create databases in databases (parent keys get access to child databases) and probably won't get these issues. e.g. I run integration tests and create/destroy a child db for each test suite. Disclaimer: I'm a dev advocate there so I'm obviously biased