Is firebase a good option to build a social networking web app?

To quickly answer your question, Yes, Firebase is a good option to build a social networking app with. There are a lot of reasons for this (real-time database, documentation, support, code quality etc) but I am going to be focusing on the points you have specifically raised:

  • Is it safe? Yes.

Firstly safe is a very relative term. Ever wonder why you often see businesspeople using Blackberry phones? This is due to it being extremely secure. Blackberry was the go to for banking and sensitive information. Other phones were safe enough but weren’t the gold standard.

This is a similar situation with Fi

To quickly answer your question, Yes, Firebase is a good option to build a social networking app with. There are a lot of reasons for this (real-time database, documentation, support, code quality etc) but I am going to be focusing on the points you have specifically raised:

  • Is it safe? Yes.

Firstly safe is a very relative term. Ever wonder why you often see businesspeople using Blackberry phones? This is due to it being extremely secure. Blackberry was the go to for banking and sensitive information. Other phones were safe enough but weren’t the gold standard.

This is a similar situation with Firebase. Firebase has complex security rules which allow you to tailor your security specifically to your app. Your understanding will determine how complex the rules are and how secure your information will be. Would I use Firebase to store my credit card details? Probably not. But they are certainly good enough for most of the expected information shared in a social network.

  • Security Rules

Firebase gives you control of your database and control of the security of your data. Checkout their security rule documentation if you haven’t already.

