When freelancing for web development, is it ok to use a firebase?

If the client agreed to use it, it's all about client satisfaction, you can make suggestions to your clients and provide reasons for your suggestions, after that, if the client agrees with you, you can pursuit your way, or go with his way :).

But if you love using Firebase that much, you can create hourlies to provide services using Firebase, like in Save on your freelance projects with PeoplePerHour! or Hire Freelancers & Find Freelance Jobs Online - Truelancer .

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the data in your Firestore database, not Google, so ignore the other answers about that also. If Google, and not the customer, owned that data, Firebase would have virtually no users. And, also contrary to the other answers, you can export data from Firestore. If customers weren’t allowed to export their data, who would ever use it?

Fourth, the suggestion to use SQL technology on your own physical servers (ones that you physically own) is not something that I think belongs in an answer to this question. SQL vs NoSQL and cloud vs in-house are decisions that you should have already made if you’re asking about a specific serverless provider. Clearly (at least apparently), you’ve decided on serverless NoSQL, which is definitely the most popular choice today. And between the two most popular providers, AWS and Firebase, they are designed to handle virtually any workload you throw at it. The most highly-trafficked applications in the world run on NoSQL serverless, like the Amazon marketplace, for example (AWS, obviously). If AWS can handle it, Firebase can handle it too. Google would never design its NoSQL serverless to max out at a certain number of users or level of traffic; it’s designed to scale virtually infinitely.

The only caveat to Firestore (and NoSQL serverless in general, really) is dollar cost—right now in 2019, anyway. Firestore was considerably more expensive only a year ago than it is today, think about that. I think NoSQL serverless will undoubtedly continue to become cheaper, including Firestore. But, right now, with a relatively large userbase, NoSQL serverless, like Firestore, can get expensive. But so can doing it all in-house. An in-house solution still comes with bandwidth cost, in addition to hardware and human cost. Hiring qualified backend engineers to build and maintain an in-house setup is not cheap (hundreds of thousands of dollars a year). Firestore (and DynamoDB) have excellent price calculators to help you predict your costs and you may be surprised to see how cheap it is with a modestly-sized userbase, even with 100k users.

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many apps will be dealing only in text strings meaning the data amount is very small. Images would be a step up from this and videos another jump in data usage. You need to think about how often your app stores this data. It might be that you only upload a single image for each user or it could be that you send multiple images while using. In both these cases the data usage will vary hugely.

Before worrying about how you will cope with 1M users think about how the app will fare with 1–10k users. In Firebase’s case you will probably be on the free tier (as long as you are not guzzling data) up to 100k users.

Think about this for a moment. You will have 100k users on your app. Even if you only add advertising you should be able to make the $25 a month to cover the Firebase FLAME costs.

The motto I use with my clients is this:

By the time you need to start worrying about backend costs for your app you can stop worrying about backend costs for your app

Once you reach the amount of users to requiring you to start payment you will have a successful app with a big user base which can be leveraged to start paying you back.

Should I use Firebase?

This is the final question you should ask yourself. Up until now this question could have been about one of the many different backends on offer.

If you are unsure I would be inclined to say: YES use Firebase!!

They are a great company and offer a fantastic product. Being owned by Google and having recently updated all their code they are unlikely to close down (RIP Parse). They also provide extensive and clear documentation and great support. There is a huge online community meaning sites like this and Stackoverflow have a huge number of questions to help you.

It is worth looking at your app though. Firebase does have some disadvantages:

  1. There is no easy way of querying data
  2. There is no way of executing code on the server

This is what should be researched when looking at whether Firebase is the right backend for you and even these can be mainly mitigated by using a separate server to control these tasks.

Conclusion: Unless your app is very data intensive then you won’t meet any of the data caps. Firebase will help you get your app online quickly and cheaply before scaling excellently once the users start pushing the upper limits.

NOTE: I would never recommend someone building their own backend when starting a new app. It might be that you have the skills to do it but in the long run it will cost you more (in your valuable time) than using another provider. Once your app is a great success and you are paying monthly fees to a backend then you can invest the money in creating a custom backend which suits your data type. Creating it yourself also requires a huge amount of invested time. If your app fails then this time is completely wasted.

Please don’t listen to the “proprietary blabla”. This is bs.

Imho MBaaS is the biggest failure ever made. No one ever will make money (long term) out of it. Their biggest failure, as you see in this post is, they don’t understand people like you. They think you will be a paying customer at some time. (This is never going to happen)

Now, let’s solve your problem. You’ve got that great idea and want to get going quickly. You seem like passionate about it. You want to focus on front end, not backend, means you focus and know your weaknesses. Very good point to start at!

So, why is Firebase your perfect solution? It’s supported by google. It’s super super easy to use. It’s well documented. Any more questions?

You can build whatever app (prototype) with Firebase in no time. It might not scale, but this is not what’s it about. You just want to master front-end stuff, don’t you? Right.

Eventually your MVP might get traction. What are you going to do? Well, if it’s going to get “a lot” of traction, you can pay someone to build a scalable backend for you. If not, scalability will never be an issue. You just don’t have to care about it!

