Using Firebase
Hi,
I've noticed that indiehackers is using Firebase for its database and auth. Since I've never really played around with FB I wanted to do some research to find out if it's a viable option for building apps faster.
Many of the articles I've read complained about the fact that the provided database is NoSQL. I'm planning on implementing a news site, which would indeed make use of relations (e.g. news can have comments, news can be up voted by users, news should be filterable by tags or any other meta data, ...) - would Firebase be any good for that? (I've honestly got no experience with NoSQL databases)
I really like the concept of having a tool which takes care of data storage and authentication - but I don't want to run into an dead end and regret my choice at a later point.
Thanks and kind regards
I’ve had a similar experience with Firebase — it’s great to get started quickly, but once projects grow, managing data becomes a bit painful.
The console is fine for simple use cases, but in real-world projects I often ended up needing some kind of custom admin panel.
Curious how others are handling this — are you building your own tools or using something existing?
You're not going to run into a dead end with Firebase. It can do everything you want. However, it gives you more than enough rope to hang yourself with, since you have to be intelligent about how to structure your data, just like with other NoSQL tools.
What's equally frightening about running into a dead end would be sudden cost increase. It would be disastrous if the project gains more and more traction from day to day, effectively resulting in financial ruin.
What about that? Even if I've added a neat monetization model, I'm not interested in paying hundreds or even thousands per month just because the service doesn't scale financially (even if it WOULD be covered by the monetization).
I've found that Firebase scales just fine financially. Indie Hackers isn't massive, but it's a fairly big site run entirely on Firebase, and I could probably keep my Firebase bill under $200/mo if was motivated to. I've had more cost troubles with Algolia tbh, but even those would've been preventable if I'd been more thoughtful (read: considered it at all) upfront.
You can model relational data with Firebase. The following video is a good starting point on how: https://youtu.be/jm66TSlVtcc
You will face certain limitations with FB if you would like to do complex queries combined with role-based authorization, but then firebase functions can help. FB really shines when you build mobile apps.
This is the best summary I've seen here.
If you only need basic operations, Firebase can save you so much time. I built www.journalforcouples.com entirely off of Firebase. It's an app for iOS only that has very simple db queries.
Firebase is simple to get started, but like most services, the real cost and complexity comes later.
I’ve built a product where early on we started with Firebase. We were up-and-running quickly. But once we added customers, Firebase began to show its weaknesses. Our product had a real-time chat component, and Firebase simply was too slow for what we needed.
We ended up migrating the database to Postgres and using its built-in JSONB support, which is faster and easier to work with in our case.
Bottom line, if you need a simple way to store document data in json format, Firebase is okay. If you need to store complex relationships and query those relationships across multiple documents, Firebase is not good.
My .02
Interesting, I thought firebase would have been a good use case for real time chat because you can make use of the subscriptions that keep the client and server in sync. Could you elaborate on the challenges you faced with firebase for the RTC feature and what solution you're using with postgrea and JSONB?
(FWIW +1 for using Postgres in general... Of course each project is different, but I find I migrate most projects to postgres pretty quickly if I've started them in firebase as a data store. I've found the authentication services in firebase more useful than firestore personally).
We were using Cloud Functions in combination with Firebase, and the roundtrip times for processing were too slow. Debugging was very difficult too.
In the end, we went with Postgres for the data store, and built the app with Elixir & Phoenix, which is very well suited to real-time chat / notices.
Thanks for the further info. Really helpful to hear your experiences on this. I haven't used elixir/phoenix before, but sounds like a solid choice for real time messaging indeed!
What tool did you use to export?
I think it was this library: https://github.com/jloosli/node-firestore-import-export
We did this about 18 months ago, there’s probably a better process today.
How long did your migration take? I'm thinking of using firebase for mvp, and then switching if needed. Wondering if that's a good strategy or just build in Postgres from start. There's not many complex relationships in my product I don't think.
The most difficult part was extracting all the data from Firebase via the API. They don't make it easy. Fortunately, I found a tool that could 'dump' the Firebase data store, then I wrote a process to import that into Postgres.
We did it with dozens of customers, not thousands or millions, so downtime was less than an hour when we finally cut over. It took many hours of planning and preparation though.
I'd say Firebase is fine for an MVP, but have a plan for migration sooner rather than later.
That's great insight...thanks! Curious, did you consider Firestore before migrating to Postgres?
Not really, I'm a big fan of Postgres so it was an easy decision to go with it.
I'm using firebase for auth and it's more than enough for me, at least for now. I wouldn't use it's database though. I tried it once and it had too many limitations.
A great thing about Firebase is that it's not just Firebase. It's integrated on top of Google Cloud - so you can also use any google cloud service with your project, including a SQL database.
It could be really effective if you take the time to learn it and structure your data well. If your goal is to learn a new technology, go for it. If your goal is to launch something quickly, stick to what you know.
If you just need the auth solution and a database from somewhere else, you can do that.
Just noticed they retired the Flame plan :(
You can always use algolia here >> https://www.algolia.com/ if you feel like you need robust searching. Like they said, the key is knowing how to structure your Cloud Firestore database in an efficient way. Check this video on how this startup ran up a monstrous bill because of their inefficient code:
https://youtu.be/Lb-Pnytoi-8
Make a decision sooner rather than later. I know many people that choose back-end stacks just because that is what their engineer knows, not what is the absolute perfect match for your app. Sometimes, its the front-end framework that dictates this (Flutter & Firebase instead of React Native & Amplify)
Disclaimer:
I use firebase auth, cloud firestore, cloud messaging (notifications) in my apps.
Firebase is great and very extensible. The entire stack for https://hypercharts.co/ is completely serverless on Firebase. I use Firebase for Auth, Database, Storage, Functions, and Hosting. And I absolutely love it. You just have to structure your data is a way that works well in NoSQL.
And for anything that Firebase can't do, you can host a container through GCP with whatever you want.
FYI if you happen to be writing your app with React, I found this written tutorial to be incredibly helpful. It explains setting up a Firebase database and authentication in a little demo project. It was enough for me to get started on my own project.
https://www.robinwieruch.de/complete-firebase-authentication-react-tutorial#sign-up-with-react-and-firebase
There is no problem to structure your data with nosql in the way you need.
I've done https://classalog.org with firebase as backend for:
I host the platform on Zeit as I'm using Next.js for server-side rendering. So far, very happy with my stack.
Would you be interested in trying out https://upminder.io? It's a my own project that can replace firebase and it uses a relational database. You would be able to filter data based on relation values. It's a WIP but it's currently functional.
Our platform at Audiostaq uses firebase. We are a full serverless stack using Google Functions, Cloudflare Workers, Firebase. It works wonders for us and is so easy to make changes.
I strongly endorse firebase. It is easy to use and I personally prefer a noSql database.
However, sql oand noSql have their place in the tech industry. Sql is great for high fidelity, storage efficient, data management. NoSql on the other hand, data duplication is allowed, an you optimize for queries to be simple.
Personally, it took me a while from really understand what are the implcations of using NoSql vs Sql.
I took the liberty of finding the video that really hel0ed me understand: https://youtu.be/5j-xvNtAZQ8
.
You might want to read about atomic updates as well. Atomic updates are a way to ensure data integrity in a NoSql database where some piece of information is duplicated and you need to ensure data is updated in both/all places.
I like the notifications and the crashlytics from Firebase but for any other things t I would always recommend a monolith + postgreSQL .
This is the best way to go with the least cost on the long run.
Just make sure you create a modular architecture and you can plug in more services later. That way you have a very scalable solution. Paying a fixed monthly rate is a lot better than paying per request. Imho.
You can do definitely do those things. Firebase is very dynamic so if you require changes to your database structure it is very easy to modify content and properties. There's a lot less to learn and code.
Use Firestore though. It's a fraction of the cost and its offers more when you will be faced with the need to do query for more than one property. It's still slightly limited in what you can do. Firebase is more suited when you need things in realtime quickly and also if the limit of firestore is going to affect your user experiences. https://firebase.google.com/docs/firestore/quotas. Its great for MVPing like @tranceyos2316 said.
Everyone is right about it having the potential to cost you a lot of money if you don't use querying properly, and if you nest your data structure heavily.
I would bet every fear you have about Firebase and what I recommend Firestore can be clearly avoided. follow this video https://www.youtube.com/watch?v=v_hR4K4auoQ.
If you get deep into it and have odd problems I can probably help you.
Using Firebase as your entire database will probably end up costing you not only more money but also more time. I'd just go with a Postgres. You can always use Firebase auth or something like Auth0 if you want to without giving up using a relational database.
Also, FWIW, I can't log into IH with my mobile browser (DDG), but I can log into every other site I use. Firebase is likely to blame. Not sure though, maybe @csallen knows more about this issue.
What I can tell is that user authentication on IH is being done via Firebase, but I'm not sure if this indicates that all storage and database is handled by Firebase too.
Use Firebase for your initial phase of your project. Firebase comes with its own limitations of user limits. Once you get good traction (say around 100,000 users) you should move on and implement the website with suitable infrastructure and code.
I think Firebase is a great tool to save time since we can communicate to the database directly and don't need to manage the server. In addition to that, Firebase comes with a lot of handy tools to help your application grow. But the biggest disadvantage which I can think of is the price. It will be expensive if your app communicates to Firebase a lot. However, if you have done monetizing your product well, by the point that you start considering lowering the running cost, you would have enough money to hire someone to migrate the functionalities of Firebase to other cheaper platforms. So all in all, It is worth considering using Firebase when you want to create an MVP of your idea.