Firebase vs own back-end for MVP?

I think the best rule of thumb for an MVP is to use what you're fastest with. If you're not familiar with Firebase, then you're going to incur some overhead to get up to speed, even if the overall platform is more feature rich than your DIY options.

Mincing words about the tech stack and being overly concerned with specialized services early in the process tends to fall in line with being premature optimization. Use what you know, and get your MVP into the hands of your [potential] customers ASAP.

Side note, I've never actually used Firebase, so take this as you will :)

Hey Marcin,

I'm using Firebase in my side projects and wouldn't change it for anything right now.
It saves you a ton of time, you get live data updates out of the box. And it's free.

As for security - yes it can be a bit tricky, but there is a lot of knowledge out there and it's easy to figure stuff out as you go.

If you design the app with migration in mind, it won't be a big problem for the future as well. I'm wrapping up firebase stuff in dataservices, so in case I need to switch in the future the change won't impact too much. But I never got to that decision, so not sure of real impact 🙃

Like @joshtronic, I'd recommend going with whatever you are most comfortable and proficient with.

If its Firebase with Firestore & NodeJS then great. You seem to be taking the right steps to mitigate that migration in the future with your dataservices.

Firebase & Firestore can do a lot for you and the point at which you will "outgrow" Firebase, you can worry about that in the lead up to that point. Right now, the worry is getting that MVP out the door and getting traction.

Remember you can have a hybrid architecture where you may incrementally migrate your stack. For example you could migrate database off Firestore to something else but still host your functions, authentication, storage, etc on Firebase. Then migrate your storage, and so on..

The way I look at it is these are nice problems to have if you get to that stage. Concentrate on getting to that stage. Otherwise its simply premature optimisation.

Firebase has a lot going for it. I've built a few MVPs with it, and it does an enormous amount for you out of the box. A couple gotchas to watch out for:

• If you're using their SDKs, your bundle sizes are going to be huge. They are working on it, but right now there's no real solution. I end up loading the SDKs from their CDN, separately from my main Webpack bundle, speeds up build times a lot

• There are articles out there about using Firebase Functions to build a "serverless API" - this might work in some situations, but cold starts are a very real problem. If you're using Firestore inside of a cloud function, they can be extreme (30s+).

All that being said - I absolutely love Firebase, and the benefits clearly outweigh the drawbacks for me. You can get complicated MVPs up and running lightning fast.

We're using Firebase for https://coronavirus.app. I would definitely recommend it. Really quick to get an app up and running and scales pretty much indefinitely (we have peaks at 40,000 users/hour).

If you're using Firestore, you'll just have to optimize your data structure to minimize the number of reads and writes, or else it'll get pretty expensive pretty quickly.

We're not using their client SDK though. Instead we built APIs that call Firestore via Cloud Functions using the Admin SDK. That gives us a bit more flexibility regarding security rules, and less room for error.

What will you front-end it in?

I am a huge fan of Firebase/Firestore in general and agree with you about auth and analytics.

Cloud functions are phenomenal. Firestore, at least for me, won me over. That doesn't even address the ridiculously low effort to set up hosting with SSL and other things that are just stupid easy.

I have a network of IoT devices where the python backends write to various firestore collections and/or documents with cloud functions just tidying up everything in the background to keep the feed of any one device's data up-to-date in near real-time.

If you're an Angular guy, the @angular/fire package is phenomenal too.

Yes, you have security rules to think through, but I'd still contend that's less work than rolling your own up-front, let alone the future maintenance.

Personally, I'd have a hard time not hearing about a new project and immediately begin thinking about how to implement in Firebase/Firestore.

All the best.

Just determine a decent value for your own time (lets say $100/hr), and determine whether the cost is worth the time investment. If not go with Firebase. If it is, roll your own.

The moment the costs significantly overruns the value of the time it would take to rewrite that component, migrating data is one of your smaller problems.

As an added bonus to all the other good points made for using Firebase for MVPs is that Firebase has a Zapier integration...which unlocks a ton of cool possibilities esp valuable in the prototyping stage.

