Bardzo dużo opowiadam Ci, jak wspaniały jest Laravel. Wiesz już pewnie, dlaczego warto zacząć pisać dedykowane aplikacje właśnie przy jego wykorzystaniu.
Jednak możesz przez to odnieść mylne wrażenie, że Laravel jest pozbawiony wad.
A to, oczywiście, nieprawda.
Wady Laravela widać gołym okiem. Nie ma ich wiele, jednak są wyraźne. Szczególnie gdy projekt zaczyna się rozrastać. Dzisiaj chciałbym krótko pokazać Ci, jakie bolączki wiążą się z wykorzystaniem Laravela.
Jakie są największe (często bardzo zasadne) zarzuty wobec tego frameworka…
Wszechobecne fasady
To chyba największy zarzut wobec Laravela.
Z jednej strony, mechanizm fasad mocno przyspiesza development kodu i pozwala Ci osiągnąć oczekiwane efekty znacznie szybciej.
Jednak, z drugiej strony, ma w sobie zaszyte niebezpieczeństwo ukrytych zależności. W ten sposób nieświadomie sprawiasz, że Twój kod jest wzajemnie powiązany i ciężko później podmienić/przetestować pewne fragmenty aplikacji.
Wygodnie jest użyć fasady (np. Storage) i uzyskać dostęp do przestrzeni przechowywania plików, jednak wtedy taki kod:
- przestaje być wygodnie testowalny
- wiążesz się z implementacją fasady dostarczaną przez Laravela
Alternatywą byłoby zadeklarowanie argumentu IStorage w metodzie i wstrzyknięcie obiektu przy wywołaniu metody (zgodnie z wzorcem Dependency Injection). Wtedy uzyskamy pełną kontrolę nad tym, co i gdzie jest wykorzystywane w naszym kodzie.
Do tego, możemy przygotować sobie klasę DummyStorage, która również będzie implementować interfejs IStorage i którą możemy wykorzystać do testów.
Wtedy podmiana tej klasy to zmiana jednego wpisu w konfiguracji.
Z wykorzystaniem fasady nie mamy w ogóle takiej możliwości.
Sprawia to, że tworzymy kod niższej jakości, jednak kosztem szybkości tworzenia aplikacji. Tak czy siak, warto być świadomym tego, z czego się korzysta.
Laravel nie wymusza na Tobie korzystania z jakiejkolwiek fasady! Ich użycie jest czysto opcjonalne, a wygoda ich użycia piekielnie do nich zachęca.
Eloquent ORM
Kolejny mechanizm, na którym przeciwnicy Laravela lubią wieszać psy.
Niby słusznie, choć znowu -> wszystko zależy od kontekstu!
Nie da się jednoznacznie stwierdzić, że dane podejście jest złe, nie znając pełnego kontekstu sytuacji.
Jednak do rzeczy. Dlaczego Eloquent ORM jest, w teorii, zły?
Dlatego, że łamie zasadę pojedynczej odpowiedzialności, czyli pierwszą z pięciu zasad ukrytych w akronimie SOLID. Mamy tu do czynienia z klasą modelu, który posiada bardzo wiele odpowiedzialności:
- przechowuje dane odpowiadające pojedynczemu rekordowi z tabeli,
- posiada logikę biznesową,
- potrafi sam siebie zapisać do bazy lub się z niej usunąć itp.
To wszystko sprawia, że zamiast trzech klas w dwóch różnych warstwach aplikacji, mamy to wszystko wymieszane w jednej klasie.
To dodatkowo sprawia, że w kontrolerze brakuje odwołania się do warstwy serwisów, które dopiero zejdą niżej do warstwy logiki biznesowej, poniżej dostępu do danych, repozytorium itd.. Za to najczęściej w kontrolerze mamy do czynienia już bezpośrednio z obiektem encji, co również jest niezgodne z pryncypiami programowania.
Jednak znowu pragnę przypomnieć, że to jest wada i zaleta w jednym.
Bo największą zaletą tego podejścia do pisania kodu jest niesamowita szybkość tworzenia aplikacji.
Alternatywą dla Eloquenta jest oczywiście Doctrine ORM. Doctrine działa na nieco innej zasadzie, a mianowicie jedynie odwzorowuje dane z tabeli do obiektu w PHP i nic poza tym. Jest zbiorem właściwości (jak id, name, email itp.), których zapisem i odczytem z bazy zajmuje się już zupełnie osobny byt (np. EntityManager).
Znowu, w Laravelu nie jesteś zmuszony do korzystania z Eloquenta. Możesz równie dobrze dodać sobie paczkę Doctrine przez composera i z niej korzystać.
Pytanie tylko, po co korzystać z Laravela, jeśli nie dla jego szybkości tworzenia aplikacji? Tę szybkość daje m. in. Eloquent, który stanowi trzon Laravela.
Ważne, by być świadomym mechanizmów, z których się korzysta oraz zagrożeń, które ze sobą niosą.
Szybkość działania aplikacji
Żeby nie przynudzać, ostatn minus ująłem w kategorii: szybkość działania aplikacji.
Co przez to rozumiem?
Przez to, że w Laravelu krążą ogromne obiekty globalne (jak App czy Route) oraz że nie możemy łatwo wyłączyć/wyciąć/pozbyć się fragmentów frameworka, z których i tak nie chcemy skorzystać, czas przetwarzania jednego żądania trwa zwykle dłużej niż w np. w Symfony.
To jest bolączka każdego frameworka.
Zawsze kod wykonywany w czystym PHP bez użycia frameworka będzie najszybszy.
Jednak Symfony framework zbudowany jest modularnie. Możesz dodawać/usuwać moduły, które uznasz za zasadne.
W przypadku Laravela albo bierzesz całość, albo nic.
Oczywiście, warto tutaj wspomnieć o Lumenie, który został wydzielony jako dedykowany fragment Laravela typowo pod tworzenie API i który narzutu ma znacznie mniej.
Jednak Laravel, przez masę funkcjonalności domyślnej, wykonuje się nieco wolniej niż pozostałe frameworki.
Zazwyczaj ta różnica w prędkości działania nie jest istotna, jednak trzeba to jasno wskazać jako wadę.
Dodatkowo, możesz przyspieszyć działanie Twoich stron np. przez użycie mechanizmu Cache, do którego Laravel również ma świetnie przygotowane narzędzia.
Czy zatem Laravel jest dobrym wyborem?
Mając na uwadze te wszystkie wady Laravela, wciąż jest on moim ulubionym frameworkiem.
Oczywiście, wybór frameworka i branie pod uwagę jego zalet/wad zależy od kontekstu i stopnia skomplikowania tworzonej aplikacji. Dla bardzo rozbudowanej aplikacji o wysokim stopniu skomplikowania i mocno customowym podejściu do funkcjonalności, korzystanie z Laravela byłoby nieefektywne.
Nie mówię tutaj, że nie dałoby się napisać takiej aplikacji. Jednak wybór Symfony do tego celu miałby dużo więcej sensu.
Jednak, jeśli miałbym tworzyć bardzo rozbudowaną, skomplikowaną aplikację krytyczną dla biznesu, rozważyłbym czy w ogóle wybór PHP to dobra decyzja. O ile byłoby to jak najbardziej możliwe, by taką aplikację napisać przy pomocy PHP, znacznie łatwiej byłoby ją stworzyć i utrzymać np. w ASP.net core.
Dlatego, czy to frameworki, czy dany język programowania, czy szerzej – jakąkolwiek technologię, powinieneś zawsze dobierać do konkretnej sytuacji.
Tak jak młotka używasz do wbicia gwoździa, a śrubokręta do wkręcenia śrubki. Dobór odpowiedniego narzędzia to fundamentalny klucz do sukcesu.
Możesz wbić gwoździa śrubokrętem, tylko po co 🙂 młotkiem będzie znacznie łatwiej i szybciej.
Do czego zatem Laravel nadaje się najlepiej?
Jednozdaniowa odpowiedź: „Laravel jest najlepszy do szybkiego prototypowania aplikacji oraz do standardowych aplikacji typu CRUD wzbogaconych o uwierzytelnianie użytkownika.”
Aplikacje w Laravelu tworzy się piekielnie szybko, a jeśli trzyma się podstawowych zasad, kod da się utrzymać w ryzach.
Z racji tego, że tak wiele startupów upada a część jest przejmowanych, Twój kod i tak prawdopodobnie wyląduje w koszu. Dlatego, z punktu widzenia biznesowego, nie opłaca się przywiązywać zbyt wielkiej wagi do pisania idealnego kodu od samego startu.
Pamiętaj, że done is always better than perfect.
A jeśli jakimś cudem uda Ci się projekt doprowadzić do tego stopnia, że Laravel będzie Cię ograniczał pod kątem wydajności, to znajdziesz fundusze na przepisanie kodu od zera w dedykowanej architekturze.
Tyle ode mnie, dzięki i wszystkiego dobrego!