Is Firebase a good choice to build a chat app?

Yes it’s an excellent choice.

  1. Performance: Excellent
  2. Learning curve: Minimal
  3. Cost: not bad (as long as you structure data and build your app right)

When you think about hosting cost though, consider how it might be offset. Were you to build your app with a more labor-demanding technology with cheaper hosting, you might need to keep some expensive developers on the payroll. With Firebase, a small team (or one person) can keep things under control. Hosting alone is a small part of the cost of owning a production website.

You need to ask yourself two serious questions before investing too much in Fire

Yes it’s an excellent choice.

  1. Performance: Excellent
  2. Learning curve: Minimal
  3. Cost: not bad (as long as you structure data and build your app right)

When you think about hosting cost though, consider how it might be offset. Were you to build your app with a more labor-demanding technology with cheaper hosting, you might need to keep some expensive developers on the payroll. With Firebase, a small team (or one person) can keep things under control. Hosting alone is a small part of the cost of owning a production website.

You need to ask yourself two serious questions before investing too much in Firebase though:

  1. Do I need to perform complex queries?
  2. Will I be heavily reliant on back-end code?

Firebase queries are pretty much like this: “Hey Firebase, give me the data at this node” and you get back raw data. You can maybe sort or limit, but probably not in any complicated way natively.

Firebase does not (yet anyway) provide a direct path to modifying the back end code. You can certainly write your own back end, especially if you use Node.js, and there are several ways to architect your app with it. To launch a chat app though, you don’t really need to worry about that.

You say it’s “in order to launch a startup” and you say you already know how to build a chat app using Firebase. In a sense there’s your answer right there. In general if you have an idea you want to implement and a clear path to move on it, take the path available to you. Even if you knew how to build it with other tech, I still might suggest Firebase due to the easy learning curve and the advantages of a real time database.

You’re open to learning new things. That’s great! You’d be a fool to be closed to new skills. When (if) your app scales to a point where the limitations of Firebase come into play it should be pretty easy/smooth to migrate away. Firebase is so light-weight and flexible that you could literally re-build your app full stack with other technology and then just plug it into your old Firebase as a quick-fix, then take your sweet time building out a new database and query structure.

There’s a pretty good chance you’ll never do that though. If your app really is limited to chatting, you’d be hard-pressed to run into a wall with Firebase. Some of the smaller limitations can be overcome by building a node.js “reactor” type server that just listens to Firebase for changes in data, then reacts in some way. You could also supplement Firebase with an API in that same or a different supplemental server.

Yes and no.

Yes, in that it’s easy to build a chat app on Firebase, and it’s a really good showcase for the capabilities of real-time messaging and notifications. There’s a reason it’s one of the apps in the codelabs. Making a chat app teaches you how to reason about the real-time database.

No in that a naively-designed chat app with large numbers of users won’t scale well. (Indeed, no naively-designed app with large number of users will scale well, but chat apps are particularly vulnerable to this.)

One of the codelabs for Firebase shows you how to build a chat app (Android, iOS, web). So you could say we’re pretty confident that Firebase meets the needs of apps that need a realtime communications like this!

Firebase is great for startups because it allows you to move quickly with development and scale up as you grow. Your startup would have to get really big before Firebase no longer meets its needs, which is a great problem to have.

Hello Soham, according to me yes it is a very good choice for building a chat app, because if you are aware of the way firebase returns data to an app using its “.on” method so it is quiet impressive for chat applications.

For the reference you may visit this link : Chattr
You can get the complete source code as well for Chatter App here :
kidGodzilla/Chattr

And further more if you wanna know how much more useful the firebase is you may also visit demo apps build using firebase which are these : Ready To Use Demo Apps

I will be happy to help further with your queries if you will have any. Good L

Hello Soham, according to me yes it is a very good choice for building a chat app, because if you are aware of the way firebase returns data to an app using its “.on” method so it is quiet impressive for chat applications.

For the reference you may visit this link : Chattr
You can get the complete source code as well for Chatter App here :
kidGodzilla/Chattr

And further more if you wanna know how much more useful the firebase is you may also visit demo apps build using firebase which are these : Ready To Use Demo Apps

I will be happy to help further with your queries if you will have any. Good Luck :)

Firebase is a cloud-based application development framework developed by Google to create high performing mobile apps.

Some Detailed About Firebase

  • Developer : Google
  • Hosting by Google, free up to 100 real-time connections
  • No custom code
  • Easy and quick set-up
  • Recommended for time applications
  • In-built database
  • JSON storage data
  • Backup data upload option to Amazon S3 bucket or Google cloud storage