Firebase’s security rules allow you to choose who can read and write information to the database. If a user doesn’t have the right to view or edit data then they can’t. Changing the java script does not affect these security rules which are set in your dashboard. For example:

  1. "rules": {
  2. ".read": true, // Anyone can read
  3. ".read": "auth != null", // Only an authenticated user can read data
  4. ".write": "auth != null", // Only an authenticated user can write

These are the most basic security rules. You can then set more complex rules based on specific areas of your data:

  1. "messages": {
  2. // Only thread members can read and write messages
  3. ".read": "root.child($root+'/threads/'+$thread_id+'/users/'+auth.uid).exists()",
  4. ".write": "root.child($root+'/threads/'+$thread_id+'/users/'+auth.uid).exists()"
  5. }

The above means that only users who are inside a chat can read and write messages to it. As you can see security rules are built on top of each other to increase the security your database has.

  • Is Firebase progressive?

Yes. You can develop an app on web and then create compatible Android and iOS apps to work along with it. There is a huge amount of documentation on this, all recreated for every platform.

  • Low budget/time/staff

Firebase has a free tier meaning you can set up and go. Compared to building your own custom server you will save huge amounts of time building, testing and modifying.

Building an application is not a quick process. If the project takes a long time then it will not be from using Firebase, rather because of the ambitiousness of the project.

Conclusion:

Firebase is safe, free to start using and excellently documented and written. If you are unsure about any particular areas then post a question to their support team or on Stackoverflow. Here is an interesting one on where your data is stored and how secure it is.

If you want any help with setting up your project data structure you should checkout our companies open source chat components on Github. The data structure would be extremely similar and we have security rules which are included meaning you can ensure your information is safe. They are also compatible on iOS and Android meaning you could see how the structure fits together if you develop native apps.

Note: You can access the security rules terminal in your dashboard by using the below menus:

Firebase Hosting simply provides a way to publish static content for everyone to access as a typical web site distributed to a CDN. You get a free SSL certificate with that, so all access to it will have standard security that you find all over the internet.

You should always assume that anyone could change the JavaScript running in a browser, no matter where it came from. There are very common development tools built into your browser that let anyone change the code in your web site and run any JavaScript on it. This is essentially true for all code running in client apps - it can all be compr

Firebase Hosting simply provides a way to publish static content for everyone to access as a typical web site distributed to a CDN. You get a free SSL certificate with that, so all access to it will have standard security that you find all over the internet.

You should always assume that anyone could change the JavaScript running in a browser, no matter where it came from. There are very common development tools built into your browser that let anyone change the code in your web site and run any JavaScript on it. This is essentially true for all code running in client apps - it can all be compromised with enough knowledge and effort. If you want business logic to be secure, you should run it on a backend service that you control, not on the client.

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 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. Next question?

Firebase

Just kidding. Seriously, though, I can tell you from 5 years of using Firebase at both GetHuman and Swish, it is awesome. However, I should stress that Firebase (i.e. the realtime database from Google’s Firebase Cloud offering) should NOT be used for any and all situations. It is not built to be a system of record. Rather, it is built to enable pushing data to clients in realtime.

At Swish, we use MongoDB for our system of record, but then we replicate a small subset of our data to Firebase so that clients can listen for that data and then take appropriate actions whe

Yes. Next question?

Firebase

Just kidding. Seriously, though, I can tell you from 5 years of using Firebase at both GetHuman and Swish, it is awesome. However, I should stress that Firebase (i.e. the realtime database from Google’s Firebase Cloud offering) should NOT be used for any and all situations. It is not built to be a system of record. Rather, it is built to enable pushing data to clients in realtime.

At Swish, we use MongoDB for our system of record, but then we replicate a small subset of our data to Firebase so that clients can listen for that data and then take appropriate actions when it is updated. It is possible to use Firebase for other use cases, but this is its sweet spot in my opinion.

Firestore

A more recent offering from Google, however, is the Cloud Firestore database. This is an attempt from Google to get the best of both worlds by keeping many of the realtime features of the traditional Firebase database combined with more robust and secure features of a normal system of record database like MongoDB.

We just started to play around with Firestore at Swish and it is pretty awesome.

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.

Firebase is a NoSQL cloud database. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Since you particularly asked for Firebase Database, I would be focusing on that only from many features of the Firebase.

Key Features of Firebase Database

  • Real-time

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data

Firebase is a NoSQL cloud database. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

The Firebase Realtime Database is a cloud-hosted database. Data is stored as JSON and synchronized in realtime to every connected client.

Since you particularly asked for Firebase Database, I would be focusing on that only from many features of the Firebase.

Key Features of Firebase Database

  • Real-time

Instead of typical HTTP requests, the Firebase Realtime Database uses data synchronization—every time data changes, any connected device receives that update within milliseconds. Provide collaborative and immersive experiences without thinking about networking code.

  • Offline

Firebase apps remain responsive even when offline because the Firebase Realtime Database SDK persists your data to disk. Once connectivity is reestablished, the client device receives any changes it missed, synchronizing it with the current server state.

  • Accessible from Client Devices

The Firebase Realtime Database can be accessed directly from a mobile device or web browser; there’s no need for an application server. Security and data validation are available through the Firebase Realtime Database Security Rules, expression-based rules that are executed when data is read or written.

  • Scale across multiple databases

With Firebase Realtime Database on the Blaze pricing plan, you can support your app's data needs at scale by splitting your data across multiple database instances in the same Firebase project. Streamline authentication with Firebase Authentication on your project and authenticate users across your database instances. Control access to the data in each database with custom Firebase Realtime Database Rules for each database instance.

Real World Usage

I've personally used Firebase in number of applications and it is very fluid in its working. It is highly efficient if you want a real-time database that is synced across every client.

Other useful features of Firebase includes -

  1. Cloud Messaging (FCM)
  2. Authentication
  3. Cloud Firestore
  4. Storage
  5. Hosting
  6. Cloud Functions
  7. Crashalytics
  8. Performance Monitoring
  9. Test Lab
  10. Crash Reporting
  11. Predictions
  12. Remote Config
  13. Dynamic Links
  14. App Indexing
  15. AdWords
  16. AdMob

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.

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 wi

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.

That depends on what large number of users means for you. I would argue that up to a million active user you should have no problem in terms of latency. The only problem I see for larger apps is that firebase doesn't offer too many pricing tears, the only have the free tier for getting started on with a fixed monthly payment and the pay as you go, which depending on your needs in terms of storage could get pricy.

I have used firebase extensively in the past for several projects. Never as a full backend solution though. I am huge fan of their realtime database which I used for messaging and real

That depends on what large number of users means for you. I would argue that up to a million active user you should have no problem in terms of latency. The only problem I see for larger apps is that firebase doesn't offer too many pricing tears, the only have the free tier for getting started on with a fixed monthly payment and the pay as you go, which depending on your needs in terms of storage could get pricy.

I have used firebase extensively in the past for several projects. Never as a full backend solution though. I am huge fan of their realtime database which I used for messaging and realtime location sharing in different apps. The results and reliability has been fenomenal aside from the ease of implementation of course.

Yes you could build an app similar to Snapchat on Firebase. In theory, you can build any app of any kind using Firebase. The limit is really up to how well you design your data structure.

That being said, is it the best backend solution for building an app similar to Snapchat? Probably not. However, that requires additional work, resources and time. If you are looking for an easy solution with quick to market timelines, then Firebase is your safest bet.

Short story, yes!

You want to create your MVP and I think Firebase is the perfect option for that, It gives you A LOT out of the box so you can focus on building your app.

One cool thing I like about its native mobile SDKs is that they offer offline support, if your users loose connection the app will remain responsive the entire time and sync the data once connection is back :-)