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.
Related
I am building a desktop application and added support for the Firebase realtime database. Because I am running a desktop application users will run different versions of my app.
As my app evolves, new features will be added and may require an update to the database schema as well. But I can't do this as I need to keep all client versions compatible.
For example, I have projects saved in the database at project/${uid}/${projectName}. Imagine in the future projects are not anymore tied to a user because I implement "collaboration" and want to change this path. How would I do this to keep all my clients up running?
You could store that path in realtime database and fetching the URL on client as required. I'm not sure what you mean by implement "collaboration" but if you want all the users to be on same version of your application then you would have to store the latest version in DB and verify the version yourself on client.
projects are not anymore tied to a user
In my opinion, if you could store a list of user UIDs who are a part of that project then that would be easier instead of structuring your app as projects/${uid}/projectname. If it is something like /projects/${projectId} then storing that list of authorized users would be much more easier.
There's Remote Config.
Firebase Remote Config is a cloud service that lets you change the behavior and appearance of your app without requiring users to download an app update.
You may have to use the REST API if your are building apps for desktop. Also as #Doug mentioned in comments, it may not synchronize all clients at same time.
I am creating a firebase project. It contains two React webapps: a client facing app and a backoffice app.
I either:
create two apps in Firebase with separate configurations, and two hosting sites
or keep a single app in Firebase and use its config in both React apps, and two hosting sites
In my understanding, the apps can access the same resources either way.
What should I do?
More precisely: what is the benefit of separating Web apps in Firebase ?
If you don't intend to configure the Firebase products within each app differently, then there is not much practical difference. You would need to visit specific use cases, then ask if separate apps help or hurt that case. The use cases where separate apps would be more helpful are likely to revolve around Analytics rather than development. Analytics and its related products use the concept of an application to generate meaningful data about that app, and also create and target audiences within those specific apps.
What is the benefit of separating Web apps in Firebase?
In your case, i.e. "a client facing app and a back-office app", you probably have different user roles:
Clients who use the client facing app (maybe with different sub-roles, e.g. authors and editors or team leader and team members, depending on the business scope of your app)
Admins or Super-users, or "back-office clerks", etc... who use the back-office app.
The classical way to handle this role-based access control strategy with Firebase is to use Custom Claims.
In addition to implementing a way to grant (or not) access rights based on roles, Custom Claims also allow you to adapt your app UI depending on the user's role or access level.
This is interesting but if your app is complex and have several screens (or menus) that have different behaviors depending on the user role it can rapidly become a nightmare to hide/show parts of the UI depending on a variable. In this case it may be better to have two separate apps (in two separate Firebase projects) that point to the same (master) Firebase project.
Having two separate apps is also very interesting if different developers/development teams works on the
two apps.
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.
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.
I'm attempting to build a simple app and would like to take advantage of Azure Mobile Services for authentication and storage of user info and settings...
however I also have some application data that I need to store, which I figure I should also put into the mobile services tables.
However, there doesn't appear to be any administrative interface for managing the data in Azure Mobile Services, such as CRUD to fill the tables and manage the read-only data that the users would be accessing.
So my options are either to put this data in a separate website/database, create a separate website and use azure mobile services within to manage the data as an admin, or just put everything into my own asp.net website and use web api (or something similar) to serve the data to the apps.
obviously the last option offers the most flexibility, but my ideal option is to be able to simply manage the data as an admin with another website.
the data i need to manage is not something the users will be editing or adding to through the app, but rather data that I need to have already in the app for the users to access...
what do you think is my best option based on these requirements?
You have a few different options for pure data management. First I'd say though that whatever option you choose, I would recommend keeping the data in the same database or make it otherwise accessible to your Mobile Service. If you're comfortable with doing it in SQL, you can connect to the database your Mobile Service is using with SQL Management Studio (this is the windows utility for SQL DB administration) or there is the SQL Portal which is a Silverlight tool which offers a lot of the functionality of SQL Management Studio. Moving on from pre-built tools, you can build your own app / website which interacts with the database directly (or through Mobile Services as an Admin). This would be the most work but offers you the ability to customize anything you might need. Lastly, you can just use a REST Client to handle dealing with any admin data. Since everything is exposed in Mobile Services via a REST API, you can use a REST Client (like Postman) to directly post data to your Mobile Service (using the Master Key to come across as an admin if needed). This is arguably the easiest way to do it without a SQL tool though it's more drudge work since you need to enter the JSON text for any data you want to send up.