Jan Mikoláš
Slovník pojmů
Laravel
Laravel spojuje běžné potřeby PHP webové aplikace do jednoho frameworku s výraznými konvencemi, aniž by za vývojáře rozhodl o obchodních pravidlech systému.
Stručná definice
Framework pro HTTP aplikace, konzolové úlohy i asynchronní zpracování.
Laravel poskytuje strukturu pro webové aplikace, administrace a backendová API. Obsahuje routing, controllery, middleware, validaci, autentizaci, autorizaci, práci s databází, fronty, cache, příkazovou řádku a testovací podporu. Díky společným konvencím se tým může soustředit více na konkrétní případ použití než na opakované skládání technického základu.
Framework je zároveň ekosystém. Vedle jádra existují nástroje pro fronty, monitoring, autentizaci nebo lokální vývoj. Neznamená to ale, že každá Laravel aplikace musí používat všechny dostupné části ani že konvence frameworku automaticky vytvoří správně navržený systém.
Použití
Kde Laravel dává praktický smysl
Laravel se používá pro aplikace, které potřebují rychle dodat funkční HTTP vrstvu a současně zvládnout databázi, oprávnění nebo práci na pozadí.
- interní systémy, administrační rozhraní a zákaznické portály
- backendové API pro webový nebo mobilní klient
- e-shopy, objednávkové procesy a integrace s externími službami
- importy dat, notifikace, reporty a dávkové úlohy
- aplikace s frontami, cache a dlouhodobě běžícími workery
Praktický příklad
Plánovaný import objednávek s Redis zámkem
E-shop potřebuje každých pět minut načíst nové objednávky z marketplace. Laravel scheduler vyvolá příkaz nebo job, který nejprve získá zámek v centrální cache. Pokud předchozí běh stále pracuje, další spuštění nezačne druhý souběžný import.
Samotné naplánování nestačí: server musí pravidelně spouštět Laravel scheduler a frontový job musí zpracovat worker. Jestliže při timeoutu není jasné, zda vzdálené API objednávku již přijalo, import ukládá externí identifikátor pod unikátním databázovým constraintem a volí idempotentní postup. Redis zámek omezuje souběh; ochranu proti duplicitám tvoří až business pravidlo a databáze.
Jak funguje
Od HTTP požadavku k výsledku
Konkrétní aplikace může mít více vrstev, základní průchod požadavku ale vypadá podobně.
- Route Routing podle URL a HTTP metody vybere controller nebo jiný handler.
- Middleware Před a po handleru může řešit například autentizaci, autorizaci, rate limiting, locale nebo CSRF ochranu.
- Validace a případ použití Controller nebo Form Request ověří vstup a předá obchodní práci aplikační službě či use case.
- Data a práce na pozadí Aplikace čte nebo ukládá data, případně vyvolá událost či předá delší úlohu do fronty.
- Odpověď Vrátí HTML, přesměrování nebo strukturovanou API odpověď včetně konzistentního chybového stavu.
Důležité části
Co Laravel poskytuje v běžné aplikaci
Jednotlivé části řeší technické obavy. Obchodní pravidla, hranice modulů a rozhodnutí o datech zůstávají odpovědností týmu.
Routing, controllery a middleware
Route určí vstupní bod, controller překládá HTTP požadavek na práci aplikace a middleware řeší opakované HTTP obavy. Controller nemá být automatickým místem pro pravidla cen, skladu nebo importů.
Service container a dependency injection
Container vytváří třídy a umí doplnit jejich závislosti. Konkrétní třídy dokáže často sestavit automaticky; rozhraní nebo kontextově odlišné implementace vyžadují explicitní binding.
Validace, autentizace a autorizace
Validace řeší tvar a přípustnost vstupu. Autentizace určuje identitu uživatele, autorizace pak oprávnění k akci nebo datům. Ani jedna vrstva nenahrazuje vlastní obchodní pravidla.
Eloquent, migrace a seedery
Eloquent mapuje databázové tabulky na modely s aktivními operacemi nad záznamem. Migrace verzují změny schématu a seedery připravují kontrolovaná vývojová či testovací data.
Artisan, fronty a scheduler
Artisan spouští příkazy pro importy a údržbu. Fronta předá delší práci workeru; scheduler určuje, kdy má být úloha vyvolána. Worker i scheduler potřebují skutečný provozní proces, monitoring a postup při nasazení.
Vztah k dalším nástrojům
Konvence frameworku nejsou celá architektura
Laravel lze používat přímočaře, ale u složitějších částí je důležité vědět, co která zkratka skrývá.
- Eloquent a Doctrine ORM
- Eloquent používá Active Record přístup: model typicky reprezentuje záznam i operace nad ním. Doctrine ORM častěji pracuje jako Data Mapper s odděleným Entity Managerem a repository. Jeden přístup není automaticky lepší; liší se mírou propojení modelu s persistencí.
- Facades a dependency injection
- Facade poskytuje staticky vypadající přístup ke službě dostupné přes Laravel container. Constructor injection naopak ukazuje závislosti třídy přímo v jejím rozhraní. Facade může být praktická na frameworkové hranici, ale v obchodní logice snadno skryje, na čem třída závisí.
- Události, listenery a fronty
- Událost oznamuje, že se něco stalo; listener na ni může reagovat. Teprve listener zařazený do fronty nebo job předaný do fronty vyžaduje worker. Pro retry, timeouty a duplicity musí být obsluha úlohy bezpečná i při opakování.
- Cache a Redis
- Laravel nabízí jednotné rozhraní pro cache. Redis může sloužit jako cache, frontový backend nebo úložiště zámků, ale cache není zdroj pravdy a vyžaduje promyšlenou expiraci a invalidaci.
- Testování
- Laravel poskytuje pomocníky pro HTTP, databázové a konzolové testy. Samotné testy mohou běžet nad PHPUnit nebo Pest; frameworkové helpery neurčují, zda jde o unit, integrační či funkční test.
Výhody a omezení
Produktivita funguje nejlépe s čitelnými hranicemi
Přínosy
- sjednocené konvence pro HTTP aplikaci, databázi, CLI i práci na pozadí
- rychlý základ pro validaci, oprávnění, migrace, cache a testování
- service container umožňuje předávat závislosti bez ručního skládání každého vstupního bodu
- funkce pro fronty a scheduler pokrývají běžné provozní scénáře
Na co pozor
- business logika v controllerech, Eloquent modelech nebo jobech může rychle zhoršit orientaci v systému
- facades mohou u rozsáhlejší obchodní logiky skrýt závislosti, které by měly být viditelné
- scheduler nenahrazuje cron, process manager ani běžící worker
- zámek proti souběhu neřeší sám o sobě idempotenci platby nebo importu
- příliš mnoho vlastních abstrakcí může odstranit výhodu jednoduchých frameworkových konvencí
Hranice použití
Framework má podporovat řešení, ne diktovat všechny vrstvy.
Laravel se hodí pro aplikace, které potřebují rozumně rychle vytvořit webovou nebo API vrstvu a těžit z integrovaných nástrojů. U dlouhodobě rozvíjeného systému je vhodné nechat framework na hranicích: HTTP, CLI, databázovou infrastrukturu nebo workery, zatímco důležité obchodní případy zůstávají čitelné a testovatelné samostatně.
Frameworky Symfony, Laravel a Nette nelze poctivě seřadit od nejlepšího po nejhorší. Liší se konvencemi, ekosystémem, zvyklostmi týmu, dostupnými balíčky i výchozím projektem. Volba má vycházet z potřeb aplikace, její údržby a schopnosti týmu dané nástroje provozovat.
Na co myslet
Laravel neodpovídá za provozní a doménová rozhodnutí
Před nasazením má smysl kontrolovat nejen frameworkový kód, ale především chování aplikace v reálných hranicích.
- nepřesouvat obchodní pravidla automaticky do controllerů, modelů ani jobů
- pro důležité akce rozlišit validaci vstupu, autorizaci a vlastní business pravidlo
- pro retry fronty a externích API navrhnout idempotentní zpracování
- správně provozovat a po deployi restartovat dlouhotrvající workery
- pro plánované úlohy definovat timeout, zámek, monitoring a postup při selhání
- spouštět testy, PHPStan a další kontroly v CI před mergem či nasazením
Časté otázky
Co je dobré o Laravelu vědět
Je Laravel vhodný jen pro malé aplikace?
Ne. Rozhodující je návrh a způsob údržby, ne samotná volba frameworku. Laravel lze použít pro malý interní nástroj i rozsáhlejší systém; u složitějších částí je důležité hlídat odpovědnosti, data a provozní hranice.
Je Eloquent totéž co Doctrine ORM?
Ne. Oba nástroje řeší práci s relačními daty, ale Eloquent je založený na Active Record přístupu, zatímco Doctrine ORM typicky používá Data Mapper a Entity Manager. Volba ovlivňuje hlavně podobu modelu a způsob práce s persistencí.
Jsou Laravel facades špatná praxe?
Ne samy o sobě. Jsou praktickým přístupem k frameworkovým službám a Laravel je umí v testech nahradit. U důležité aplikační logiky však constructor injection lépe ukáže skutečné závislosti třídy a omezuje skrytý globální přístup.
Spustí Laravel scheduler úlohu sám?
Ne. Scheduler pouze rozhoduje, která úloha je právě splatná. V produkci ho musí pravidelně spouštět například cron nebo spravovaný proces; frontové joby navíc potřebují samostatně běžící worker.
Zaručuje Laravel čistou architekturu?
Ne. Nabízí konvence a nástroje, ale nerozhodne, kam patří obchodní pravidlo, transakční hranice ani jaké závislosti jsou pro doménu přijatelné.
Jak Laravel zapadá do mé praxe
Laravel chci vedle PHP využívat pro specifické backendové úlohy.
Pro současné backendy používám hlavně Symfony. Laravel rozvíjím jako další nástroj pro projekty, kde dávají jeho konvence, Artisan, Eloquent nebo práce s frontami a schedulerem konkrétní smysl.