Google Firebase Reviews

Our primary use case is with a chatbot and file usage. Let us say you wanted to pay for your utility bill and your data at the same time. We do this using a reward commodity known as cash tokens. This includes checking your wallet's balance and topping it up.

One of the challenges I was facing when I was using it was the library called Google Dialogflow which allows you to connect your chatbot with an intent. So there is so much adding when you are trying to connect it with your service because you have to do a lot of repetition writing a new intent, putting it step by step so it is good to escape. I believe it should be flexible and dedicate the intents based on the relating and to write a lesser code when doing that.

I have been using Google Firebase for the past two years.

When it comes to stability I had an issue during training with downtime, I do not know maybe because of more traffic on the chatbot.

The scalability is good.

There is plenty of documentation available. I think there is plenty of group support available and Google support as well. The website has plenty of information.

The price is perfect and very clearly defined. The price during the trial setup is free and then you move to a paid service.

I would rate Google Firebase a ten out of ten.

I started using it for web development, taking advantage of the SDK to speed up the development process. Since you do not need to create an API, you can connect to Firebase from JavaScript.

The product that we sell has a lot of important features, and one is the real-time chat that was only made possible by Firebase. Currently, we are working on a migration from another document database to Firestore, which is the second generation of Firebase.

Firestore makes possible more things than Firebase. It is a mix of Datastore and Firebase. We needed a database that provides high consistency and scalability, given the real-time feature. This helped our organization a lot because the process to develop everything was very fast, thanks to its SDK.

The Realtime Database feature is the most important for us since we are able to see changes in the database the moment they are happening. So, we built a real-time chat where users are able to talk with each other. Also, the push notifications on smartphones are another important feature that we discovered later, and it made a big impact on our portal.

The Firebase functions that act as triggers to let you know when there are changes in the database are very helpful.

Another important feature would be the SDK. You do not have to create an API since you are able to query the database directly from JavaScript or any other language.

I would like to have a facility for testing possible scenarios by writing dummy data and then doing different queries. This would help me to better develop applications.

I have been using Google Firebase for two years.

We have never had problems in the two years that we have been working on this database.

We currently have around 500,000 and the database works very well.

So far, we haven't need to contact customer service. The documentation is clear about how to implement it.

We were using CouchDB and we changed because we needed to use a managed service. The one available on GCP was Firebase.

The initial setup is simple since you only need to create an account on the Firebase website.

We implemented this completely using our internal team.

The monthly cost is based on writing data and queries to the database. The price, I would say, is cheap. You can use this database in the free tier even for production with small applications.

We did not evaluate other solutions.

Queries to the database were very simple. However, modeling is a challenge and I recommend running proof of concepts when you want to store something new in the database.

Overall, I have to say that this database is great.

Google Firebase is one I like a lot because it gives us a little bit more power and accessibility when it comes to publishing apps a lot quicker and for the needs that we have.

The documentation for Google Firebase is great. Also, what I like about it is the integration to Android, which is the reason I went with Firebase. Android is the biggest mobile platform out there currently, bigger than IOS, especially in South Africa.

The only thing that I won't do on Firebase is the hosting side of things for a progressive web app because it feels like you actually still need to download the app first before you can actually get into the functionality of the app.

So, it's not really a website, but it's web-based, and the app needs to be like a downloadable app. In that sense, I'm using normal Linux hosting and PHP for normal websites. I still have to split my software into a web app. If there's something that needs to be improved, it is that if you publish an app as web-based that you don't have to physically download the app or that the app doesn't download in the background. 

I would rather not publish as a progressive web app. Initially, on first opening up, the app seems very slow. After that it's quick, but it feels like the app needs to be downloaded first before you can actually get into the functionality of the app.

I've been using it for about six or seven months.

In the case of your first setup, if you're not sure what you want to do, it can become a bit of a problem. If you've done something wrong, it's very difficult to get rid of your project. There are some unique IDs that are left behind. So, the initial stages were a little bit difficult in that sense because if you make a mistake, you can't reuse what you have done.

However, once I got used to working with Firebase, it was nice and easy. Firebase is a Google product, but in the beginning, it didn't seem like one. Google is making a lot of changes, which makes us developers make other changes a lot as well.

The moment you go into volumes, then you work on a pay-per-volume basis.

I would recommend it if you're experimenting and starting off because of the way Google gives you a lot of free options when the project is still small. However, if you're thinking of a big project where there's going to be costs and a lot of traffic, then I would recommend that you decide on Firebase, Azure, or AWS from the beginning before you actually do something. For the experimental side, Firebase is fantastic.

If you're going to do mobile apps and need to publish to play store and have functionalities such as push notifications, analytics, AdMob, and monetization, then Firebase definitely is the way to go.

I would rate Google Firsebase at eight on a scale from one to ten.

We use Google Firebase for the database in the backend. We also use some of the Firebase functions for the website to interact with. We host two apps on it. One is an Ionic app that connects to the Google Play Store and the Apple Play store. The other one also has a Firebase backend, Firebase functions, and some schedule functions to make some payments.

What I like most about Google Firebase is that it's one of the easier options to host a website or app quickly. I think the backend integration is quite quick with the Firebase.

I think the migration into a data warehouse, or Google BigQuery, should be a bit more automated. There are still some manual hiccups, and it wasn't as user friendly as some of the other components.

I would like to see faster data migration and some support for other languages in the next release. Google Firebase has functions, but it'll help to do a .NET Core kind of function or a bit of additional support for other languages. Right now, I feel like it's very Google-centric.

I have been using Google Firebase for about 18 months.

Google Firebase is definitely a stable solution.

