Is it possible to base my entire website’s or app’s back-end with Firebase Cloud Functions?

Without a clear and distinct set of requirements, it’s impossible to say whether or not any given technology satisfies your needs. Like any technology, its advantages and limitations need to be understood before committing to an implementation that could sustain a product.

Yes definitely. Really depends what your app needs to do exactly though. It might not be a good idea for 100% of your app.

It is DEFINITELY possible but not sure about the pricing and the flexibility to call third parties API.

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

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.

I have done both for many, many years. The answers so far that say that back-end development is easier are constrained to problem sets that are focused on front-end solutions. If, in this day and age, you are dealing with SQL and a REST API written in a scripting language (like PHP, Python, Ruby, etc) and that is good enough for your commercially successful app, then I would say you are right; the back-end is easier. There are many successful apps like this.

That said, many applications (most of the most successful ones?) have many difficult problems and technologies that they deal with on the

I have done both for many, many years. The answers so far that say that back-end development is easier are constrained to problem sets that are focused on front-end solutions. If, in this day and age, you are dealing with SQL and a REST API written in a scripting language (like PHP, Python, Ruby, etc) and that is good enough for your commercially successful app, then I would say you are right; the back-end is easier. There are many successful apps like this.

That said, many applications (most of the most successful ones?) have many difficult problems and technologies that they deal with on the back end in order to handle millions of concurrent connections, processing terabytes of data, multi-node distributed processing, machine learning, etc. Think Facebook and the Ads network they have to manage and target to hundreds of millions of users, or Walmart who has to provide responsive, inventory shopping services to millions of users daily. These are not "just a little bit of SQL, some Ruby and tada!" kinds of apps and I promise you that more of their R&D goes into the back-end than the front-end, because the problems there are much, much more difficult to solve.

The interesting thing to consider is this:

Front end development has a lot of hairy technical challenges, but by-and-large *they are always the same problems for all applications*. In essence you have millions of smart developers working to solve the same problems you are solving every day. This is why the platform innovates so rapidly. Whereas, the challenges that confront back-end developers tend to be unique to the application and require far more science, development of algorithms, architectures and solutions, because, at scale every application has very different requirements for success. In our company, we have an intermediate layer written in Nodejs, hosting pages written in Angular, D3 and React. The UI is clean and responsive and I don't remember the last cross-browser issue we had. Our back-end is written in Scala over Akka. We use Storm to process the terabytes of data we receive from hundreds of sources, Redis to cache it for processing, Kafka to queue it up for storage, Cassandra for the data analysis and Zookeeper to manage the nearly 100 service nodes that are all cooperating and automatically scaling to serve peak load. Our UI is awesome, but the IP for the company is in the back-end, it is special and it is ours (and yes, I confess that I am proud of it). We have solved and continue to solve tremendously difficult data processing problems at scale and that, my friends, is far more difficult than any front-end development you will ever do. AND, I think that every application that operates on any large volume of data for any large number of users has to solve problems that are similar, but distinct from the ones we have solved.

In short, I think the front-end is a great place to work, is very hard to get right, and is very rewarding, but the most exacting requirements and the challenges that separate the men and women from the kids in software is on the back-end. That's my opinion, anyway.

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution see

There are several reasons not to avoid using Firebase and several reasons to avoid it altogether. Since you asked, the main reasons to avoid it are the following:

  • Outages: Firebase Realtime database seems to runs on a single zone and if it fails you cannot do anything but wait for it to recover and outages surely do happen.
  • Scaling: If your service grows a lot, you will start facing serious performance issues in reading and writing to the Realtime database.
  • Multiple environments: While Realtime has an emulator you can use for development, it comes with important limitations. The best solution seems to be to have a second project to use as a development/staging environment. Of course, if you want to have a few development environments plus a staging one before you roll out to production it starts to get messy. Being able to replicate your production environment using docker containers does make life and collaboration easier and you can’t do something like this with Firebase.

Nonetheless, I would not recommend just setting up your own backend and having to do software patches etc as some people imply is the alternative. The alternatives include using more scalable databases such as BigTable or ScyllaDB which can be used as a turnkey solution and then using things such as Cloud Functions, App Engine or Docker containers along with Kubernetes for your backend services. Just make sure that you encapsulate and abstract calls to your queues and databases so that you are not tied up in any one technology.