Read More Choosing the right platform for real-time chat application development - XMPP vs Firebase

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.

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.

Absolutely not .Build chat app is very easy in nowadays. Here I’ll share my thoughts

Creating a real-time chat feature for an app is a challenge every developer might face sooner or later. Clients’ requirements keep growing along with market leaders’ strive to innovate. And usually, as soon as a software house develops one or two chats, they start claiming significant expertise in the field. Looking at the complexity of the subject, becoming an expert takes a bit more than that.

You may think a chat app is a basic thing. All the popular services like WhatsApp or Facebook Messenger give the impre

Absolutely not .Build chat app is very easy in nowadays. Here I’ll share my thoughts

Creating a real-time chat feature for an app is a challenge every developer might face sooner or later. Clients’ requirements keep growing along with market leaders’ strive to innovate. And usually, as soon as a software house develops one or two chats, they start claiming significant expertise in the field. Looking at the complexity of the subject, becoming an expert takes a bit more than that.

You may think a chat app is a basic thing. All the popular services like WhatsApp or Facebook Messenger give the impression that it’s all easy and straightforward. When you start looking under the hood, you realize there is much more to it than what you see on your screen.

Functionalities a chat app should have

To create a messaging app that will outshine the competition, you can think of additional features that are more sophisticated and interesting. Audio and video chats used to be perceived as extraordinary, but now they are standard in chat apps. So which novelty could become your unique selling point

Take It to the Next Level you Chat App with Extra Features

Now that you’ve got the basic guideline on how to build a chat app, you can raise the bar with extra features that can make your messaging application really stand out.

The most crucial pillar of the entire app development process - Security!

  • Pin certificates for trust authorizing the user and the device.
  • Infrastructure deployment using a private network.
  • End-to-End encryption is a must.
  • Comply with GDPR requirements.
  • Throttling and Rate Limiting in the network to avoid triggering errors.
  • TLS/SSL protocols are vital for implementing a connection between client and server.
  • Every user should have a unique registered phone number. The same number should also help in two-factor authentication SMS.
  • Allocate a File Object storage for chats in which only active chat participants can access media. Authorization and authentication are pivotal.
  • Rule out saving sensitive user data. If the need arises, it should be encoded or hashed with special algorithms.
  • Use the SHA-512 hashing algorithm where the message is broken into 1024-bit chunks and further processed.

Bottom Line

To compete in the market, you should constantly improve your app’s functionality. We’ve gathered a list of advanced features that will make your chat app a robust competitor to giants like WhatsApp and WeChat.

If you are looking third party Chat API or SDK providers for your Chat app . Explore Here[1]

Footnotes

The quick answer, YES, Firebase is the best and safest option for the majority of cases users will need it. Is FireChat the best chat API to use for chat? Maybe but I wouldn’t recommend any of those APIs.

I work for a bespoke app development company which specialises in instant chat, we use Firebase for many of our projects. Below I will put some of the advantages and disadvantages of FireChat, then I will add some additional points of the best implementation I see when using chat.

NOTE: Other services will include many of the same advantages and disadvantages, this answer will be trying to show

The quick answer, YES, Firebase is the best and safest option for the majority of cases users will need it. Is FireChat the best chat API to use for chat? Maybe but I wouldn’t recommend any of those APIs.

I work for a bespoke app development company which specialises in instant chat, we use Firebase for many of our projects. Below I will put some of the advantages and disadvantages of FireChat, then I will add some additional points of the best implementation I see when using chat.

NOTE: Other services will include many of the same advantages and disadvantages, this answer will be trying to show that Firebase is better overall based on its strengths. I disagree that the other services you have mentioned are useless. In my experience they have all been excellent (great developers, documentation etc) but Firebase is exceptional.

Advantages of FireChat

  • Cost: As you mention in your question Firebase is great for starting developers. You can get a good level of users on your app before needing to start paying for the service. This level has been set well to mean that once you start paying you have enough users to be monetising your app.
  • Support: Firebase offer great support and also have a huge community to offer support for them. Due to the size and scale of their company Firebase is widely used. This means if you have problems there is a good chance others have found and solved it already, if not then there are lots of people willing to help on Stackoverflow and other forums.
  • Documentation: Firebase has a huge and excellently written documentation base. Their documentation is also extremely complete spreading across almost every feature or function you might want to implement.
  • Security: Security is on both lists. Security is easy to set up and understand on your Firebase database. The fact they give you the freedom to set and modify is a real strength. This enables you to customise your functionality very well to your specific app.
  • Speed: Firebase is super quick which is a very important feature for a real time chat.
  • Quality: The Firebase code is extremely well written and excellently tested. In the 4 years I have been working with Firebase I have yet to find a bug with their provided code.