Google Firebase felt like it was scalable to a point with our solution. But when we went a bit further with our databases, we ran into some problems.

We had a concept where we were white labeling and had different speeds. As soon as we connected six different apps to the same backend, we started having problems. Then we had to split into duplicate databases, and that wasn't perfect.

I also found that we hadn't used the real-time database in the BI component, and we used the Firestore component. Originally, we had a real-time database, and we migrated to the Google Cloud Firestore database. I found that I could easily migrate that into Google BigQuery. But there's a couple of steps. First, you have to do the backup, and then you have to import these backups into Google BigQuery.

I did that about six months ago and was slightly annoyed that there were no streaming functions. Scheduling the import was very difficult with Firestore. We had to use a couple of other tools to create schedulers to import. But the import on the Google BigQuery and the Firestore component was still a manual process, which was a bit annoying.

Google Firebase is quick to set up and relatively easy to install. But it depends on the context, dependent on the growth of the application. For example, if you have a site that's already developed, doing the hosting and configurations, with authentication plugins and more, will probably take anywhere from a couple of days to a week.

Google Firebase was set up by myself and one of the other developers.

The pricing component is a bit confusing when it comes to what exactly you'll pay for, but I wouldn't say it's expensive. I just found it a bit confusing to understand what exactly it was saying. There aren't any extra payments for the license. 

We started with Firebase, but we recently considered moving over to Azure. But the benefits we would've received weren't worth the migration effort.

I would recommend Google Firebase for startups and people specifically focusing on apps.

Based on our use case, I would give Google Firebase an eight.

Firebase has multiple uses. My team uses it for the mobile app, while the audit team uses Firebase for the web app. We are also using Firebase to handle notifications into the mobile and web app.

I love Firebase's notifications, crash analytics, and bug tracking. It gives you detailed reporting about app usage and users.

Firebase's real-time information isn't technically real-time. It takes a while to upload user activity into the app. It's not as fast as Datadog, the other solution we use. 

I've been using Firebase for two years at my current company, but they were using it before I was hired. 

Firebase is stable.

I believe Firebase is scalable. 

Firebase was already set up when I started, but I know that the integration steps are explained well in detailed documentation.

I rate Google Firebase eight out of 10. Firebase is a good product. The free version is decent, so you can start with that and pay for more features as your needs grow. I think it's a fantastic product to start with.

We already use this technology in our company to build our Android and iOS mobile applications and to communicate with our back-end infrastructure.

Google Cloud Functions: Allows us to create functions without any infrastructure apart from the Google App Engine. These functions can have several kinds of triggers:

• Realtime Database Triggers
• Firebase Authentication Triggers
• Firebase Analytics Triggers
• Cloud Storage Triggers
• Cloud Pub/Sub Triggers
• HTTP Triggers

Google Cloud Auth: Allows our Android and iOS mobile applications and JavaScript codes to make authentication with almost no effort. The reason is because the Auth has already implemented it for us.

Google Cloud Real-time Database: Allows our Android and iOS mobile applications and JavaScript codes to record and retrieve data with persistence and minimum effort.

In my humble opinion, Google Cloud Functions (which is still a BETA version) needs to have more control over the uploaded functions. That is, it needs more options for controlling the functions itself. I might think about some characteristics that can improve a lot this:

- A START button to start the function. This button should be
incorporated in each one of the functions that the developer created and
deployed in Google Cloud Functions;
- A STOP button to stop the function. This button should be incorporated
in each one of the functions that the developer created and
deployed in Google Cloud Functions;
- A RESTART button following the save behavior as above buttons with
RESTART capability.
- A better and improved log view. The actual LOG view has a Slow
performance to show the log items and also it doesn't allow fast searching
for past log items. For example, whenever we need to look for a block of
log items that happened in the past, it's very difficult to access that
block of code.
- Capability to save the log to an external tool.

I did not find any stability issues yet.

Our actual phase in development (MVP), doesn't allow me to give my opinion on this point.

Currently, it has not been necessary to contact technical support, due to the vast and informative documentation with Google Standard.

We tried to use the AWS cloud. They have a very good solution, although the documentation is a little verbose, in my humble opinion.

The setup is very easy and straightforward. You just need to follow the documentation from the Google App Engine.

They have a free tier that will cover most projects. For more intensive use, you pay as you use it, but the price is very cheap.

We evaluated Amazon AWS, but due to the reasons explained above, especially the flowery documentation, we decided to go through Google App Engine and Google Firebase. We have no regrets at all.

I would say that they should go ahead with Google App Engine and Google Firebase.

We use the solution for user management.

The solution is useful for managing users and user authentication.

We had some compatibility issues with Elixir. It had some library compatibility issues. We did a workaround through Google Cloud Functions and achieved the desired output.

I have been using the solution for the last four years.

I rate the tool’s stability a ten out of ten.

I rate the tool’s scalability a ten out of ten. In the past, we had 70,000 users. The usage was reduced later.

The initial setup is simple. The solution is cloud-based.

I rate the pricing a five out of ten.

Overall, I rate the tool a ten out of ten.

This solution supports our real time database. We also use it for AB testing and for its Google Cloud functions. We make use of Crashlytics and reporting on details.

The best features are the cloud functions.

We have experienced many challenges with the realtime database. Every time we need to retrieve chat history that has multiple observers, it will execute multiple times. The UI for the realtime database could be simplified.

I have used this solution for three years. 

This is a stable solution but requires some improvement. 

The technical support for this solution is good.

You can use this solution for lightweight use but I would not recommend being dependant on it. When you want to scale, you will need to have your own server, services and infrastructure.

I would rate this solution a six out of ten.