I am planning to use Firebase for the backend of a mobile app project, and I was wondering : am I obligated to build an app to be able to use Firebase (e.g for tests) ? Or is there a way to use Firebase during my programmation phase ?
Firebase offers about a dozen of services. Including databases and test tools.
You can use any subset of those services
You can use Firebase any way you want using the provided APIs and SDKs. This might or might not involve a mobile app. As long as you stay within the limits of the free tier, or are willing to pay for the services you consume on the Blaze payment plan, nobody will care if you have an app or not.
Related
I am about to start making a game for iOS/Android which involves connection to Firebase backend.
Since the game contains a bit controversy theme, I'm scared of DDoS kind of attacks.
To make protection, I know Google provides Firebase App Check service and they say it's available for iOS/Android/Flutter/Web according to their webpage.
https://firebase.google.com/docs/app-check
My question is, is the service available for Unity, Godot, or other game engines?
Since App Check SDK is available for Flutter, does this mean we need SDK for Unity, Godot etc. if we use those engines?
Or can we just use Firebase iOS/Android SDK together with any game engine?
I checked whether they provide SDK (with App Check) for any game engine and only found that Firebase Unity SDK seems to be trying to implement App Check feature (but not done yet).
https://github.com/firebase/firebase-unity-sdk/issues/511
It would appear Firebase is available in the Play Core Native SDK, so it would be possible to use GDNative to access the API.
I have a Flutter white labeled project, i want to use only the Firebase Auth on login module of all differents apps i'll generate, can i make it with only one Firebase Project and work with the UID response on the backend after the login completes? What's the best practice?
firebaser here
The recommended practice is to use a project only for single family of apps, with a single set of users. So an example of this would be to have the iOS, Android, and web versions of your app, and maybe an administrative back-end you have for that same app, and then maybe pro versions for all platforms too.
White labeling the same app for many customers should be done with a separate project for each of those customers. Otherwise you'll quickly run into limitations, such as the number of API keys you can create in a single project.
I've been using Firebase for a long time and it's great, however I need more power for certain things.
At the moment, I have a function in Cloud Functions for Firebase to do some video processing and I need more power. I have heard Google's App Engine is better for this kind of solution and I've been experimenting with App Engine with my Google Cloud project.
I went to deploy my first Node.JS app function to App Engine and it seemed as if it was going to overwrite my existing functions I have. I have lots of functions, and code in Firebase for my app and my website to talk to one another, so I'd like to keep and leave my Firebase stuff alone.
I'm just wondering, how I'd use App Engine (and maybe some other higher end Google Cloud products) alongside Firebase without interfering or changing one another, but using the same project?
App Engine is an entirely different product than Cloud Functions. Anything you deploy to App Engine will not affect what you've already deployed to Cloud Functions, and the same applies in reverse. You can use both products in tandem with no conflicts.
Here, you can find more details related to the serverless environments options that you have. It would be helpful to read about each of them and choose whatever fits your needs better.
Does firebase limit the amount of firebase apps that a google account can have? I'm making an app for 2 different customers and have decided to use firebase for the db functionality.
I'm slightly concerned about the above if I were to grow my business. In the event that I manage to increase my client base, , I would hate to have multiple logins to access each client project.
When it comes to billing. Can I set up my firebase to charge my account and not be project specific? An alternative to this would be if I was to create a singular project and then have multiple different apps connect to the database. However I don't think this would be possible as there would be no way for me to know who my clients customers would be. Is there anything I'm missing when it comes to this?
There is a fixed limit to how many apps you can have in a single Firebase project. Last I checked it was around 30 or so, but that may have changed.
The important thing to realize is that Firebase projects are meant to cover variants on a single "logical" app, all with a single user-base that all access the same resources.
So if you have an iOS, Android, Unity, Flutter, and Web version of the same app, you'll want to have those in the same project so that they share the same resources. If you have a specific variant of the app for admins, you'll also want to add that to the same project; again, so that it's accessing the same backend resources.
But if you have two different apps with two different user-bases, you should create a separate project for each app.
Google just released Firebase 2.0.
It seems they are completely separate platforms.
Firebase: https://www.firebase.com/
Firebase 2.0: https://firebase.google.com/
APIs are also different.
Firebase: https://www.firebase.com/docs/web/api/
Firebase 2.0: https://firebase.google.com/docs/reference/js/#firebase
Could someone explain the differences in the core concepts on both mobile and web?
I've been building an app using old Firebase.
Should I change my codes to use Firebase 2.0?
The new version of Firebase is the same platform - it just adds a whole range of new features, so the big change to the core concepts is an expansion of what you can do.
The Realtime Database offers the same functionality as before, but with a refreshed API and a new console. You can keep using the same approach and data model as before, and the API changes are largely cosmetic (renaming to be consistent with the newer features).
Authentication is pretty similar, but it has been expanded to include new features like account linking and customizable emails. You should be able to upgrade your application to the new SDKs and console pretty easily: take a look at our migration guides for Android, iOS and the web.
You can import your project at any time. Your applications and the existing SDKs will continue to work. You can then update your code when you are ready to use some of the new Firebase features in your application.
The new concepts are really around the new features:
Analytics is a new mobile-first analytics product that gives free and unlimited event reporting, and allows building audiences which can be used in many other services.
Storage allows you to store and serve user-generated content, such as photos or videos.
Remote Config allows you to change the behavior and appearance of your app without publishing an app update.
Cloud Messaging is a cross-platform messaging solution that lets you reliably deliver messages and notifications at no cost. Notifications gives you a tool in the Firebase Console to send re-engagement messages easily.
Crash Reporting lets you collect crash data from your Android and iOS apps, to find and fix problems more quickly.
Dynamic Links are smart URLs that dynamically change behavior to provide the best experience across different platforms. They allow you to use deep links that survive app installs on Android and iOS.
Several existing Google products have been integrated into Firebase as well
Invites replaced AppInvites, giving easy way to sending personalized email and SMS invitations. App Indexing gets your app into Google search.
Firebase now also integrates with AdWords to let you target ad campaigns with Analytics audiences, and AdMob to automatically track in-app ad effectiveness.
Its a lot of new features, but you don't have to try them all at once! Once you upgrade, its straightforward to pick and choose.