Do Facebook or Instagram use Firebase?

No, they dont.

And if you are talking about the realtime database they never will.

I love firebase, when i just started programming a few months ago, it helped me get started to make real apps.

The app got viral and now i pay 3$ daily.

You will think that 3$ is nothing, but i am a 14 years old and that is 21$ weekly.

I am trying to set up a backend bit it takes time, and like every 14 years old, i have to go to school and i dont have time.

But facebook with more than a thousand engineers has time and knowledge to make a real backend for their own servers in their own data centers.

In the process of exchanging the auth code, Instagram will also return the user identity (this sometimes requires an additional request with other OAuth 2.0 providers like LinkedIn). ... your user is signed into Firebase with profile data from their Instagram account. One of the main problems with it, is limited querying capabilities. Realtime database provides no way to filter capabilities, because the whole DB is a huge JSON file, which makes it pretty difficult to make complex queries. Another point to consider also relates to Firebase Realtime DB and its data modeling.

Yes but you will burn way too much money. Why?

Firebase is a general purpose very easy to use Api and so are the features. Very easy to use but not too rich of functionality. (you cannot get complex queries with Firebase e.g.)

You will easily build a Instagram Clone. However, at a certain point it’s simply too expensive and you’re better off developing your own stack to serve your needs efficiently.

Conclusion: Build an MVP with Firebase if you have no idea about backends. If your app gets traction you can easily transition to your own stack. (Most of the times you won’t get traction so there’s n

Yes but you will burn way too much money. Why?

Firebase is a general purpose very easy to use Api and so are the features. Very easy to use but not too rich of functionality. (you cannot get complex queries with Firebase e.g.)

You will easily build a Instagram Clone. However, at a certain point it’s simply too expensive and you’re better off developing your own stack to serve your needs efficiently.

Conclusion: Build an MVP with Firebase if you have no idea about backends. If your app gets traction you can easily transition to your own stack. (Most of the times you won’t get traction so there’s no need to waste time implementing your own stack)

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.

Yes it can be done but it’s stupid! Read on and learn why. It all comes down to the complexity of operations we’re going to run on our data. In the case of Instagram what we usually want to achieve is loading the news feed. This is a problem with Firebase, let’s see why. A newsfeed is (in a naive way) a list of posts of people I’m following. In a relational database I would simply select all rows from table post, join them with the follow table and sort by timestamp (very very naive, we’re omitting “relevance” but this is ok for simplicity). That’s basically it. If you want to scale this out y

Yes it can be done but it’s stupid! Read on and learn why. It all comes down to the complexity of operations we’re going to run on our data. In the case of Instagram what we usually want to achieve is loading the news feed. This is a problem with Firebase, let’s see why. A newsfeed is (in a naive way) a list of posts of people I’m following. In a relational database I would simply select all rows from table post, join them with the follow table and sort by timestamp (very very naive, we’re omitting “relevance” but this is ok for simplicity). That’s basically it. If you want to scale this out you’d probably want to introduce sharding before your database explodes but this is another topic. Let’s get back to Firebase, which is a massive scalable json store. In order to understand the problem you should have a look at the pricing table: Firebase Pricing 100K concurrent connections for the Realtime Database is ok at the beginning, the problem lies in storage costs and pay per data transferred. If we translate this into a graph it would look like this: The more data you store and the more data you transfer the more it costs you. If data stored and data transferred were to increase linearly this would be ok, but this doesn’t make sense for a platform like Instagram. Once Instagram kicks off what you’ll see is people with millions of followers, generating content with millions of likes etc.. Why is this important? The business model of Instagram is based on network effects. You’d always want to achieve exponential growth which, and this is the critical part, would directly translate into exponential costs when using Firebase. This is because with Firebase Realtime Database you cannot simply “join” a newsfeed together. You will have to heavily denormalize your data and re-join it at the application level. If you want to achieve near realtime news feed functionality you’d have to accumulate all posts that should be shown in a user’s newsfeed, put them into a json array and store it. This increases data stored exponentially! Now think of adding “likes” to the posts. You could either update all denormalized posts which will increase data transferred exponentially or you can store likes centralized and make one request per visible post. The latter would increase data transferred even more and leads to a poor user experience. To sum up: Firebase Realtime Database is an excellent tool to reliably store json data. When it comes to heavily relational data like “social network data” you’re going to pay a lot of money to achieve the same results and you’ll have to implement a lot of logic into your application layer to correctly accumulate the data required in the frontend which is prone to errors. It could have been done but it would have never scaled.

Hello Friend,

You can’t track conversation of any person on facebook (for personal accounts), but there is another option where we can track and respond to the any person’s messages.

  1. In facebook messenger there is an option for creating Chat Bot, with particular account and you can track those conversations which will be happening with that account over chat bot.
  2. Yes, whenever we will be using facebook SDK for development purpose we will definitely need the login form a user to track and perform activities on their account data, because whenever a user login into facebook provide an access token

Hello Friend,

You can’t track conversation of any person on facebook (for personal accounts), but there is another option where we can track and respond to the any person’s messages.

  1. In facebook messenger there is an option for creating Chat Bot, with particular account and you can track those conversations which will be happening with that account over chat bot.
  2. Yes, whenever we will be using facebook SDK for development purpose we will definitely need the login form a user to track and perform activities on their account data, because whenever a user login into facebook provide an access token which helps to get user basic details and data from facebook.

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 da

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.

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 co

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.