Since I am not using the Google Cloud Platform App engine service anymore, I disabled it and got the following error on Firestore:
The workaround I could find is just to deploy a dummy app engine fully managed application. Still I think this should not be the right way of doing things.
Is there another way? Why did Google choose to link Firestore to App Engine?
firebaser here
Cloud Firestore is an evolution of Cloud Datastore, which in turn is the (originally unnamed) database in App Engine.
So it's not as much that Firebase chose to link Firestore to App Engine, as it is that we can't unlink it from App Engine without rewriting a lot of infrastructure. That may happen at some point, but at the moment you'll need to keep App Engine enabled to use Firestore.
By the way: this is also the reason that for a long time you could set a spending limit on Firestore, but not on other Firebase products: it inherited its spending limit from its App Engine lineage. When the ability to set a spending limit disappeared from App Engine, Firestore also lost that ability.
A lot of Google Cloud products are actually linked to App Engine deep down inside cloud projects. I'm not sure anyone is going to be able to give you a satisfactory explanation of why this is (unless it's coming from an engineer from Google). But I can tell you that it's a long-standing legacy of the way cloud projects work. App Engine is the original Google Cloud product, and much cloud infrastructure was built around it. That's all implementation details, and you don't need to know why that is - all you have to do is enable the App Engine API, even you don't use it directly.
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 see this question has already been asked but not all that recently so I am bringing it up again.
How do you hide your firebaseConfig file, or any secret key, in an expo application? (For production, not dev).
As far as I can tell, there is no way to properly hide the firebase config file with API keys etc in a react-native expo app.
Being that I have already built my entire app around interacting with firestore, I am a bit perplexed as to how to proceed forward.
If I eject, is there a way to properly hide my API key in a non-expo react-native-app? Or will I still face the same problem? Everything is working smoothly and I would prefer not to eject.
I have some experience using node.js/express.js as a backend (only ever in a development setting). Should I build myself a server and then serve the config info from there?
If I want to deploy a 'demo' app, is there a way to hide the keys while still using expo?
Any insight into this would be so helpful.
As far as I am aware there is no 'dotenv' package compatible with expo.
Also I have zero experience in deploying mobile apps, and very little in deploying web apps. I have not yet had to deal with securing keys in deployment.
Any help would be so appreciated.
It's not possible to effectively hide your Firebase config information. The best you can do is make it more difficult for someone to find them. Since all the JavaScript code is running on a computer or device that you don't control, you can't ensure that any of it is hidden from view.
In fact, you don't need to hide any of that. I suggest reading this: Is it safe to expose Firebase apiKey to the public?
If you're using Realtime Database, Firestore, or Cloud Storage, you should be using security rules to protect data so that only authorized users can access it.
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.
I'm trying to find a way to allow users to create and setup firebase project on their own google account from a client app, and get all their project information, urls and so on.
I took a look at the new project management api but can not figure out how to achieve this.
The management API currently does not support the creation of a new Google Cloud project. You are free to file a feature request for that, but it's worth pointing out that project creation is a complex issue and needs to be gated by abuse prevention measures.
You might also want to look into Google Cloud APIs for dealing with projects.
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.