Disadvantages of FireChat:

  • Searching: Firebase is very bad for apps which require an accurate search. Basic search is possible but is not particularly sensitive or quick. If you need to search for characters stored in your database then you either need to write some tricky/slow code or need to use another framework for search (RIP Parse which had excellent search queries)
  • Push notifications: Firebase does have push notifications but these require a custom server. This is a shame as an in house feature would be incredibly convenient.
  • Data storage: Firebase is not the best database for storing large data files. It deals with text great but if you need to be uploading large images/videos regularly then there are probably better services you could use.
  • Security: Firebase is secure but not bullet proof. If your data is highly sensitive then it is worth having a service which specialises in data security.

From the points above you should be able to see that Firebase is a great product with its main disadvantages being in very specific areas. These might affect you depending on your project but can often be fixed with other frameworks.

I would argue that using an API for chat is itself very limiting. In this sense using FireChat is just as bad as using any of those other listed APIs. Below I have listed some of the main disadvantages I see of using any chat API:

Advantages of using Firebase for chat but not FireChat:

  • Flexibility: Firebase is extremely flexible, dumping the API will increase Firebase’s flexibility. Your imagination is the limit of ways in which it can be used.
  • Control: When using an API you are limited by their functions and structure. You are also limited when adding new features. Using FireChat reduces the control you have over the code as the structure is completely fixed.
  • Customisation: Similar to the points above, when using an API you give up a large amount of control in exchange for additional ease of use. In this case I don’t think it is worth it due to the way the Firebase code is currently written. Coding your chat using Firebase, but not through the API, will allow you to add new features and more easily modify current ones.

As you can see Firebase excels when it is being used for the majority of projects. Where it falls down is when a specific project has some very specific requirements which don’t quiet fit the Firebase model. This is why I would recommend it to 95% of developers - the other 5% will need to research what will be best for them.

The problem is not with SendBird, Layer or Sinch but the inherent problem with Chat APIs themselves. Although FireChat falls into all these pitfalls, Firebase provides code to enable you to code it yourself.

Our company has recently released an open source chat component, using Firebase, on Github. These are fully complete and compatible iOS and Android chats which we have released on an MIT license. This means you can release and modify the code with no obligation to us. Both of these project use Firebase for message and data storage but use Backendless for push notifications. I would recommend these over the other chat APIs as it gives you the source code to modify instead of being reliant on a companies frameworks.

What else could we use?

One final disadvantage of Firebase (and all the frameworks you mentioned) is the fact that you are using someone else’s service meaning you are reliant on them. Obviously this is a problem with every chat solution as it requires you to use their API for your project. The solution to this could be XMPP which is what many professional chats have switched to using. The advantage is that you build your service and configure it directly to the service you offer. Our company also specialises in XMPP solutions, you can check them out further here.

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.

Firebase is a great tool and you should use it.

Pros:

  • No need of writing php or JavaScript or any sort of backend structure as in a server based system.
  • Provides offline support and you do not have to take care of caching and persistence storage.
  • Fast data transfer.
  • Simple API and amazing SDK.
  • Great community support.
  • No need to take care of the security and encryption etc.
  • Insights about the app performance and user retention.
  • And a lot more…

Basically you don't have to worry about the backend, just concentrate on your app and its features. Leave the backend to the experts.

Cons:

  • Shifting from SQL to NoS

Firebase is a great tool and you should use it.

Pros:

  • No need of writing php or JavaScript or any sort of backend structure as in a server based system.
  • Provides offline support and you do not have to take care of caching and persistence storage.
  • Fast data transfer.
  • Simple API and amazing SDK.
  • Great community support.
  • No need to take care of the security and encryption etc.
  • Insights about the app performance and user retention.
  • And a lot more…

Basically you don't have to worry about the backend, just concentrate on your app and its features. Leave the backend to the experts.

Cons:

  • Shifting from SQL to NoSQL takes time.
  • Not many examples exist to show how to efficiently structure the NoSQL data.
  • Business logics have to be included in the app's code. Whereas in servers based system they can be included in the backend and changed whenever required. If a change is required here, the app itself must be updated and everyone must update their app as well.
  • Extreme care must be taken when updating the app. Since Firebase can convert objects (business objects) to json format in order to store it in the real-time database and vice-versa there can be conflicts with the naming in the newer version of the objects to the version already existing on the real-time database.

I have used Firebase on 2 of my apps. One of which is on the Google play store and performed perfectly.

I was able to build it within 2 weeks and it wouldn't have been possible without Firebase and saved me a lot of time.

Interrupt 7.0 - Apps on Google Play