Firebase is great to start with. If you do not plan very complex queries or full-text searches, then I usually recommend just starting with that. If you, however, want to go down the GraphQL route, then check out https://hasura.io/. I recently moved a firebase app to its own backend with it, and it was very straightforward. So I would not be afraid to start with firebase and move if you need it (likely, you won't even need to move ever).

Interesting timing on this question. I am a huge fan of the serverless model and tools like Next.js, etc. but also am finding that Firebase is not a good fit for all the projects I want to do, and have been frustrated at the lack of good options for working with a plain old RDBMS + serverless.

I am building a solution for myself that lets me add database connections and queries with input parameters, and then allows me to just call them with REST APIs. This way I don't have to build out a whole dedicated API from scratch each time. Would you consider a solution like this as an option? I can talk with you a bit more if so.

Be careful. It really depends on the type of App you are building. I have had both very good and very bad experiences with firebase before. If you know how to use it and have a relatively simple app (e.G. no complex query necessities) go for it. But if you don’t or are already familiar with running your own backend I would prefer that route.

Some background: I decided for Firebase last year (using the whole suite of Cloud Functions, Firestore, Hosting, Storage and even some Google Cloud Funcionalities)[https://www.indiehackers.com/@jaschaio/building-launching-an-advanced-email-marketing-app-in-just-4-weeks-95459a5ea7] and went just through migrating everything over to my own backend because of constant hassles. It can become very expensive very soon and debugging is really hard as well. If you have lots of data even migrating could become an issue and very expensive as well. I was basically saved by running ElasticSearch alongside it and could just export the data easily from there.

If you don't have anything that's backend processing intensive, definitely go with Firebase. Cost can go out of hand very quickly if you have unexpected usage or a simple bug. I've been through this with a web video editing tool I was working on that ran ffmpeg in Cloud Functions.

However if you're simply writing and reading serialisable data and your queries are simple and don't read and write too many documents on each user action you're better off going with Firestore.

I used AWS, Azure for production level apps but nothing is even remotely as simpler as Firebase. I can literally go from idea to app (including, setting a domain, SSL/HTTPS, hosting, authentication, default email like [email protected] etc, some simple cloud function) in couple of hours. This is not the case with AWS, AWS is a mess just to setup a simple domain with SSL, HTTPS and worst to setup a lambda function with HTTPS endpoint, Gateway Shit, Certification... oh god..#%$#$%

There is seriously huge market to simplify this AWS process.

Firebase negatives:

• Expensive for large applications.
• I don't like the idea of calling firebase database calls directly from UI, its not only cumbersome security rules but also very tightly coupled UI with firebase.
  I have a slightly different approach with Firebase. For most of the critical functionality I will implement API using firebase functions, the general expressjs etc... That way I don't need to waste time with database rules and also my UI is having clear separation.
  If I want ever want to move out of firebase its just moving the function code.

I developed www.dearele.com (not functional anymore) on a weekend. I give major credit to Firebase, if it was AWS I will still be messing with HTTPS certificate, etc after 48 hours.

I love the speed of building with firebase, they provide so much functionality for free. When building an mvp I think the best thing is to not try and force your app structure into something that it wasn't designed for. If you need to build something that is relational like a newsfeed don't build it with a nonrelational database like firestore. Also don't be afraid to use multiple platforms/databases if it will make it easier to develop and improve user experience!

I am having the exact same dilemma. I am using Amplify instead of Firebase and I am quite happy so far with the pace at which I am developing my prototype but I know I will hit a wall at some point when I 'll need to implement complex business logic, in my case time-series reporting with spatial relationships.
What about using Firebase for all the simple parts and group the complex queries/business logic into separate dedicated services/API. You could get the benefit of both world.

I went with Firebase and so far I'm pretty happy with. I need constant writes to a dB and fast reads, but very simple queries. So far it worked pretty well.

My app isn't released yet, so we will need to see how it scales.

As @szferi pointed out, I would go for Firebase if your queries are super simple. I faced the same dilemma you have right now a few months ago and I decided to go for Firebase for building www.chooseyourplant.com. I did wrong. I structured the data just to make it right for firebase which I think it's absolutely wrong and then, I changed and I do everything in JSON.

What kind of data do you have to store? There are other alternatives.