Of course, there are also very good reasons to use Firebase:

  • Authentication: Firebase takes care of your authentication allowing for different authentication methods that work on all devices. This makes life a lot easier.
  • On(change, add, delete etc.) Events: Realtime database is just amazing for frontend updates. You subscribe to data changes and the moment something changes in the database, your frontend updates instantly.
  • Cost: Especially in the beginning, it costs next to nothing to get started. As your app scales you start to feel the cost but in order to have a system that offers what Firebase offers you will be paying in any case so it is good to be able to start with very low fixed monthly costs and paying based on usage.
  • Speed of Development: Firebase allows you to launch your MVP in no time. It is not the best for large teams and complex projects but for MVPs it is just fantastic.

If you're building an app that requires multiple users to communicate with each other or access a shared pool of data, back-ends are pretty crucial. Since you were using Wampserver I'll assume you have a MySQL database, and you're running PHP. There's nothing conceptually wrong with the way your system is implemented right now, I wouldn't know the details, and you can scale fairly easily because pretty much every web host supports MySQL and PHP. So a simple option would be to buy some server space and host your database there.

However, you have a few other options, and yeah, Parse and Firebase

If you're building an app that requires multiple users to communicate with each other or access a shared pool of data, back-ends are pretty crucial. Since you were using Wampserver I'll assume you have a MySQL database, and you're running PHP. There's nothing conceptually wrong with the way your system is implemented right now, I wouldn't know the details, and you can scale fairly easily because pretty much every web host supports MySQL and PHP. So a simple option would be to buy some server space and host your database there.

However, you have a few other options, and yeah, Parse and Firebase are among the best. I'll also add another service I've extensively used called App42. All these services are called Backend-as-a-Service (BaaS). Their primary objective is to eliminate the need for you to host your own back-ends, and most of them provide value added features, that way, all you have to worry about is Android, you don't need to know how to build and scale databases, all you create is the server-side logic, and you can argue that it makes you more productive since you don't have to build from scratch.

One great thing about using a BaaS is that if you make an Android app that uses data from the BaaS, you can just as easily make an iOS app or a web app that uses that same data.

So where do you start? Well I believe you can build anything you want to on any of the three, for both mobile and web. Firebase is the fastest, but it doesn't really give you more than a place to store and retrieve your data in real time. App42 is the most robust and has the most value addition, meaning you can easily implement a ton of features without having to write the code yourself, but it's not as fast as Firebase, and relatively falls short when it comes to offline caching and a few other tiny things. Parse doesn't really have that many flaws either. They're all awesome and free to begin with.

All this is nit-picking really and you should check them out and decide for yourself what's best for you. Hope this helps.

EDIT: Ignore the others and just start with Firebase. It's really powerful and robust now.

I have personally used AWS, Google Cloud as well as Firebase for various projects. I am not associated with either of the companies. I am summarizing my experience with the services here:

  1. AWS has a whole lot of services (almost anything you can think of), they basically convert many open source solutions AS-IS to cloud along with adding billing. Most of the services (except few) are services where you would still have to think of capacity, traffic etc. Something that requires a decent sized infrastructure team. Billing is (usually) complicated, some services have various tiers, different ways y

I have personally used AWS, Google Cloud as well as Firebase for various projects. I am not associated with either of the companies. I am summarizing my experience with the services here:

  1. AWS has a whole lot of services (almost anything you can think of), they basically convert many open source solutions AS-IS to cloud along with adding billing. Most of the services (except few) are services where you would still have to think of capacity, traffic etc. Something that requires a decent sized infrastructure team. Billing is (usually) complicated, some services have various tiers, different ways you can buy instances etc. If not used properly can potentially incur a lot of cost.
  2. Google Cloud also has a lot of services (but fewer than AWS) but I find that they are more advanced technologically (Bigquery, Image/Text/Voice apis etc.). Many of google services are geared towards autoscaling, automatic traffic management and low IT costs. Billing is usually simpler and consequently google tends to be cheaper at scale as well, particularly if you are a small team putting together a fast product. (At-least it was cheaper for me)

Firebase although did not start @google, adheres to some of the principles google tries to have in its cloud products. It is a backend as a service, requires very little server side code if at all. It scales/load-balances without any intervention from you. Support is very good, they respond quickly. There is a lot of library support as well from the open source community. The best part(s) about firebase are 1.) It is built over websockets so you can actually build realtime applications with ease. More importantly you can actually give a real-time feel to even traditional applications. (think gmail vs yahoo mail in 2004) 2.) Billing is very easy and straightforward and in my opinion quite low cost esp. after google started backing it.

