I want to make three layers of application all served through Rest API.

For a user case we can say it's school management system where there could be multiple schools where the teachers are administrators of different classes.

  • Super super admin: Is the service provider (me) creating the account for the schools which want to use the product.

  • Super admin: Is the administrator(headmaster) of the school assigning different groups for the teachers at schools, and having access to all of the groups plus extra features like statistics etc.

  • Admin: Is the teacher managing the students and updating the calendar, grades etc.

  • Student/Parent: Can view the changes in calendar check the grades, write comments and messages etc.

I have never made anything that big before and it is hard to wrap my head around how to implement the role system or the grouping and where should I start.

What is the best role architecture in this scenario, and how should database structure look like, and roles would be handled ?

Should it check the user role for each function call or is there other ways to do without repeating myself.


2 Answers 2


If at all possible, put everything in a single database. One database per anything (in your case, per school) is always more difficult to manage.

You start by creating a table that holds the roles. Then you create a table that associates roles with users. It would contain UserID and RoleID. Roles can be cached, so that you don't have to be constantly looking them up from the database.

Once you have your role-based system in place, I have found that creating a mapping between roles and allowed activities is incredibly useful. You can do that in the database or in code.


From experience, I would avoid using layers in a role system. A layered system like you're describing has an obvious drawback: Every role in the pyramid has all of the permissions of roles below it.

For example, does it make sense that the Super Super admin which has permission to create the school accounts also has permission to view and change grades?

Ultimately what you're describing is roles which are inherited. There is a key difference between this and layers: with inherited roles, you don't force yourself into a hierarchical structure where roles take on permissions they otherwise wouldn't need. Essentially, instead of a pyramid, your roles would look more like a tree, where you can branch off and extend/inherit roles freely without the concern that you will break existing permissions.

If you have a db table called Permissions, you can create a many-to-many relationship with a Roles table (thus, there would be a join table, called roles_permissions, for example, that maps permission_id to role_id).

To handle extending, you can include a parent_role_id field or something similar in the Roles table, which references another role. When resolving a role's permissions, you look up the role in the table, recursively follow the parent role until you find a root, and then build your permissions up from the root. This way you can add new permissions for each role, or even override permissions.

For example, role A extends role B. Role A now has all of role B's permissions. New permissions can be freely added to role A, independently of its parent (role B). Likewise, if your Permissions table has a column which dictates whether a role is GRANTED or RESTRICTED, you can also remove permissions.

  • While it doesn't sound like your system has a need for it, I want to just quickly mention that I think extending multiple roles is a mistake. It turns your permissions tree into a permissions graph and you now have issues where roles can have conflicting permissions and you need to somehow resolve them. It becomes a massive headache to implement as well as use.
    – Jessie
    Commented Aug 20, 2019 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.