React (Typescript & Redux & Webpack)
I'm developing a micro front-end application using react (typescript & redux & webpack)
But I'm seeing blockers in sharing the data between container app & child apps,
Above the planned structure, there roles based authorization
Teacher (Access to Teacher - Student Management App & Student - Academic Assessment && Teacher Registration App
Parents (Acccess to Parent Registration App && Student - Academic - Assessment
Student (Student Registration App && Student-Academic Assessment App)
Now, I'm seeing a blocker in sharing the redux-store data across child applications, i.e. when users log in from the login app, how to share the logged user information to child apps so that role-based access is implemented effectively, data is also to be shared. Store should not be shared across apps.
Honestly, you are making things more complicated for yourself that it needs to be. To make some of that data available to each other, you will end up with multiple copies of the same data in different stores that has to be kept in sync.
Just share that store instead of coming up with a complicated scheme of making some application state available to some others and not others.
If you suddenly start accessing another sub-app's data, chances are you actually need that access. And then you will have to enable data sharing there again - which you could have from the beginning.
Another solution for this would be to add some code rules. A "human" solution, not a "technical" if you want to phrase it like that:
one central store
an app can only dispatch actions from it's own app
one app's reducers can listen for actions from other apps (this is how app A could lead to a state change in app B if you need it)
you only use selectors, no inline-written selectors
keep all selectors in a central (but scoped) location for all apps to access, but add a linter rule to "forbid" import of certain scoped selectors to other apps. You can easily disable those rules for certain combinations to allow read-only cross-app access.
Related
I want to make an app where parents can buy a subscription for their children (one subscription per child) but I wonder how the corresponding accounts in Firebase would look like (buying the subscriptions themselves is out of scope of this question).
Are there best practises I should follow here?
I'll have a parent account in Firebase I guess
how can I create the children's accounts and how do I communicate their (generated?) credentials to them?
Thanks in advance for your insights!
Firebase Authentication maintains a flat list of accounts per project. There is no built-in relations between any of the accounts, unless they are linked (which is not what you want here).
The best I can think of for the structure is to add a custom claim to the child accounts identifying their parent (and vice versa if needed). This needs to be done from a trusted environment (such as your development machine, a server you control, or Cloud Functions/Cloud Run). A local (Node.js, or other supported language) script or this extension that sets claims based on a Firestore document are probably the easiest way to get started with this.
If you choose to create the kid's accounts in a trusted environment with an Admin SDK too, you might as well add the custom claim there.
Seeking some thoughts here. When someone launches my mobile game for the first time, I would prefer they get into the gameplay first before having to worry about "signing up".
I think this provides for a better user experience as you can instantly jump into gameplay. Firebase supports anonymous accounts and saving progress against anonymous accounts, which can later be converted to an actual account (e.g linking their google or facebook accounts to their anonymous account) while retaining their game progress.
Does anyone have any thoughts on this approach or is it better to force a user to decide at app-launch to make a choice between creating an anonymous account or registering using google / facebook / email / etc?
Cheers
Kevin
This is actually a very similar use case to what it often pitched to web developers using Firebase:
For a shopping app, you'll often let a developer go through the shopping flow and finish checkout. When checkout is complete, you then "promote" their account to a full account so you don't bounce a customer out during the critical flow.
For a game, not only do I love this anonymous account flow (play now, then "upgrade" for any social features you need), but I think you can get a really cool natural flow going on. For example, if you were making tic tac toe, you could use a dynamic link to invite your friends to play against you. This link will usually persist across app installation (iOS and Android, although it's a little flakier on iOS) so the player you invite can jump right into the game you're playing using Anonymous Auth to seamlessly create an account.
There are two considerations you need to make though:
You're still storing user data if you pair Realtime Database with an anonymous account. I am not a lawyer, but if your region has strict privacy regulation you will want to talk to one.
The merging an anonymous account into a "full" account process does have some non-trivial edge cases. What do you do if the player already has a full account (obviously, you have to merge the data. But you'll have to do it by hand as there's no game-agnostic way for Firebase to do it for you)? What do you do if a different user claims the same email address when you promote your account (you'll need to throw one out, and there are rules for resolving which has the stronger claim to the name)?
2 is a little complicated also by the current architecture of the Firebase auth SDK as well. All of the C# objects are pointers to C++ objects under the hood. The "current user" was bound in a way that it references a global singleton on the C++ side representing user data. This has the unfortunate side effect that you can't cache a user data on the C# side in the case of a user entering their credentials incorrectly when "upgrading" an account (usually manifesting itself in having to re-enter a username/password and maybe losing cached data). This bug is actively being tracked (I believe it's a side-effect of this one), but in the near term it just means that you probably want a good way to either re-upload local data (assuming you'll lose access to the DB node once you drop the anonymous account) or you'll want to avoid persisting any user-specific data before migrating a player to a "full" account (probably a consideration I'd have with current privacy regulations anyway).
We are building a to-go order web application for restaurants with Firebase and Vue.
Restaurants can create their own pages, and add menu items.
Users (customers) can orders some foods from those restaurants pages, and pick them up later.
At the beginning of the project, we have chosen to store some transient data (user data, shopping carts, etc.) in the Vuex store. It works fine but there are a lot of complexities in it, which made it hard to maintain.
Recently, I have realized that we could just use Firestore for those transient data as well, which will greatly simplify the architecture, eliminating Vuex completely.
Before making all the changes, I want to make it sure that I am on the right track and I am not missing anything.
I'd really appreciate any comments and suggestions from those people who have experience in building relatively large scale web applications using Firebase + Vue (or even React).
Short Answer
Yes, this seems perfectly reasonable.
Long Answer
Many web applications have their state synchronized via an external service like Firebase, GraphQL, etc. In these cases you may already be using some kind of shared, UI-independent cache (e.g. Frestore, Apollo client). Unless the aforementioned cache cannot be easily accessed by your UI components, there would be little benefit to switching or duplicating the data to Vuex.
Keep in mind that even in the above scenario, Vuex can still be a useful tool to track UI-specific state across otherwise disconnected components in your interface. For example, you could globally identify the user's current viewing mode, or which modal is open.
Yes you can go without VUEX, however, it will limit your potential.
First of all vuex is really simple, you can easly add vuex your code.
Without Vuex you may write same code again and again.
For example you want to redirect your user to his restaurant page when he logs in. So you write a code that first checks if user has a restaurant and then gets his restaurant ids.
Also you want to check when a user opens a restaurant page, if the user owns that page, you write the same code again. However, if you have a function that returns a value if user is the owner or not. You can call it any page you want.
I have a saas platform I'm building and I'm currently struggling with how to model my auth flow. The system is going to be multiple multi-tenant applications but I would like to unify user authorization & authentication. Basically, each US State will have its own web app/resource server/database and every county in that state will be a separate tenant. I cannot combine all states into one application, so that is not an option.
I would like to throw all users and their information/password into one database connected to my auth service. But each county (tenant) admin within each state (web app) needs to be able to add & manager their users and their roles. So the auth service needs to be aware of all the different tenants across each application. I also need to be able to link items created in each database to the user that created it. If I create object "X" and another user in my county views that item, they can see "Kovaci" created this.
I also do NOT want SSO between states but if possible I would like users to be a part of multiple tenants within one app (not a requirement though). Native iOS/Mobile apps are another client I need to support with this flow.
I used this bitoftech article to base off of: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/comment-page-1/#comments
And here is my paint quick mockup: multi saas design
My question is just generally how do I design this auth part? Can I store all users in one auth db like my goal? If so, how do tenant admins manage them and how do I link tables in my separate app db's to the users' current info in the auth db?
The docs say:
Contact Synchronization is performed by the Synchronization service.
The service loops over the active Synchronization Targets that have a
URL for Contact Synchronization Server defined and, for each server,
synchronizes the Segments and the new/changed/deleted Contacts.
Does this happen regardless of whether a synchronisation target is assigned to a publication?
Background
I have STAGE and LIVE env's, separated by a firewall - our ASP.NET website deployed to both makes use of Audience Manager as store for ASP.NET membership.
STAGE has profilesync.aspx and OE APIs/CD setup to use a STAGE_submgmt table so the staging site can function correctly - but how do I get contacts into this table?
If I create a new sync target to point to the profilesync.aspx on STAGE, I can't assign this to a publication because they use the LIVE sync target. Does that matter?
Or is just quicker to just do a manual backup/restore of the LIVE submgmt table and not bother with sync on STAGE at all.
Synchronization Targets will be used even if they are not assigned to a Publication (unless you deactivate them using the checkbox on the editing screen). However, no Contacts would be synchronized in that case - since there are no Address Books to sync. Other items - like Segments and tracking information - will still be synchronized.
I'm a bit confused about your setup. Why would the Publications on your staging system point to the Synchronization Targets of your live system? That would mean that the Contacts on your staging environment are synchronized to your live website. Since you created separate databases for it, I assume this is not what you want.
In that case, I strongly recommend deleting the "Live" Synchronization Targets on your staging environment and only adding the ones for your staging database. Otherwise your staging environment is actively interacting with your live environment.
Edit: Remember: Contacts are not content. They are not published, but synchronized. Most people do not manage Contacts themselves, leaving it up to the website users themselves to maintain their profile. So you also have the option to not have separate databases for staging. It all depends on how you intend to use it. If you do want separate databases, you will need to have separate Content Manager instances for them too.