Build whatever you like. Focus on the things you love to do. Firebase let’s you do exactly this. Keep it going, cheers.

Firebase is, essentially, a key-value store that you can use to quickly prototype and run a simple application, either native mobile or in-browser javascript.

They include all the authentication stuff and website hosting, so it takes away a lot of the pain of getting started and allows you to get something up and running really quickly. I haven’t played with it very much, but from what I’ve seen and heard it is a fantastic product!

What Firebase will not do for you, however, is any business logic on your stored data. You would have to incorporate that into the front-end application, which for complex stuff is simply not a viable option.

If you’re making something cool that just needs a fast, reliable database, user authentication and usage tracking, then Firebase is a great way to go. If you’re building something that has complex back-end business rules then you’re going to run into difficulties.

You can totally combine it with a custom application of course, store your data in Firebase and have a middleware layer that does the business logic, but for most business cases this isn’t really a good compromise.

In short NO

Firebase is a good option but if you want to create a CMS and use it real-world application then consider these below points before starting.

1.Ease of use

Yes, firebase is easy to use no doubt in that. But when using it in a real application than you will face many complications. For Example:

Limited option is available for Firebase. Like if you want to add a search query in the firebase then hard luck doing that as there is no direct way of don't that.

2. Cost
Firebase is lucrative when starting out with its free tier but as your users grow your bill will grow exponentially.

3. You will get stuck

It is impossible to switch your firebase backend if need be. Like if you are on a SQL database you can easily switch to any other variant and service providers when you need it. But with firebase, you will get stuck with it.

So in my opinion, if you are making a data-driven app like blogs or tutorials or anything like that then look somewhere else. But if database is a secondary functionality of your software like a photo editor or similar app then you can use firebase.

I’ve used Firebase in production with a small MVP and for lots of smaller side projects. Here is a quick and dirty list of the good/bad:

Good

  1. Easy to get started with great API docs and rock solid SDKs
  2. 3-way data binding if you use AngularFire
  3. Addition of Google Cloud services (file storage, notifications, analytics) makes those things easier as well.
  4. Very fast client-side (if you can avoid downloading excess data)
  5. Dead simple auth module that makes me less nervous about a hack b/c Google
  6. Support for a server side SDK allows you to still use the data to render pages on the server
  7. I don’t have to worry about managing a DB, DB server, or backups!

Bad

  1. There is a serious lack of query power with the SDK. If you are doing any kind of data analytics, stick with SQL
  2. Lack of control over user emails/passwords (this could also be a good thing as well)
  3. In some ways, harder to structure modular code. A lot of the Firebase stuff ends up becoming spaghetti code wrapped in a method. It works, but it is not as elegant as it could be with a REST Api.

Overall, I’ve had good experiences with Firebase and would use it again to bootstrap a product. I’ll update this post when my current project grows so large that I have to migrate off of Firebase, and then we’ll see how easy that is : )

It’s a great solution for authentication, including multi-factor. The real-time database combined with a React or similar app is a great user experience. The functions and other services, now with ML, make it a very rich toolset.

Be sure you know how to model data and follow their recommendations in the docs (using object instead of arrays). Use the bulk update whenever possible and if over a hundred writes per second, chunk the updates.

Be sure to watch the video on the security rules and validation features. If you study and leverage these it will minimize code you have to write for input validation and authorization.

Use the push syntax to generate unique, sequential IDs.


Dont force using NoSQL however. Some use cases are best served with ACID compliant DBs (I.e. banking, accounting, users).

As of today there are two plans: Spark (free) and Blaze (pay-as-you-go). The Spark plan is pretty generous, but once you go beyond the free quota limit you need to manage your Firebase costs.

When you consider your app size, think about:

  • Size of data and egress (are you storing large video files you’ll be streaming)
  • Website hits + database reads/writes
  • Long processing tasks - Cloud Functions

vs your growth in revenue. If you are paying $1,000 a month for Firebase, but brining in $50,000 a month, that might be ok. If you are paying $100 a month and have no revenue…maybe an issue. In other words, if you have a large app with growing revenue, it might be ok.

Now for managing and controlling your Firebase costs, I would point out this article on Understanding Firebase Costs and my company, fireRun.io, that actually helps you see and manage your Firebase costs.

When you want to be vendor independent. And if you plan your app to last more then 5 years. If your app will be used to store some data for years and some business will rely on you than you should not use firebase, why? Look what happebed to Parse, google have a long list of closed projects and nobody can say for how long firebase will last. You shold consider what is better: invest now in independent solution, or invest later to move all the apps related to your new backend and backend itself to another platform. If your solution is “made fast, fast forgotten”, or safety of the data not really a big matter for your users then firebase is very good solution.

Firebase Pricing

Firebase has both 1 free and 2 subscription options:

Firebase provides the best back-end server, great database and analytics solution, and useful integrations with other Google products. Most of all, users like that it’s free to use and has affordable subscription options. A wisely designed CMS solution guarantees project scalability and data security. In the development process, up to 40% of efforts are made on building a flexible CMS structure and Admin panel. So, if the features of Firebase Free plan are enough to achieve your final goal, then you may save up to 40% of your budget and also time.