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.
Related
I've looked around for answers to my question, but most are actively trying to do what I don't want which is why I'm asking.
An app I'm developing for the company I work for has gone live, and so to further develop I need to use Firebase preview channels.
I've looked over the documentation and it states that channels use the same resources, which I find a little unclear.
Does this mean that preview channels are UI only and using an app on a preview channel will still write to the live database (Firestore) that customers are currently using?
If you're talking about Firebase Hosting preview channels, the only difference between each channel is the web content (html, css, js, images) that you deploy to it. The configurations for the other Firebase products (database, analytics, etc) don't change at all. You can see this for yourself by printing the active Firebase configuration in JavaScript - you should see the all the same values.
If you want to build against a different database before you push updates to production, you should instead use completely different Firebase projects to keep them separate. It's common for developers to keep multiple projects for multiple environments, such as development, staging, and production. This is the formal recommendation.
Bottom line: A Firebase Hosting preview channel just lets you try out different web assets against the same backend services. If you want different working environments to avoid disturbing customers in production, you should use different projects entirely.
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.
For example, if I wanted to use the functions.auth.user().onUserCreate() trigger, is there any way to make it trigger different functions for different apps that are all in the same Firebase project? Is the only way to fix this to create separate Firebase projects for each app? The issue with that is that I need them to access the same database.
It's not possible to know in a Cloud Functions trigger which app a user used when they created their account. Firebase Auth accounts don't have a sense of "ownership" with respect to multiple apps per project. All apps in a project share the same users with the same permissions.
What you can do instead is have each app write something unique in your database after the account was created, then use that to determine what that user should do later on. Either that, or use different projects if your apps don't actually need to share the same set of users.
The only possibility that I think that might help you is organizing your Cloud Functions in different files, which will be then loaded per project. So, for example, in your Project Alpha, it will run the Cloud Functions from the foo.js file, while in the Project Beta, it will run the functions from the bar.js and the same logic for other projects and Cloud Functions.
This way, even though all users are sharing the same database, it will trigger the function based in the file that you requiring in your application. You can check for tips in organizing your Cloud Functions in multiple files and calling them individually, in this official documentation here:
Organize Functions
I believe this way might work for you, so, I would recommend you to check the documentation and give it a try splitting the functions in multiple files and calling each specific files, on their specific applications only.
Let me know if the information helped you!
I'm relatively new to Firestore and I am currently trying to build a Flutter app on it. I have hit a roadblock where I realize that I must utilized Firestore Cloud Functions in order to perform server-side data manipulation.
Unfortunately, there are not a lot of great resources and videos describing the process to set this up (at least for someone super new to software development like me). However, I was able to find this video https://www.youtube.com/watch?v=DYfP-UIKxH0 that goes over how to set up a Firestore app using Typscript. As such, I have two questions:
Will setting up the environment to write cloud functions be the same here for Firestore as it will be for Firebase?
Do I want to write these functions in Javascript or Typescript?
Yes. When you use Cloud Firestore, you're essentially using Firebase, and the setup for Cloud Functions is the same between them. If you run into problems, post a questions with the minimal steps needed to reproduce that problem.
That's your call, as recommending one technology over another is off-topic here on Stack Overflow. That said, most developers coming from a background with strictly typed languages may prefer typescript.
This is in relation to the question here: Google Cloud / Firebase Functions, handling dependencies per function
So, to manage dependencies better, is it allowed to divide the functions to as many projects as we see fit?
This would create one "master" project, that contains the data in database and storage + the projects that are otherwise empty, but contain only certain functions.
Thins of the following projects: My Awesome App, My Awesome App Stats Api, My Awesome App Admin Api etc.
It depends on what kinds of functions you're writing.
If you want to write database triggers, they have to be in the same project as the database that's receiving the writes. You can't have a second project respond to writes from the database in the first project.
If you want to write HTTP triggers, you can init the admin SDK to point to different projects for querying and such.
I don't particularly see any need to "shard" your functions like this in a production environment. Cloud Functions will scale your functions as needed to handle the load, and having different functions in different projects shouldn't make a difference in that respect.