PHP Framework Laravel: How I Tried It for the First Time
IT copywriter
Reading time:
Hi everyone, my name is Andrew and I’m a Symfoniac. Recently we worked on a project to develop additional parts for our client’s SAP system. At the start of the project, I could choose the necessary set of development tools for myself. And in spite of my preference for Symfony, I decided to take a look at some other PHP frameworks, which could replace the familiar Symfony.
According to the project’s specifications, we had to work through SoapClient with web services responsible for building a user interface and providing interaction between users and a particular part of an ERP system. There was no need for complex structures. The work with databases was limited to the data storage for user authorization and keeping several tables of settings. At the same time, the system didn’t imply further development of a large-scale and complex solution. In fact, we had to implement only a thin client for work with the server of web services.
I cannot say that Symfony is inappropriate to fulfill the project’s tasks but the number of required code lines was too high. Thus, I decided to consider a simpler solution.
I chose Laravel because based on internet reviews, it is quite easy to learn. Besides, PHP Framework Laravel has a big community and shows great results in small and simple projects. To tell the truth, I was curious as to how effective Symfony components within other frameworks are.
Laravel completely met my expectations:
- Easy and fast installation
- Simple and comfortable to use
- Suitable to start with writing the production code
I prepared this review of Laravel, its architecture, and components, according to my first impression of the framework.
Laravel
A framework is a skeleton of a project’s structure providing some ready-made functionality. It helps to solve typical tasks during software development. The framework’s architecture can implement your own set of patterns as well as show the realization of particular widely known patterns.
The Laravel architecture is based on the principle Inversion of Control >> Dependency Injection >> Service Container. Symfony developers know this principle very well as it is a cornerstone of all Symfony developments.
The Service Container Laravel is quite similar to Symfony with slight discrepancies. Unfortunately, you cannot find many details about the Service Container in Laravel documentation. Perhaps Laravel developers did not consider this component as one of the key elements in the framework architecture. I guess they missed the detailed description in order to keep the documentation simple and give other developers a chance to use the component on their own.
Here you can find more details about the Inversion of Control and patterns that follow this principle — Dependency Injection >> Service Container and Service Locator:
Laravel uses some components of Symfony. It doesn’t mean those components are built in the framework by so-called “copy and paste” actions. Components are likely to be incorporated in the framework structure, some of them are changed a little, others are supplemented and adapted to coincide with the ecosystem. That made sense as many Sf components look like ready-made code and can effectively solve tasks on the general level.
Framework Components: comparing Laravel and Symfony
As I am a Symfony developer, I try to compare two PHP frameworks – Laravel and Symfony.
HTTP fundamentals & MVC pattern (Controllers, Routing, Views)
Let’s turn to the roots of web development, in particular, to the HTTP protocol. Whatever your server code is doing, it has to receive some request eventually, process it and give back a certain answer. If you use plain PHP, then you can easily be confused with the body of the response and the return of the response headers. If you’ve been in web development for a long time, I can just mention “Headers already sent” and you get my point.
In order to avoid the same problems, you can just emulate the work with requests and responses as they work with a couple of the associated classes (objects). The component HTTPFoundation in Symfony serves this specific purpose. It is used in Laravel and allows you to emulate the work on the level of the HTTP protocol. It’s simple and convenient in use. You can find examples in the documentation.
Pattern MVC is very well known and implemented in Laravel. MVC in Laravel is quite standard including controllers with actions, separate level with a view, a template engine and everything that we mean by a model.
A simple action in the controller can look this way:
public function postResetPassword(Request $request)
{
$user = Auth::user();
if(!$user){
return redirect()
->action('AuthController@getLogin');
}
$user->changed_by_user = true;
$user->password = $request->input('password');
$user->save();
return redirect()
->action('UserController@getInfo', array());
}
Here we check whether a user is authorized or not and change his/her password. It’s better to take into account that action receives an object of the Request class, that is in turn inherited from the Request class included in HTTPFoundation Symfony:
use Symfony\Component\HttpFoundation\Request as SymfonyRequest; class Request extends SymfonyRequest implements Arrayable, Array
ORM Eloquent vs. Doctrine ORM
A fairly standard purpose in web development is keeping the objects in a database and reading from the database. You can use the so-called Models to work with the database. ORM Eloquent is responsible for this process in Laravel.
Eloquent uses pattern Active Record that is significantly simpler than the patterns DataMapper, Unit of Work and Identity Map. The last two are applied in ORM Doctrine that is the basic ORM for Symfony. Eloquent has many advantages due to its simplicity. The main benefits include code terseness when describing models and clarity in use when writing the code. It is not obligatory to describe every accessor while creating a model. It’s enough to access a property by the field name in the database.
Here is an example of work with Eloquent:
$user = new User; $user->name = 'John'; $user->save(); $user = User::find(1); $user->email = 'john@doe.com'; $user->save();
Simplicity has a downside — by default, you should not wait for the hints in IDE due to the absence of the described methods. This problem can be solved via laravel-ide-helper that generates comments to models.
There are also some helpful options like a built-in migration generator or simple description of relationships between models. Overall Eloquent is very convenient for the development of small and medium-sized models. It’s hard to say how well it works for large models, although I can propose that the Eloquent capacity is not enough.
Artisan vs. Console Commands
Being a contemporary framework, Laravel is a powerful tool to work with the console. In Laravel this component is called Artisan. It provides wide opportunities for different routine operations. Basically, the component includes code generators (migrations, models, controllers, listeners, etc.). Using Artisan, you can manage the tasks, implement operations within schedule, clear cache, and do many other things. Besides, it’s easy to write your own commands via the created and registered command class. You can also create command chains by calling commands from each other.
For example, if you’d like to create a new model, then you just need to run the following command in the console:
$ php artisan make:model User
Artisan slightly differs from the standard console components of other PHP frameworks. It’s essential to know that it is here and works. My favorite command is “PHP artisan inspire” :).
Service Container
As I mentioned before, Laravel architecture is based on the pattern Service Container. Its implementation is similar to the implementation in Symfony with a few differences.
When you work with Symfony, it’s better to follow this pattern and conduct dependencies via complex abstract layers. The whole framework is built on the services and it is almost impossible to receive the specific class object directly. Therefore, you need to apply to correct services for receiving the class object.
Laravel is simpler regarding the Service Container pattern. A developer has a free hand. I found only several examples of receiving the required methods or objects by calling through the static interfaces. In common cases, it can be seen as a violation of the template principal, but there is nothing criminal, it just depends on your preferences and your approach to web development.
Templating: Blade vs. Twig
The View is implemented on the basis of the template engine Blade. An ordinary template engine includes built-in operators like “if”, comfortable generators for HTML blocks, allows overriding the template parts and accessing the required services. You can also write your own directive.
I found Blade less convenient than Twig. Although Laravel is simpler than Symfony, the template engine in Symfony is easier to learn.
Debug and error handling
There is a development mode in Laravel when a developer gets access to the special panel on every page. In the debug panel you can see what happened on the framework side when the response was prepared. For instance, there you can find the list of implemented requests to the database, actuated exceptions, sent emails and more. The panel looks very similar to the debug panel in Symfony, but it is not as powerful.
It goes without saying that Laravel creators oversaw the most important things for web developers except debug panel. The system can log everything that happens, has automatic code generators and special function dd for data output in the process of development.
Conclusion
My general impression of production work with the Laravel framework is quite positive. The development speed can be faster than in Symfony. The frameworks simplicity and relative code terseness reduce the time for writing code. There are a lot of features that facilitate the development routine. It also gives a great boost!
You can use Composer for the framework installation and work with third-party libraries, so it’s very clear too. As an aside, Laravel performance is worth mentioning. The framework isn’t complex and mostly very fast. I did not use any special benchmarks, but the superiority in speed is obvious by my sensations and according to the debug panel view with the general time of the script.
I felt a little disappointed with the documentation. It is very limited. I suppose that Laravel authors followed the minimalist strategy when creating their documentation. It includes only a description of the main functionality. Everything else you have to investigate for yourself. However, Laravel has a big community that can help you anytime when you face problems.
Finally, I’d like to say that Laravel in practice is the same as in theory. It is a very simple and useful PHP framework especially for cases when you don’t have to deal with all the difficulties of enterprise development.
Comments