Laravel Controller Subfolders Structure: Admin, User, Common Controllers?

We recently received this question below on Laravel Daily Discord. In short: how to structure Controllers? Should it be by roles?

And, the second part of the question: what if some features need access by multiple roles? Where should those "common" Controllers be located?

Let me explain my philosophy.

Option 1. Small Projects: No Sub-Namespaces

If you have up to 5-10 CRUD-type Controllers with similar actions, you may not need the Admin/AbcController and User/AbcController with duplicated code. You can just get away with app/Http/Controllers/AbcController and use roles/permissions to get different data by roles.

Example:

class TaskController extends Controller {
 
    public function index()
    {
        // Get all tasks or tasks by the user
        $tasks = Task::when(// ...
 
        // You may or may not create sub-folders for different views by role
        return view($role . '.tasks.index');
    }
 
    public function create()
    {
        // Only the admin can access this, for example
        $this->authorize('tasks.create');
    }
 
}

Option 2. Clearly Separate Sub-Applications

In some applications, you can see a clear distinction that there should be an "admin panel" area, where administrators should manage the same tasks but in a totally different way than regular users.

Also, this option fits when there are different methods or parameters with clearly different meanings.

Example:

// Admin/TaskController to manage tasks as CRUD:
class TaskController extends Controller {
 
    public function index() {}
    public function create() {}
    public function store(Request $request) {}
 
    // ... other methods
}
 
// User/TaskController to view tasks in different formats:
class TaskController extends Controller {
 
    // Tasks by my project
    public function project_tasks(Project $project) {}
 
    // Tasks by my tag
    public function tag_tasks(Project $project) {}
 
    public function calendar() {}
 
    public function reminders() {}
 
    // ... other methods
}

Option 2b. "Common" Controllers?

There may come a point in your project when you have structured the Controllers by role areas, and a new Controller should belong to multiple roles. For example, let's imagine a ProfileController which may manage the profile for any type of user.

Then, some of the sub-namespaces of the application may not necessarily be role-based.

For example, the typical sub-folder structure I see in App/Http/Controllers:

• Admin/
• User/
• Auth/: login/registration forms, profile management, settings
• Public/: homepage, about/contact pages, public data
• Api/: totally separate world for API structure, with its own sub-folders
• etc.

For larger applications, there may even be plenty of sub-folders on top of the role-based ones, representing the modules of the application. Then, separate sub-folder routes are protected by role Middleware. Take a look at Firefly open-source project:

In general, I would advise you to take a look at examples in the open-source projects list on our page and focus especially on bigger projects. You will get plenty of options on how to structure your Controller sub-folders.

And, of course, you can check out my deeper course on this subject: How to Structure Laravel Projects