So my app is a large and flexible multi-user business database, which means there are lots of tables that contain information about how it works and is set up…
… and I can only load all those tables once the user has logged in.
I’m curious about how you go about doing this if you have a similar style of app.
Do you have a very large set of actions which happen upon a successful login?
If so, how do you manage a login at sign-up as well as a normal login?
Is there another way you manage this situation?
I’m trying to avoid making and maintaining the list of data loads in more than one place!
That’s a fairly broad topic, so more than one way to manage…here are some thoughts that might help you choose…
Server side config/data variables – If these are used across manage actions, the I use Session variables to load them up at login.
Front end page loads – I often have a single page_load action that loads up variables, option sets, etc. Doing this as a single action is best if they won’t be refreshed during the use of the page. If you have multiple server actions that the front end calls, you will run into restrictions on how many can run simultaneously.
Front-end cache – For items that change, but rarely, then consider local storage and a system for refreshing that when needed. This way it persists across sessions.
If you want to stick with vanilla Wappler, there isn’t much for re-using the actions across different login scenarios. I like stored procedures in mysql as any changes made will be immediately used by all actions calling that procedure.
In a multi use environment I tend to do everything by reference to the securityprovider.identity
So for example a server action may first obtain the identity, query the user table for any necessary data related to configuration.
Then each serveraction will return data related to that users configuration or role setting That way the server action does all the decision making all with reference to the current logged users id and the action can be called by any user in the confidence that only the appropriate data is returned.
That is dependent of course on the data being properly structured with all the appropriate keys linking back to the Id returned by the securityprovider.identity