https://medium-com.translate.goog/@destinyajax/how-to-build-modular-applications-in-laravel-the-plug-n-play-approach-part-1-13a87f7de06?_x_tr_sl=en&_x_tr_tl=vi&_x_tr_hl=vi&_x_tr_pto=wapp
Last updated
·
4 min read·Feb 2, 2019
--
6
Knowledge is a process of piling up facts; wisdom lies in their simplification.
Simplicity; its sounds amazing and interesting right? For you to be able to build modules (a sub system) off your project and reuse them in another project. Yes! And that’s what I will be showing you in this article but first let’s understand the solution we are trying to solve.
Laravel is a wonderful PHP framework with a decent, scalable architecture and a nice folder structure. But there are times when your application becomes bigger, your code base becomes larger , and it become overwhelming to manage.
If you have worked on large applications before, you might have noticed that you end up with bloated controllers sooner or later. Even if you use interface or service classes to extract logic from the controller, the amount of dependencies, methods and lines of code will grow over time.
Recently we @sprinble started working on a huge enterprise project using Laravel 5.7 which was going to be a huge project in terms of functionality. Considering the scale of the application, the different modules that it going to have, and instead of chunking every thing up (controllers, models and views etc) in the existing directories that Laravel provides, we decided to implement modules such that each of the modules will have everything, (it’s controllers, models, views, middlewares, any helpers etc) separated. And the most beautiful part of it all is that these modules can easily be plugged on another project or shared across teams easily which saves a lot of time.
The solution we arrived at was to build each part of the application as a module on its own but can communicate with other modules in the application which is referred to as Loose Coupling in the Software Engineering term. This led us to a Laravel package called ‘nwidart/laravel-modules’.
nwidart/laravel-modules is a Laravel package which was created to manage your large Laravel app using modules. Module is like a Laravel package, it has some views, controllers or models. This package is supported and tested in Laravel 5+.
The nwidart/laravel-modules package is a re-published, re-organised and maintained version of ‘pingpong/modules’, which isn’t been maintained anymore. For more information about this package. Click Here.
Please follow the step below to implement the same module-like structure for your next big project.
According to the package’s documentation, the package requires PHP 7.1 or higher and also requires Laravel 5.7 to work.
To install the package through Composer, run the following command:
composer require nwidart/laravel-modules
The package will automatically register a service provider and alias. You can as well optionally, publish the package’s configuration file by running:
php artisan vendor:publish — provider=”Nwidart\Modules\LaravelModulesServiceProvider”
By default the module classes are not loaded automatically. You can autoload your modules using psr-4. For example :
And please don’t forget to run composer dump-autoload after the above processes.
Now its time for us to create a module in our application. To do this run the command below:
php artisan module:make <module-name-here>
Quick Tip: Please always use CamelCasing naming convention when naming your modules.
It is also possible to create multiple modules in one command like the one displayed below:
php artisan module:make Blog User Auth
The command above will create three different modules Blog, User, and Auth modules.
After creating a module you should get something similar to the image displayed below:
Can you spot the difference? The ‘Modules’ folder houses all the modules you created, so you can go ahead and click on the ‘Modules’ folder to see all your modules and their files respectively.
It has been an exciting moment all along, to be able to modularize your Laravel application for better management and use.
With this we have come to the end of this first part of ‘How to build modular applications in Laravel’. In this part we were able to achieve how to create modules and why we should create modules.
So in the part 2 of “How to Build Modular Application in Laravel — Part 2” we will looked at how we can use the modules we have created, like running migrations, seeders, using routes, models, controllers, and views.
Thank you for reading and please don’t forget to give a clap so that others can find this article easily.