It is standalone you can combine it with any backend AWS or google if you need to. So the choice is not really AWS vs Firebase.

In fact you can combine the good features of each cloud and not really have to choose between aws vs something.

Well, I’d say the answer varies wildly for the exact use case you’re going for. So while most of the components that firebase offer to build apps are “planetary scale”, a lot of features are sorely lacking if you’re building an application on firebase features alone. Having built tens of projects, both as a hobby and as part of work I can give you a couple instances from my experience, but your mileage will vary depending on what you use firebase for.

  1. Hosting: firebase lends itself very easily to hosting thanks to the scale of Google’s infrastructure knowledge, built in CDN and SSL certificates

Well, I’d say the answer varies wildly for the exact use case you’re going for. So while most of the components that firebase offer to build apps are “planetary scale”, a lot of features are sorely lacking if you’re building an application on firebase features alone. Having built tens of projects, both as a hobby and as part of work I can give you a couple instances from my experience, but your mileage will vary depending on what you use firebase for.

  1. Hosting: firebase lends itself very easily to hosting thanks to the scale of Google’s infrastructure knowledge, built in CDN and SSL certificates and the new functions hosting that you can use for server side rendered node web apps.
  2. Fire store and real-time database: This is also massively scalable and you might find yourself using these databases even if you make the switch to other stacks just cause of the easy of use and the ability to have real-time listeners which is just such a breath of fresh air compared to MySQL or other databases. HOWEVER, this is also the part that I have the biggest issue with scalability. You just cannot do good queries with either of the databases. And this is a bigger problem than you realize and you will have to use an external system like Algolia, that has to index your database and something you have to pay extra for.
  3. Authentication: This just works out of the box and since they are effectively just wrappers around existing with providers like Facebook and google, they just work.
  4. Notifications: Having being built on Google’s Cloud Messaging system, this would also be infinitely scalable and should have no issues supporting a large app.
  5. Cloud functions: These work in a pinch when you need to run a couple functions in a server less environment, and to have an express app to host your website or to do certain tasks when data is written to or deleted from your database. HOWEVER, it has all the limitations of being a server less environment and doesn’t provide much control over its internal workings.

Having said all that, I am still an ardent firebase fan and I’ll continue using it for any projects I work on, whether at work or a personal project. And I am confident that over time, firebase will only get better with new features being added to it.

In my opinion it's Django..it depends..one's advantages are also it's disadvantage but how?

Advantages of firebase-

• Why firebase is created when pre established framework like Django is there..to reduce the complexity of framework..hence it's simpler to learn or more preferably it's a light weight.

• Real time data base management like you are indulged with app like for banking or other relies upon frequently change in users data then it is made for u.

• it facilitates​ you with the cloud messaging i.e you can send notification to users at a time with no cost.

• imparts authentication for Google,

In my opinion it's Django..it depends..one's advantages are also it's disadvantage but how?

Advantages of firebase-

• Why firebase is created when pre established framework like Django is there..to reduce the complexity of framework..hence it's simpler to learn or more preferably it's a light weight.

• Real time data base management like you are indulged with app like for banking or other relies upon frequently change in users data then it is made for u.

• it facilitates​ you with the cloud messaging i.e you can send notification to users at a time with no cost.

• imparts authentication for Google,Twitter & Facebook & other.

• crash reports solution i.e if your one of the app crashes in any mobile you will be informed.

• doesn't need to separately integrate admob.its built in available in it

Disadvantages of Firebase-

• every perks come up with some cost..so firebase is not suitable for large projects as you will have to code lots of line.

• Not free you need to pay 25$ in a month,moreover it's cumulative with users i.e more user more load on pocket.

• Therefore it's not good for long term with so many users.

• your user data is somewhere in servers which you don't own,therefore it becomes hard to fetch all data & you will need to contact them.

Let's come to the Django

Advantages of Django-

• Built with Python.which is easy to learn & faster,it is best structured webframe.

• it comes with its own ORM(object relationship mapping) i.e you connect your objects directly to relational database by writing code in Python.

• It has rich,pre established community..therefore you can instantly get answer of your queries.

•It provides you admin panel by which you can change,modify your database entries.

I suggest you to go with Django,it's kind of one time solution forever most suited for large application. At first it seems complex but once you will step into this things will be simpler for you.

But if u don't wanna get into complex framework & only want some real time small application with limited user.then you can switch to firebase.

Hope it helped u!

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 perf

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.

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

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.