I think this is the hard part of any project: to separe concerns. It would be great for many of us to teach us how to proper start a project arhitecture rather than keep teaching us how to code in Laravel. The coding is much easier if a developer has a good start.
this is mostly based on what are the requirements of the system, one thing may be applicable to a project but not on other projects. deciding on how you architect your project depends on that and what are the available resources
this boils down to how much experience the team has on database architecture, frameworks, techniques, infrastructures, coding, and etc. for example, I could teach this and that, but does the team have the experience to pull off this design/architecture?
I see no issues with separate guards and using polymorphism for logic sharing. I see more issues with using single guard for two different kind of users which can at times cause vulnerability and require lot's of logic to separate concerns. There's no better way until the project at hand demands you pick one approach instead of the other.
I am creating a project where the User can have one of three roles: Admin, Teacher, or Student. To achieve this, I created a "users" table for authentication purposes and fields that are commonly owned by "users", such as "name", "profile_picture", and "phone_number". Additionally, I created a separate table for each role (admins, teachers, and students), each with its own specific fields. For example, the teachers table has a "subject" field, and the students table has a "class_group_id" field (foreign key). Does this match the setup described in the video?
It is normally indifferent but huge different in database with huge amount of users and also normalization. Index sizes, first row admin vulnerabilities, etc in my opinion
It doesn't work in a scenario where a customer can signup in multiple stores as a different user using the same email and phone number. Where the user types are: Admins Store owner Customers Because a table will be forced to have duplicate emails and phone numbers with store_id as the composite key to uniquely identify a user for a specific store. I believe in this scanerio you will need a new table for customers.
The app I'm currently working on, I don't have an option I have to use seperate guards ( although, I'm usung the same user table different guard names ) I have role categories, not roles. My boss wants vendors to have the ability to create roles eg accountant, users etc Then the system_users can create roles in their own end There's no logical way to do this with the available roles package and im not ready to recreate my own So I'm using multi authentication guards and extended spatie permissions to allow system users be true global roles and then vendor roles are normal roles Have i encountered issues, yes. Am i encountering issues, yes But that's my only option
Video title is kind of Misleading, Roles are not considers as Users. What here talked about is User Type and it's separate profiles. I consider role as group of permissions, One user can have n number of roles as per requirement. Depends on size of application may be one or multiple roles for user.
User types and roles are different things. So having "admins" and "users" tables is impractical. There should be a single users table. Then you can differenciate users (types) by using sub-tables (see Class Table Inheritance). Roles/permissions, on the other hand, is a seperate issue and should have its own tables.
Basically in a fin tech system or system that handles money, please make sure you seperatate concerns as much as possible, do not mix match users and admins, when one is bridged, you're finished.
Separate Databases should be concerned with different things. In Laravel, Eloquent relationships do not work well across different connections (database configurations). If you want to separate concerns in different databases, user profiles are not the way to go. I personally don't do it because my projects are not big enough to require it but assuming the database driver is used for some of the configs, things that can be moved to a separate database are the job tables (failed_jobs, jobs), the session table (sessions) and the cache table (assuming you use the database driver for cache instead of something like redis). I think it's overkill anyways.
just recently i made 2 school managment projects i used spatie permissions in the first project to separate between (admins, teachers, students and parents) and honestly i regret that, the project was a mess and i had to write a lot of if statements and now i'm working on the second project and i'm using guards to separate them and it is looking good (i didnt finish yet but for now i like what i see)
Actually, when you use spatie for roles, you need a separate controller and view. The model remains the same. So, you never use even an "if" in your life.
User role or user type can be helpful, depending on user role or user type. This allows user to choose between login as doctor or as user or switching if they need it from the same ui.
Hello, your lessons are very good! Thanks you! I have a question about not this video. Why you choose laravel instead of symfony? If you record video about that, it will be awesome
Si extiendo mis tablas como profesores y estudiantes con la de usuarios y esta tabla de usuarios tiene una relación con roles, que puedo hacer para que solo ciertos roles accedan al sistema, por ejemplo: que solos los usuarios de la tabla profesores (que tendrá rol de profesor en la de usuarios) y los usuarios con rol de admin puedan acceder al sistema, y los usuarios de la tabla de estudiantes no puedan acceder al sistema web pero si a la autenticación por API
i see it as an area if some users type allowed to enter this area but some of them has limitation inside it. it`s ok to be one table one auth but if it`s a different area not all user allowed to enter it like dashboard it just allowed for admins to enter this area i see it`s better to be a separate table with separate guard and auth
Email issue: Lets use your Patient/Doctor example, but it can be User/Admin, whatever. I'm assuming that the email is defined as unique, so, lets get to the issue: A patient can in practice be a doctor too, because doctors can get sick also. In this situation then a person can register as a patient and as doctor, but unfortunately they cant use the same email, though it would be pratical that they should be able to. I imagine you can circumvent this by not specifying as unique and they put some registration logic to check email and role to permit email duplication but restrict it if the user has the same role. What would be your approach to work-around this? Table wise, logic, etc, how would be your best solution for this?
If possible, at all times I would avoid the situation of same person with same email in different roles. Need different roles? Use different emails. In rare cases, you can't avoid it, then role_user pivot table. Everything else is hard to explain in a short comment, need a separate video.
There probably are other examples, but in your example the same person as a doctor would use his work email, while he'd use his personal email as a patient.
@@nero3700 Yes, in that example, the doctor would most likely use a working email and a personal email. But, that is not what i was trying to point out. But, there is always a possibiltiy that the doctor would use the same email for both cases, either the personal or working email.
I didn’t know that you are answering questions on twitter.. probably cause i dont use twitter.. you mind if i share some code with you for your review? Am trying to become a better laravel developer and your help would be highly appreciated.
I sometimes do that if I see a case usefu not only for that person but for many people in my audience. If you feel your case is like this and you're ok with waiti foe a month for review, email me povilas@laraveldaily.com
Really cant say which one is better. If using guards makes things better why not use them??? I had similar situation where i created online vacancy portal. I maintained that with guards admin for admins and default web guards for user. Roles and permissions were maintained only for admins as admins had two roles maker and checker. Was that a bad approach then????
If both the patient and doctor have an address, is it okay to repeat all the address fields in both tables or create a new polymorphic address table? In this sceneario an admin doesn't need an address but it's required for a patient and doctor.
I have a lot of content about that package on LaravelDaily: laraveldaily.com/tag/spatie-laravel-permission Or generally about permissions: laraveldaily.com/tag/auth-roles-permissions
I prefer separate admin and user logins. The administrator cannot have the option of reminding/resetting the password and you can additionally protect against unwanted number of incorrect logins to the system or restrict access only from a specific IP.
