Can an Angular application be modularized by roles?

Question

I'm working on an Angular project with 6 other people. The application will be able to handle 4 types of users: 'administrators', 'partners', 'students'...

I've noticed that when structuring an Angular application, the goal is to modularize the most important parts of the application. For example, a Class module, an Exam module, etc. And within those modules, access to those views on the client side is managed using guards.

For instance, students and partners can access the Class module, but if you're a PARTNER within the Class module, you can access some extra classes. Guards are used to manage access to that web page.

My main question is: Can an Angular application be modularized by roles? So, instead of modularizing by Class module, Exam module, etc., you can modularize by roles: Student module, Partner module, Admin module with its own routing module. With lazy loading, you only send to the user what they need, and then protect that lazy loading afterwards with a Node server. As it generates a js file (23rwf234asd.js), I understand that you can implement security.

But if you modularize by roles, for example, admin.Module, Student.module, Partner.module... Is this possible or is it frowned upon? And when the user logs in, you later send them the corresponding js file. That is, when you run the ng build command, Angular generates specific files for the module configured for lazy loading, for example, 23ksf23ajd3asd.js. What I'm saying is, the user logs in, and you redirect them to their corresponding role module.

Also, I would like to resolve this doubt I have. I know that lazy loading is used to improve the performance of the web application by sending the user only what they need.

But studying Angular, I realize that you can also block the sending of the generated js file when running the ng build command if the user doesn't have the corresponding jwt... What do you think of this last thing I'm saying? That is, in Angular, you will have a RESTful service that will communicate with the corresponding server to deliver data from the database to the user. If you protect the lazy loading, you can protect the RESTful service...

For example, the AdminModule has its own RestAdminService...which in turn contains http://201.201.34.21:3000...that URL would only be known to the admin.

The user has to log in to be able to know which server is used to get data from the database, and the only way to know that other server is by going through the login.

Answer 1

My main question is: Can an Angular application be modularized by roles?

You have two ways:

1. Using Directives the concept here is that the directive will check if you have the role/permission to view this component (using an api request or other stuff) if not the directive must remove/hide the component. (Note: the same can be achieved using ngIf)
2. Using multiple router-outlets: by assigning a name to each router-outlet and specify the outlet name in the routing configuration. check the following answer in stackoverflow

Also, I would like to resolve this doubt I have. I know that lazy loading is used to improve the performance of the web application by sending the user only what they need.

But studying Angular, I realize that you can also block the sending of the generated js file when running the ng build command if the user doesn't have the corresponding jwt... What do you think of this last thing I'm saying?

AFAIK - any component in a lazy loaded module will be sent to the client when requested, that means if you have a component in a view that's declared in another module (lazy loaded) the module will get sent to the client, that's how the guard prevent the module from getting called until the guard returns true

Answer 2

Thank you Faisal Shahin for your response. It's very useful to us. The group was already thinking about doing what you suggest.

We will use directives or ngIf to control which elements of the dashboard are visible based on user roles. This means that the application will have a dashboard, and depending on whether the user is an admin, student, teacher, etc., we will use ngIf to control which URLs the user can access. When the user clicks on them, they will be directed to the corresponding components. And yes, we would use guards to block access to certain URLs from the interface we send to the user if they don't have the specific role. This involves adding a guard to a component or a module configured as lazy load.

But you dont answer the question: My main question is: Can an Angular application be modularized by roles?

I haven't been able to find any project examples on the internet that modularize by roles. However, I found a post on this same forum that structures lazy loading based on role. In this way, after a login occurs, only the specific module of that user that contains the components, services, pipes, and directives of that user would be downloaded from the server.

redirectTo lazy module based on user role As you can see in that image, a lazy load is being created based on the user's role, making the use of ngIf and directives less necessary. But since I don't see many projects doing that, I have my doubts about whether there is something I'm not considering. Moreover, from my perspective, modularizing by roles seems much easier.

---

---

"So by modularizing by roles, Angular will eventually generate a single file that contains the specific things for that user. Well, following that idea, I think even more security could be added because I have the option not to send the module from the server side by creating a middleware (an entry point) that verifies the JSON web token."

That's why I made an explanatory diagram of how the idea would look like.

I emphasize this last point because I have only found one post on StackOverflow that tries to open a security topic of the type I am mentioning. That is, that the server decides whether or not to send the components, modules if the user is not authenticated or does not directly have the role.

Unfortunately, that post was closed because supposedly it does not provide enough details. Then someone gives their opinion saying that it is not necessary although they used to do something similar before. However, I do see a lot of utility in it.

Angular user/role based security

---

---