I am trying to develop a RN application which would contain different screens, based on the role of user logged in.
Application would have 4-5 roles and each role would kinda be like a whole application within itself.
I am undecided as to what kind of architecture should I have if I am looking to incorporate all these roles within one application only. Or if I should go about making a separate application for each role?
I think more important than the roles will be the actual tasks your roles have. I'd create a matrix for getting clarity on which role requires which tasks. You then write task specific ui screens/components and show/hide based on the role matrix. This will probably be the most logical architecture and promote reuse of your task oriented ui components. Imagine a new role comes into the picture for your application - Or a new task. For both cases this architecture is easily extensible/changeable.
You can do this approach with writing a single app for all roles or a separate app for each role - Your task specific modules will be reusable in either approach.
And the comment to use redux for state management is a somewhat different topic, but generally not bad advice for a reasonably complex app. Just read this to get more clarity.
Related
I am researching on the demo version/account of the application for the users. The demo account is a read-only account to prospects so that they can view a fully functional demo account. Instead of signing up or paying for the application to see what it looks like, they can view what the service and what are the functionalities without signing up for it.
It could be based on static data (and doesn't have to be dynamically generated).
Based on my research, I have concluded a few things that can be helpful to create a demo application and keeping the persistency of the demo application with the original application:
We can have separate routes for demo application something like app.com/demo/dashboard or app.com/dashboard?demo=1. With the separate route, we have to use separate components because I don't want to entangle the demo components with the original components because it has lots of authentication logic, API calls and other stuff. With this approach comes the problem of keeping the persistency of Demo application UI with the actual application.
To overcome this, I can use the same styling for multiple components but not the structure. So with time, this will become cumbersome to keep the structure in sync.
So I am looking for general answers for:
What is the most efficient way to create a demo version of the application?
What data to use?
How to keep the components persistent. (For that, maybe we can create a Git workflow to make sure engineers update the structure of Demo UI whenever they update the structure of original UI)
I hope this pseudo code convey my thought process
One of the demo web application example is: https://demo.pritunl.com/
Guys! I'm kinda new in cypress and was looking in this link (https://www.cypress.io/blog/2019/01/03/stop-using-page-objects-and-start-using-app-actions/ )to see the diff between page objects and app actions. Since app actions are brand new, i was not able to find any documentation to help me out. In the link above, there was an example of how to predefine values on the page so no UI interaction is required. I was able to follow the steps and realize the changes here, but i don't know how to do that outside this example.
How could i manipulate cypress application to do that?
Skimming the article, the idea of application actions is to export an API/hooks from your application that your test can use to interact with the app (its model, state etc.), for the purpose of speeding up certain workflows (such as seeding the model), awaiting certain events etc.
There's nothing magical about it, but it requires knowing your app architecture — what you need to export (i.e. expose on the window object), and how to interact with it. If you're not the developer of the app (e.g. you work in a separate QA department), and treat the app as a black box, then you'll need to discuss with the dev team how best to implement this.
Each app is different, and depending on the app architecture (What framework does it use? How does it store state/model? etc.), each solution will be different.
Currently I've been tasked to create a bunch of small-to-medium applications, each of them having some common functionality.
Implement a preapproved boostrap-based graphical design. Therefore, they will use the same assets, images, css and JavaScript components.
Share the same licensing-based mechanism. An application service will be built where it will scan a file or database to get the number of licenses available for each app, thus granting or denying access to users. The only thing that varies is the name of the application instance itself.
Use AzureAD authentication.
Each must use the same authorization mechanism. A claims-based mechanism will be built to retrieve the claims from the database, given a user AAD account.
Each must share the same administration console.This console will be the one needed to populate user information and common catalogs.
A service will be built, to show toast notifications within the apps.
An email notification service will be built, to send emails to users when triggered by business rules.
And some other, less important features, but these are the core ones.
A first, perhaps naïve approach, was to create an ASP.NET Core 2 solution for each application, and implement the shared functionality in a sort-of Core assembly that can be shared by each app. However, while this could work for points 2 to 5, I'd still be repeating the graphical UI design for each app (basically, copying the wwwroot folder as well as the shared razor views five times). So, a change tomorrow in a CSS would have to be replicated five times.
Another approach would be to create a single ASP.NET Core 2 solution, implement the shared functionality and the UI, and then use the "areas" feature o ASP.NET Core 2, each area being a different app. The problem to this approach is shipping the app: if I have to install the five apps in a customer's server, no problem. If I have to install, say, only two apps, then I'd have to ship the five apps anyway and find a way to disable the other three apps.
So, I'd like to know if there is a feature in ASP.NET Core 2 for handling this type of scenarios, or alternatively, what are industry-standard architectural designs that could apply here.
In Windows Presentation Foundation with Unity, I can create a common shell, and then load modules in that shell, within the same shell window. So, using configuration files, I can add or remove modules as I see fit. What I'm looking is something similar in concept. I do not want to create five ASP.NET Core solutions and copy-paste the wwwroot folder and implement the same mechanisms of authorization, notification, email, etc., but rather, find a way to load the core, common features and then load additional features.
Thanks in advance.
I'm very new to vuejs world and I'm trying to move my existing application to vuejs.
I use Laravel as a backend framework. I got a lot of entities and settings, and in order to the app to work properly I need to retrieve from server some necessary data like user role etc. So basically I need to:
Hide the whole app and show a loader instead
Make few ajax requests in order to retrieve data from server
Store the data somewhere, so that it's accessible everywhere in vuejs app
Hide loader and run the app
The data might be changed though, for example, I have a team and team members. The list of team members used in many places. So if I add a team member the team member list should be updated as well.
So I don't want to have a global javascript variable for storing such data, because any modifications in this variable should affect the data-binding and stuff.
How could I achieve this?
Thanks
Your use case seems appropriate to using Vuex.
From Vuex documentation:
Vuex is an application architecture for centralized state management
in Vue.js applications. It is inspired by Flux and Redux, but with
simplified concepts and an implementation that is designed
specifically to take advantage of Vue.js' reactivity system.
In other words, it is specifically designed to handle situations such as:
The data might be changed though, for example, I have a team and team
members. The list of team members used in many places. So if I add a
team member the team member list should be updated as well.
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.