This is intentionally a very broad question. Sorry about that.
I'm experimenting with firebase for the first time. I would like to build a little e-commerce webapp using firebase, React and Next. I would like to split the App in two different apps: one admin app (used to create products and do other admin stuff) and the actual shop app. The Apps should be hosted on two different domains but they should talk to the same cloud firestore.
What would be a good setup to implement this architecture? Currently I am thinking about creating separate firebase projects for the admin and the shop app so I can host them on different domains. The cloud firestore would live in the admin project together with all admin related cloud functions etc. The shop app (or client app) would have its own project for hosting and would be connected to the firestore from the admin project.
Does that sound like a reasonable architecture or am I completely on the wrong path. Any suggestions are appreciated. And again sorry for the broadness of the question.
You don't need to do anything special. Each app (mobile, web,whatever) connects to a firebase instance/project. You can just set them all up to use the same firebase project (.plist file etc) and it will all work. The advantage of this design is that both admin and client access the same data, which presumably you need. (If you haven't found it, on the Firebase Console -> Settings -> Project Settings; add applications which will generate the appropriate credential files for each device type.)
Since you will have a shared/common authentication space, you may find that you want to add a flag/limitation to login so that only specified users can access the admin side. There's a few ways this can be accomplished.
Related
The educational organization that I'm working for have for some years been using a custom built Firebase site as a Learning Management System: custom email/password authentication, access of pedagogical recources with custom built frontend exercise modules/learning games, user administration etc.
Now, this organization is to an increasing extent using Google Workspace for user administration, resource sharing etc. However, Workspace itself can't be used as a replacement for the Firebase site due to the limits in design possibilites, lack of customization of pedagogical content etc.
So, does Google Workspace provide api's that would make it possible to use it as a "backend" for a Firebase frontend?
The most basic and inportant thing is authentication/authorizaion: Users should get access to the Firebase site and its resources via their Workspace account group and membership(s) in Workspace group(s).
When it comes to content, it would be great to - apart from the custom Firebase documents/pedagogical modules - also be able to present documents/resources from associated Workspace groups.
All in all: as much as possible of user auth, user adminstration, document resources should be kept on the Workspace side, with Firebase used as a facade communicating with workspace via api's, and also providing the customization possibilites when it comes to special content not possible in the Workspace context.
How much of this can be done with the combination of Firebase and Google Workspace today?
Preferrably using api calls, not by first copying/syncing database information back and forth?
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.
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.
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.
I am building a marketplace Meteor app but I am confused about the app architecture. I want to build front end user interface for marketplace, Customer dashboard, Vendor dashboard, admin user interface and meteor mobile apps for customers and vendors. I know Meteor bundle everything in client folder and send it to the client. My question is do I need to use same hosted Mongodb database and create separate Meteor apps for
App 1 Marketplace user interface and Customer dashboard.
APP 2 Vendor dashboard.
APP 3 Admin user interface
App 4 Meteor Mobile App for Customers
APP 5 Meteor Mobile App for Vendors
OR
Create a single Meteor App for everyone. but in that case app size will increase.
OR
Create separate Meteor apps and connect all other apps to APP 1 (Marketplace App) through DDP to share publications and methods.
Please help me decide best architecture.
Option 1:
I've done so using a single MongoDb instance. I currently have four apps connected to it. It works really well.
Make sure you use the oplog for instant updates across all the apps.
Some of the security benefits of this approach were unexpectedly nice. For example, allow and deny rules being created with only one type of user in mind for each app. If someone has access to admin.yoursite.com for example, the permissions allow all sort of things for admins, but for the client facing app, the permissions can be locked down to only allow editing of the few things that are required.
You can get pretty far with this approach, I recommend it.
Option 2:
I wouldn't recommend making a large app that does everything.
Option 3:
Not to say there is no benefit to that sort of approach, but "APP1" in this case should probably be some sort of event log, which each app can subscribe to the events of and write events to, and update their own databases. This is the most complex (and expensive) solution, and I wouldn't recommend it until you are trying to scale really large. If you are interested in this type of approach I recommend looking into Event Sourcing/CQRS.