Laravel – czy warto się go uczyć?
23-11-2023
Laravel był drugim, po Code Igniter, frameworkiem PHP, który opanowałem. To w nim jednak zacząłem programować zawodowo, oraz robić projekty poboczne i hobbystyczne. Pomimo, że pracuję też z innymi technologiami, do tej pory jest to framework backendowy, którego używam najczęściej. W niniejszym artykule postaram się co nieco powiedzieć o jego wadach i zaletach. Nie będę jednak wchodzić mocno w szczegóły, ponieważ ten tekst kieruję raczej do osób, które szukają swojego pierwszego frameworka i rozważają wybór Laravela.
Spis treści
Próg wejścia
Próg wejścia dla nowych programistów jest bardzo niski. Mamy świetną dokumentację, dobre CLI (Command Line Interface – innymi słowy wiele wiele podstawowych czynności jak tworzenie nowego controllera, czy modelu można wykonać przy pomocy jednej komendy), proste do zrozumienia ORM, które ułatwia pracę z bazą danych, wiele gotowych rozwiązań, jak Starter Kity, a to tylko część ułatwień które serwuje nam Laravel.
Żeby nie być gołosłownym, wyobraźmy sobie, że chcemy wybrać wszystkich aktywnych użytkowników z bazy danych (User, to oczywiście nasz model):
$user = User::where('active', 1)->get();Mamy też świetny Tinker, który umożliwia nam operowanie na bazie danych w podobny sposób, jak w konsoli mySQL, ale przy wykorzystaniu Laravela, w tym ORM.
Bez wątpienia bardzo istotne jest też to, że Laravel ma w zasadzie większość potrzebnych rzeczy dostępnych od razu po uruchomieniu – od systemu szablonów (w tym przypadku jest to blade) po seedery, tworzenie własnych poleceń, itp. Dzięki temu krzywa nauki jest prostu przyjemniejsza. Nie musimy gdzieś po YouTube szukać informacji o ekosystemie frameworka, co bez wątpienia może być dużym ułatwieniem.
Niestety niski próg wejścia niesie ze sobą pewne konsekwencje – łatwo jest nabrać wrażenia, że po przerobieniu jednego kursu na Udemy jesteśmy w stanie tworzyć zaawansowane systemy. A Laravel oferuje dużą elastyczność, co akurat według mnie jest pewną wadą, ale jednocześnie dzięki temu jest łatwiejszy. Efektem często jest kod spaghetti, który bardzo ciężko jest później rozwijać.
Podsumowując – Laravel jest prosty w nauce, przyjemnie się w nim programuje, ale tworzenie jakościowych rozwiązań, to już zupełnie inna bajka.
Model – View – Controller
Laravel operuje na modelu MVC, który jest raczej standardem, i możesz go spotkać w większości innych frameworków. Warto sobie jednak powiedzieć, czym on w zasadzie jest. Żeby sobie to lepiej zobrazować, spójrz na poniższą grafikę.
Widok – mówiąc najogólniej jest to warstwa wizualna strony – to co widzisz po wejściu na daną witrynę. Laravel. Jako programista możesz wewnątrz widoków wyświetlać wartości zmiennych, używać pętli do wyświetlania postów z bazy danych, itp. Laravel jako, tzw. blade do budowy widoków, które znacznie upraszczają ten proces. W mojej ocenie są one bardzo wygodne. Zobaczmy na fragment przykładowego blade (jest to tylko kod pokazowy, który mniej więcej pokazuje jak wygląda tworzenie widoków):
@if(isset($comments) && $comments->count > 0)
@foreach($comments as $comment)
<div class="comment">
<div>{{$comment->description}}</div>
</div>
@endforeach
@else
<div class="error">Brak komentarzy do wyświetlenia</div>
@endifOczywiście nie ma też problemu z dzieleniem widoków na mniejsze części.
Controller – controllery służą do kontrolowania różnych procesów wewnątrz aplikacji. Może to być wyświetlenie widoku, zapisanie czegoś do bazy danych, itp. Mówiąc najprościej – wchodząc pod jakiś adres url, uruchamiana jest odpowiednia metoda controllera, która odpala widok z odpowiednimi zmiennymi. Jeśli chcemy zapisać jakąś informację do bazy danych, uruchamiamy kolejną metodę controllera, która przy wykorzystaniu modelu (o czym za chwilę), zapisuje dane w bazie danych. To w controllerze możemy przeprowadzać też proces validacji danych, i możemy w nim umieścić logikę biznesową. Tylko, że – to, że możemy, nie oznacza, że powinniśmy. Validację możemy przenieść na zewnątrz do request, a logikę biznesową do serviców. Sam controller powinien raczej zajmować się kontrolowaniem tego co jest uruchamiane, albo jakie operacje będą wykonywane na bazie danych.
Model – modele reprezentują bazę danych. Są odpowiedzialne za interakcje z bazą danych i wykonywaniem na niej różnych operacji. Posługując się modelami możemy stworzyć nowy record w bazie danych, usunąć go, albo wyświetlić wszystkie recordy spełniające określone kryteria. To właśnie w modelach możemy też definiować relacje, ale możemy też sterować tym, które kolumny będą wyświetlane, dzięki czemu nasza praca będzie dużo łatwiejsza.
Taki podział rozdziela aplikację na warstwy, co jest ogromnym ułatwieniem i pozwala zachować względny porządek w kodzie.
Laravel pozwala błyskawicznie rozpocząć pracę nad nowym projektem
Spośród wszystkich technologii, z którymi pracowałem, to właśnie Laravel pozwala najszybciej zacząć pracować nad nowym projektem. Mam tutaj na myśli głównie pracę w środowisku Dockera. Po ściągnięciu projektu, wpisujesz tylko jedno polecenie, które w zasadzie buduje całe Twoje środowisko:
./vendor/bin/sail up //ewentualnie sail up, jeśli stworzysz odpowiedni aliasJest to w zasadzie pełne środowisko, które ma wszystko, co jest Ci potrzebne do pracy, łącznie chociażby z obsługą maila. Oczywiście faktycznie nie wysyłamy nigdzie maila, a jedynie korzystamy z MailHug, który jest narzędziem wykorzystywanym do testowania wysyłania maili. Dodatkowo Laravel posiada fajne Starter Kity, takie jak chociażby Breeze, która pozwalają tworzyć aplikacje full-stack przy użyciu Laravela, i np. Reacta, albo Vue. Od razu dostajesz cały system logowania i rejestracji, a dzięki Inertia dużo łatwiej jest taką aplikację tworzyć… albo przynajmniej szybciej.
Ma on swoje wady, ponieważ tworzymy wtedy monolit, więc jeśli chcemy stworzyć API z którego będzie korzystać, np. aplikacja napisana w React i dodatkowo jeszcze aplikacja mobilna, to raczej nie jest to technologia dla nas.
Z drugiej jednak strony, jeśli tworzymy aplikację pokazową, albo jakąś małą aplikację na własne potrzeby, albo MVP, to jest to rozwiązanie wręcz idealne.
I oczywiście można powiedzieć, że chociażby Django też umożliwia szybkie rozpoczęcie pracy, bo nie dość, że aplikację uruchomimy równie łatwo, to jeszcze dostajemy bardzo wygodny panel admina, który oszczędza nam masę pracy. I oczywiście to jest prawda, ale gdybym chciał na szybko stworzyć aplikację z wykorzystaniem Reacta, jeszcze jakąś tam obsługą maili, to wydaje mi się, że to właśnie Laravel pozwoliłby mi oszczędzić najwięcej czasu. Tym bardziej, że Django też zazwyczaj trzeba lekko dokonfigurować.
Struktura projektu Laravela vs inne frameworki
Niestety tutaj mam pewne zastrzeżenia odnośnie Laravela. Niestety projekty zazwyczaj są brudne już na samym starcie, zwłaszcza jeśli porównamy strukturę tego frameworka, chociażby z Django, czy NestJS. Owszem, to są inne języki programowania, ale w tym momencie patrzę na nie pod kątem dobrania technologii backendowej. W Laravelu mamy logiczny podział na controllery, modele, migracje, seedery, itp. co sprawdza się całkiem fajnie przy mniejszych projektach. Przy większych, trzeba odpowiednio zaplanować tworzenie aplikacji, żeby nie zrobić bałaganu.
A jak to wygląda w innych frameworkach? Przykładowo – tworząc aplikację w Django, mogę stworzyć wewnątrz projektu oddzielny moduł (aplikację) dotyczący zamówień, danych klientów, itp. Każdy z tych modułów posiada własny controller, czy model (mała uwaga – wiem, że Django operuje innym nazewnictwem, ale jest to artykuł dla osób początkujących i nie chcę tutaj mieszać tym, że widok w Laravelu i Django to dwie zupełnie różne rzeczy. Dlatego posługuję się wyłącznie nomenklaturą Laravela). Takie podejście wymaga co prawda początkowego zastanowienia się jak podzielić aplikację, ale w dłuższej perspektywie daje bardziej schludny kod. Podobnie jest z NestJS, który nie tylko proponuje nam podobny podział aplikacji, ale zachęca nas do przenoszenia logiki biznesowej poza controller – do serviców. Co prawda Laravel też to umożliwia, i zachęcam trzymanie porządku w controllerach, ale z doświadczenia wiem, że większość programistów Laravela ładuje całą logikę biznesową do metod controllera i w ten sposób powstają potworki, często na kilkaset linii kodu. Właśnie przez inną strukturę aplikacji, w mojej ocenie nieco trudniej jest utrzymać schludny kod.
Praca z bazą danych – ORM i relacje
Praca z bazą danych jest dosyć prosta. Chcąc utworzyć nową tabelę, możemy wydać polecenie
php artisan make:model Customer -mI tutaj zatrzymajmy się na chwilę. Powyższe polecenie stworzy model o nazwie Customer, oraz odpowiednią migrację, kóra może wyglądać następująco
public function up(): void
{
Schema::create('customers', function (Blueprint $table) {
$table->id();
$table->string('firstname');
$table->string('lastname');
$table->boolean('active')->default(1);
$table->text('description')->nullable();
$table->timestamps();
});
}Jak widać, migracja pozwala stworzyć tabelę w bazie danych w bez porównania prostszy sposób. Chcąc dodać nowy record do bazy danych, albo chcąc wypisać recordy, odwołujemy się do modelu, np.
// Wyświetl pierwszy record
$customer = Customer::first();
// wyświetl wszystkie recordy
$customers = Customer::all();
// wyświetl aktywnych klientów
$activeCustomers = Customer::where('active', 1)->get();
/*
wyświetl aktywnych klientów,
którzy zostali dodani do bazy w 2023 roku
*/
$newCustomers = Customer::where('active', 1)
->whereYear('created_at', 2023)
->get();
// wybierz klienta o konkretnym id
$myCustomer = Customer::find(1);jak widać tworzenia prostych zapytań jest wręcz bajecznie proste. Równie prosto wypada tworzenie relacji pomiędzy tabelami jest równie proste, i robi się to bezpośrednio w modelu. Często wymaga to też odpowiedniego przygotowania tabel, co jest oczywiste. Nie chcę tutaj jednak uczyć Ciebie samego Laravela, a jedynie pokazać z czym to się je.
PHP Artisan
Jak pisałem wyżej, Laravel udostępnia fajne CLI, za pomocą którego możemy wykonać wiele podstawowych, i powtarzalnych czynności – stworzenie controllera, modelu, seedera, czy zmigrowanie bazy danych. O ile większość współczesnych frameworków udostępnia jakieś CLI, to uważam, że to od Laravela zostało całkiem fajnie pomyślane. Dodatkowo możemy tworzyć własne polecenia, które wykonują określone czynności. Są też bardzo łatwe do zapamiętania. Zaczynają się od php artisan, albo od sail artisan, jeśli korzystamy z Dockera.
Tinker – pomocnik do pracy z bazami danych
Innym tematem jest też Tinker. Jest to konsolowe narzędzie do pracy z bazą danych w środowisku Laravela. Oczywiście żeby sobie coś na szybko podejrzeć w bazie danych, możemy skorzystać z MYSQL WorkBrench, czy innego, alternatywnego narzędzia. Tinker ma jednak tę zaletę, że działa w środowisku Laravela, więc operacje wykonujesz dokładnie tak samo jak w Laravelu – odwołując się do modeli, a jeśli mamy jakąś relację, to także bez problemu możemy ją wyświetlić.
Wesoła twórczość w Laravelu
Laravel posiada całkiem dużą elastyczność, co może być zaletą, ale według mnie jest pewną wadą. Pisałem już o tym, że programista sam musi zatroszczyć się o to, żeby struktura jego projektu była klarowna, oraz o to, żeby zachować porządek w controllerze, a jest duża pokusa, żeby narobić tam bałaganu. Przykładów możemy podać jednak więcej.
Weźmy za przykład validację danych, czyli jedną z podstawowych funkcjonalności backendowego frameworka. Możemy to zrobić na kilka sposobów. Możemy chociażby validować pola za pomocą $request:
$validated = $request->validate([
'title' => 'required|unique:posts|max:255',
'description' => 'required|min:100',
]);Alternatywnie możemy chociażby stworzyć własną instancję, np. w takie sposób:
$validator = Validator::make($request->all(), [
'title' => 'required|unique:posts|max:255',
'description' => 'required|min:100',
]);Albo skorzystać z mojej ulubionej metody, czyli przeniesienie całej validacji do osobnego pliku Mógłby on wyglądać następująco
class PostStoreRequest extends FormRequest
{
/**
* Determine if the user is authorized to make this request.
*/
public function authorize(): bool
{
return true;
}
/**
* Get the validation rules that apply to the request.
*
* @return array<string, \Illuminate\Contracts\Validation\Rule|array|string>
*/
public function rules(): array
{
return [
'title' => 'required|unique:posts|max:255',
'description' => 'required|min:100',
];
}
}I zanim powiedzie, że ostatnia metoda jest najbardziej skomplikowana, to powiem tylko, że cały ten plik jest generowany za pomocą omawianego wcześniej CLI, a w tym konkretnym przypadku edytuję tylko rules().
No ale w czym problem, możesz zapytać? Każdy sobie wybierze metodę, która będzie dla niego najlepsza i wszyscy będą zadowoleni. Niestety tak się składa, że miałem okazję wchodzić do projektów, nad którymi pracowało już wcześniej kilku programistów, a te projekty nie były mocno nadzorowane od strony technicznej, więc każdy to robił trochę po swojemu. Uwierzcie mi – odnalezienie się w taki projekcie nie jest łatwe, a czym więcej opcji mamy na stole, tym potencjalnie większe ryzyko narobienia syfu.
Jest jeszcze jedno ryzyko – osoby dopiero zaczynające mogą czuć się zagubione. Bo która opcja jest najlepsza? Ja z doświadczenia wiem, że najbardziej wolę opcję ostatnią, ale osoba początkująca takiego rozeznania nie ma i może czuć się zagubiona.
Zwróć uwagę, że mówiliśmy tylko o validacji – a takich rzeczy jest na prawdę dużo!
Inny przykład, to gdzie zastosować middleware, jak ogarną logikę biznesową, jak uporządkować routing.
Wdrażanie aplikacji
Laravel jest napisany w PHP, więc w zasadzie możesz taką aplikację wdrożyć na każdym hostingu współdzielonym. O ile coraz więcej hostingów umożliwia hostowanie aplikacji napisanych w JavaScript, czy Python, o tyle dalej język PHP jest najpopularniejszym językiem tworzenia backendu stron internetowych. Dlatego tworząc stronę dla klienta, albo tworząc oprogramowanie open source, mniej zaawansowanym użytkownikom łatwiej będzie wdrożyć aplikację napisaną w PHP.
W jakich projektach Laravel sprawdzi się najlepiej?
Wachlarz zastosowań Laravela jest bardzo szeroki. Z pewnością byłby jednym z pierwszych wyborów przy tworzeniu CMSa, zwłaszcza gdybym chciał go udostępnić innym użytkownikom, także mniej technicznym. Poza tym – wszelkiej maści narzędzia do wewnętrznego użytku firmy, szybkie i małe projekty, MVP, może nawet rozważyłbym budowę niewielkiego sklepu internetowego.
Sprawdzi się też do tworzenia API dla innych aplikacji, np. mobilnych, a prywatnie tworzę w nim coś w rodzaju portalu społecznościowego, ale jest to projekt poboczny. W gruncie rzeczy większość projektów można stworzyć w Laravel. Prawdopodobnie zastanowiłbym się przy bardzo dużych projektach. Gdybym musiał użyć baz noSQL to też wybrałbym inną opcję.
Podsumowanie
Laravel do świetny framework, którego na prawdę warto się uczyć. Ma niski próg wejścia, oferuje pełne środowisko do pracy, dzięki czemu można bardzo szybko rozpocząć prace nad nowym projektem. Sprawdzi się przy większości projektów, ale niestety czasami ciężko jest utrzymać kod w dobrej kondycji. Dlatego nie jestem przekonany, czy jest to najlepsze rozwiązanie do pracy w dużych zespołach programistów.