In this lesson, let's talk about structuring projects by areas based on roles. It's a typical scenario for many projects: for example, you have administrator users and regular users.
There could be a more complicated scenario: for instance, in school management software, you might have students, teachers, admins, etc. So, how do we structure such projects?
We have two sub-questions I've seen developers asking:
- Do we define separate Models:
app/Models/Admin.php,app/Models/User.php, etc? - Do we define separate namespaces:
app/Http/Controllers/User,app/Http/Controllers/Admin, etc? Same with Routes?
The answer to the first question is no. Please, please don't create separate models and DB tables for different user roles. It will bite you in the long run: you will need to repeat the same logic in multiple Models, then. Use one model User and then roles/permissions DB tables for this: below, you will see a few examples.
The second question can be answered with "it depends on a project" or "it's your personal preference".
Some projects have totally separate admin areas: different designs, different features, separate login areas, etc. Then, of course, it makes sense to separate the Controllers/routes/views into subfolders.
Other projects are just about checking the permission of the users to access the same pages/functionality. In those cases, I would go for the same folder for Controllers/routes/views and check the permissions as needed.
Let's look at examples of this approach from open-source projects.
Example 1. Check Roles/Permissions in Controller.
This approach to structuring admin/user areas is about using roles/permissions and not changing anything about the structure of the folders.
In other words, you have the same Controllers, common for...
I think that statement says it all. Having been bitten by a production project that is more than four years old I have learnt a lot through mistakes, but still have many lingering questions.
Let me make it clear I'm not worried about name spacing. Name spacing in my opinion is a more general / beginner type question.
Implementing multiple roles if you have a single database column doesn't suffice. It's back to many-to-many relationships either roll your own use Spatie's like so many people do.
The moment you have many-to-many filtering and a User database model it gets tricky.
Let's take this example for a video game.
Role #1 - Administrators - mostly administers the users but can also be a player. So more than one role.
Role #2 - Players
Role #3 Viewers. Only observes games and can like stuff. But can also be players. So again more than one role.
To design this more complex project there will be many hanging questions. Perhaps in your "Game" model there is a GameUser many to many and each line has a pivot column for "role" who created it?
Also, you probably can't have one dashboard. You have to carefully think about when a user with more than one role logs in, what to show them, how to direct them.
Then for your back office. Unless you like pain you're already using either Filament or Nova. In both Filament and Nova it's not so easy to generate resources for the same model but have them "separate". Elegant filtering is not so easy nor readable with many-to-many relationships. Performance might even suffer.
I would like to see a tutorial that handles the more complex cases as mentioned above starting with a user can have more than one roles, redirection, and how to elegancy build the admin back-end without breaking your back.
After having type this huge reply I was wondering if you thought there was ever a use case for this:
I've experimented with it and because of "authenticatable" it's not simple. But somehow I thought that to be a good solution, at one stage.
Wow Eugene, what a long comment. I appreciate you taking the time.
The thing is that your question touches on multiple topics that require multiple DEEP tutorials comparing the approaches. I will try to touch on them in my upcoming course about Roles/Permissions.
But, in short:
Everything else depends on the exact functionality you want to achieve for the exact project. The balance between performance, developer experience and user experience.
Also, one more thing I remembered: Spatie package docs say this, and I would apply it broader: don't be attached to roles, always check for PERMISSION (Gate) in your code, whichever roles have those permission.
A role is just a "parent" concept of "set of permissions", and roles may change quite a bit. But permission names rarely change.