Blog | Má zkušenost s Laravelem

Má zkušenost s Laravelem

Za posledních 8 let jsem žádné dva projekty nenapsal v naprosto stejném setu technologií. Což je perfektní, když se chce člověk hodně naučit, ale docela špatné, když chce člověk dosáhnout velké produktivity.

Já ale pro Flexianu hledám devstack, na kterém právě těch projektů postavíme plno.

Už jsme zkusili na reálných projektech:

  • Clojure (Luminus) + Polymer
  • Clojure (Luminus) + Hiccup (server-side šablonovací knihovna, žádný JS)
  • Lumen (microframework nad Laravelem) + Dingo (pomocník na psaní REST API) + React + Redux
  • Laravel + React + Redux

Laravel jsme zkusili proto, že vychází z Lumenu, který je osekanou verzí Laravelu (spousta namespaces je kvůli výkonu vyházených) proto, že:

  • se hodily funkčnosti, které jsou v Laravelu, ale do Lumenu se nedostaly (různé funkčnosti artisana atd.)
  • ne všechny obrazovky musí být SPA, mnohdy se jedná o administraci číselníků, kde stačí upravený nagenerovaný scaffolding

No a už nějakou dobu na Laravelu vyvíjím a tady je má zkušenost:

Nelíbí se mi adresářová struktura, v posledních letech jsem si zvykl spojovat namespaces podle business částí, ne podle toho, jestli chci zrovna dělat controllery, nebo modely. A tak prakticky v rootu aplikace nebo v podsložce src mívám složky typu reporting, users, warehouse, manufacturing…

Laravel navíc zvláštně rozestrkal soubory tak, že třeba controllery jsou v app/Http/Con­trollers, modely v app/Models, views v resources/Views, routy v routes/, místo složky temp mám složku storage.

Nelíbí se mi nadužívání static, kterým je Laravel prolezlý. Ano, jak tak adresářová struktura, tak i to static, by šlo nějak napravit. Laravel prý má DI, ale zároveň všechen kód, který k Laravelu uvidíte, bude používat static, v dokumentaci najdete static.

A jak sám říkám, že framework není knihovna, ale styl práce. No tak „Laravel-way“ je staticem prolezlý. Já se definici vlastních statických metod vyhýbám a vlastně tam, kde píšu OOP, tak nepoužívám static vůbec.

Laravel používá traity, static, věšení se na eventy kdekoliv (koukněte se, jak se má dělat v Laravelu obdoba beforeSafe), tedy nevysledovatelně. Výsledkem je kód, který nápadně připomíná Rails 2. Vlastně je to takový Zend Framework 1 říznutý Railsy 2.

V podstatě on ten kód je hezký takovým tím Ruby způsobem, kdy udělám jakoukoliv magii, aby to vypadalo elegantně. Přitom je to úplně zbytečné.

  • nač v migracích volat statickou metodu, které předávám anonymní funkci? Nestačila by metoda $this->getTableDefi­nition() nebo něco takového?
  • proč si hrát na repository např. v knihovně InfyOm, když Eloquent je obyčejný ActiveRecord?

Controllery jsou skoro identické s ZF1. Vlastně by stačila relativně tenká fasáda a controllery v Laravelu by byly plně kompatibilní se Zendem. Akorát proč flashMessage je zase statická metoda? A redirect, render view obyčejná funkce?

Laravel v podstatě ignoruje všechny objektové best practices, ale nedělá ten krok se na objekty úplně vykašlat. Někdy se objekty použijí správně, jindy jsou jen další namespace na funkce. Laravel-way je návrat někam k Nette 0.x.

Hledal jsem nejlepší generátor scaffoldingu a použil jsem ten od InfyOm, který vypadá nejpropracovaněji. A přesto je spíš slabší.

  • ano, umí to nagenerovat REST API (pozitivní)
  • kód vypadá relativně čistě (není horší než to, co je podle Laravel dokumentace běžný způsob psaní)
  • šablona je v Bootstrapu, to je pozitivní, byť není sémantická
  • použitý font neumí české znaky
  • hlavně – vygenerované inputy jsou obvykle jen inputy (trocha chytristiky je třeba u password, nebo booleanu), ale neumí to např. combobox z relace, M:N vazby, to už jsou dnešní knihovny na scaffolding dál
  • nemyslí se na vícejazyčnost

Na Laravelu se mi líbí, že má migrace a seeder. To je přesně věc, kterou nechci pořád dokolečka integrovat a myslím si, že by měla být součástí frameworku.

V Laravelu se zjevně extrémně myslí na rozšiřitelnost. Všude jsou middlewary, providery, předpřipravené traity.

Zajímavé je, že se v Laravelu poměrně rychle programuje. Produktivitou práce bych to přirovnal k Rails nebo CakePHP, tedy frameworky, které jdou cestou Convention over Configuration. Na nagenerování REST API a jednoduché administrace bych to použil znovu (a nebo bych použil CakePHP, protože ty frameworky jsou si velmi podobné). Projekt, s kterým bych měl spojit svůj život na několik let, bych napsal v něčem jiném. Popularita Laravelu mi naprosto uniká, výhody toho frameworku jsou v pozlátkové estetice a rozšiřitelnosti a v tom frameworku není nic, co bych neviděl jinde před 10 lety, kdy jsem se o frameworky začal zajímat.

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích