Jak dělám frontend backendově

Trendem je řešit všechno frontendově a AI to ještě podporuje. Backend a PHP ale mrtvé nejsou. V článku podle mé přednášky shrnuji rizika frontendově těžkých aplikací a výhody backendového přístupu se Symfony.

Už před nástupem AI byl mezi programátory patrný trend řešit prakticky všechno frontendově. S rozmachem umělé inteligence se tento sklon ještě prohloubil – když si dnes necháte poradit od AI, velmi často vám automaticky nabídne frontendovou technologii, i tam, kde by klasické backendové řešení dávalo mnohem větší smysl.

Backend a technologie jako PHP přitom zdaleka nejsou mrtvé a v řadě situací jsou stále tou nejlepší volbou. A pokud pracujete na existujícím projektu, už vůbec nedává smysl přepisovat aplikaci do programovacího jazyka a frameworku, který je aktuálně v módě. A proto je třeba připomenout tímto článkem, že vývoj aplikace na převážně backendových technologiích má stále smysl.

Typická aplikace a co od ní očekáváme

Představme si typickou aplikaci, která řeší reálnou potřebu uživatele – například digitální řízení nějakého komplexního výrobního procesu. Taková aplikace musí pokrýt spoustu okrajových případů, mít konzistentně uložená a dobře provázaná data a zároveň musí být uživatelsky přívětivá, ať už ji používá ředitel nebo dělník ve výrobě.

Díky AI dnes vzniká čím dál víc aplikací, které jsou „frontend, frontend, frontend“, jako by backend prakticky přestal existovat. Já se ale ve své praxi typicky setkávám s existujícími PHP aplikacemi, které nejsou postavené na nejnovějších technologiích – a nemám důvod je násilně přepisovat do jiného stacku. V konečném důsledku by to bylo časově i finančně neefektivní. A pokud máte hodně starou PHP aplikaci, kterou už nechcete dál rozvíjet, tak i stará PHP aplikace se dá provozovat. Jak na to popisuji v článku Jak provozovat staré PHP aplikace. Samozřejmě pokud aplikaci chcete dál rozvíjet, je nutné si najít budget na upgrade nebo dokonce postupný přepis.

Kdy dává smysl volit frontendové technologie?

Frontendové technologie samozřejmě mají své místo a v mnoha případech jsou nezbytné. Typicky jde o situace, kdy:

• aplikace vyžaduje velkou interaktivitu
• je potřeba komunikovat s jedním nebo dokonce více API (jak takové API navrhovat a implementovat, najdete v článku REST API Platform)
• backend je řešený úplně jinou službou a klasická databáze chybí
• chcete ušetřit díky sdílení částí kódu mezi frontendem a backendem
• nad existujícím API chcete postavit více klientů. Například webovou, mobilní i desktopovou aplikaci
• potřebujete dynamické výpočty, u kterých komunikace s backendem není vůbec nutná

Rizika frontendově realizovaných aplikací

Přesun logiky na frontend s sebou nese řadu rizik, se kterými se v praxi opakovaně setkávám. Všechna jsou řešitelná, ale lepší je jim předcházet tak, aby programátor vůbec nemusel myslet na to, že tam takový problém může nastat a tedy že ho má řešit.

Únik know-how

Pokud je business logika – například specifický výpočet ceny – umístěná ve frontendu, kdokoliv trochu zkušený ve čtení kódu si ji může v prohlížeči prohlédnout a odhalit tak citlivé know-how firmy.

Zbytečně mnoho requestů

Setkal jsem se s e-shopem, kde se každá položka načítala samostatným JavaScriptovým dotazem. Zajímalo mě víc položek, tak jsem je otevřel v deseti oknech – a vygenerovalo se tolik requestů. Následně mě server odřízl. Jako zákazník jsem měl následně eshop nedostupný.

Nechráněná API

Vypadá to komicky, ale poměrně často se stává, že API endpointy nejsou chráněné přihlášením, tokenem nebo jiným způsobem. Osobně jsem se s tím setkal! Například při jedné optimalizaci výkonu se ukázalo, že data na URL adresách API jsou volně dostupné bez přihlášení a servírují veškerá data. Ano frontend zobrazí jen část, ale do prohlížeče se pošle mnohem víc – třeba celá databáze uživatelů s osobními údaji, ke kterým by se bez přihlášení a správného oprávnění neměl dostat vůbec nikdo. A právě proto je u frontendových technologií potřeba klást mnohem větší důraz na webovou bezpečnost.

Fragmentace technologií

Frontendových frameworků je obrovské množství a často se mění. S každým novým projektem se tak programátor musí učit nový framework – a je otázka, zda se do toho vyplatí investovat čas. Osobně mám mezi frontendovými technologiemi nejraději SvelteJS. A vždy platí méně technologií je lépe.

Kód generovaný AI

AI dnes generuje obrovské množství kódu, jehož bezpečnostní kvalita bývá přinejmenším sporná. Ten kód ale musí někdo udržovat. Čím méně kódu je, a čím víc je ve výchozím stavu bezpečný, tím lépe.

Backendový přístup: PHP a Symfony

PHP aplikace, které se ke mně dostanou, nepřepisuji – naučím se technologii, která tam je, a stavím na ní. Nepotřebuji být za každou cenu „moderní“, chci být flexibilní a mít v projektu co nejméně kódu, protože to je podle mě známka lepšího projektu.

Často pracuji s PHP frameworkem Symfony nebo s Nette. PHP se za poslední roky výrazně posunulo a dnes je to za mě už dobrý programovací jazyk se skvělým ekosystémem jako je například PHPStan, PHPUnit, kvalitní knihovny. Nové aplikace vznikají podle moderních standardů, takže je snadné se v nich zorientovat. A starší projekty lze na novější verze PHP převést nástrojem Rector, viz upgrade PHP pomocí Rectoru nebo použít AI a vibecoding.

Když maximum logiky řeším backendově, nemusím řešit samostatné API a všechny problémy, které s API souvisí – včetně autentizace, autorizace a bezpečnosti. Méně práce ve výchozím stavu znamená více bezpečnosti. Vše řeším rovnou u dané části aplikace.

Konkrétní výhody backendového přístupu

Formuláře, validace a HTML5 atributy

Symfony u formulářů automaticky generuje HTML5 atributy, které zlepšují uživatelský zážitek, a nabízí validace, které lze nakonfigurovat tak, aby přebíraly informace přímo z definice entit ukládaných do databáze. Pokud používáte Doctrine, stačí jeden řádek a například délka řetězce definovaná u entity se automaticky propíše až do validace formuláře – programátor s tím má minimum práce.

Validace probíhá standardní cestou na backendu. Napíšete jednu třídu, jak má formulář vypadat, a framework sám zkontroluje spoustu věcí – třeba i to, že uživatel vybírá jen z povolené množiny hodnot. Tím automaticky zamezíte tomu, aby vám útočník do aplikace posílal nesmysly. Prostě to funguje out-of-box aniž by programátor musel psát kód pro validaci. Zároveň když zkouším nějaký prototyp, se standardním formulářem se mi pracuje mnohem lépe než s testováním API.

Fungování i bez JavaScriptu

Aplikace postavená takto dokáže do značné míry fungovat i bez JavaScriptu. Z pohledu uživatele to dnes nemá velký smysl, ale z pohledu vývoje a testování je to pohodlnější – nemusíte řešit spoustu API volání a hledat v konzoli, co který skript dělá. Navíc je to lepší pro SEO.

Optimalizace a cachování

Backendový přístup umožňuje optimalizovat na nižší úrovni. Například přímo na úrovni SQL dotazů, což u volání samostatného API často není možné, nebo si musíte psát vlastní endpointy. Na backendu také můžete krásně cachovat to, co používají všichni uživatelé dohromady, a něco nacachuje i samotná databáze. Co se uloží do cache díky jednomu uživateli, mají další uživatelé k dispozici rychleji. Více o zrychlování webů najdete v článku Jak zrychlit web, rozdíly mezi databázemi pak v článku SQL: PostgreSQL, MySQL, MariaDB.

Jeden dotaz místo desítek

Pro výpisy dat uživateli používám standardní šablony frameworku, takže se nemusím učit nic nového. Stejnou šablonu můžu vyrenderovat přímo do stránky, nebo ji načíst JavaScriptem – na frontendu mi pak stačí jeden dotaz (klasický AJAX), který vrátí celý nový obsah, bez zbytečných dat navíc. To bývá rychlejší než načítat data spoustou dotazů a skládat je až v prohlížeči, který je pak často dost zpomalený. Šablona je navíc skutečně oddělená od logiky aplikace.

Znovupoužitelnost a kvalita kódu

Když logiku i funkce píšete na backendu, máte jeden kód, který lze snadno znovu použít, místo abyste stejnou věc psali zvlášť na frontendu i backendu. Nad tímto kódem navíc můžete používat PHPStan s restriktivními typy nebo PHPUnit, což zvyšuje pravděpodobnost, že bude kvalitní. Programujete víceméně v jednom jazyce – trochu JavaScriptu samozřejmě potřeba je, ale jen na načítání a nejnutnější dynamické prvky.

Jednodušší testování

Testování formulářů a logiky na backendu je často jednodušší než laborování s API. Pokud pošlete výsek HTML stránky, tak odpověď z URL dostanete tak, jak ji uvidí uživatel (jen bez stylů), a nemusíte složitě něco proklikávat. Hodnoty, které se počítají a ukládají do databáze, můžete pokrýt automatickými testy i statickou analýzou.

Nové funkce při aktualizaci frameworku

Pokud používáte framework, tak s upgradem frameworku přicházejí nové funkce automaticky. Aniž bych aplikaci sám vylepšoval, do jisté míry se vylepšuje sama.

Ukázka v praxi

Reálná ukázka takové aplikace a toto téma si můžete pustit i jako záznam přednášky z meetupu komunity Phpkáři:

Na první pohled to vypadá jako každá druhá webová aplikace , která načítá data a zobrazuje uživateli spoustu údajů vypočítaných podle aktuální situace. Používá se klasický Symfony formulář – po odeslání se data zpracují na backendu, zvalidují a uloží. Celou dynamickou část vygeneruje backend a na frontendu se jen zobrazí.

Když v prohlížeči vypnu JavaScript, aplikace postavená třeba v Reactu by ukázala jen bílou stránku. Tady se některá data nenačtou, ale formulář zůstane funkční – data jde normálně uložit. A když otevřu přímo URL dynamicky načítané části, vidím (sice bez stylů) přesně to, co backend posílá, což je pro vývojáře mnohem jednodušší kontrola než ladění API.

Podobný přístup jde kombinovat i s frontendovým frameworkem – například SvelteJS dodá interaktivitu a veškerá logika a formuláře zůstávají na backendu.

AI a robustní backend

V době AI je podle mě potřeba dbát na kvalitu backendu o to víc. Z pohledu výkonu i bezpečnosti je backend zásadní. Právě backend se stará o data, oprávnění a business logiku. Špatně udělaný backend může znamenat špatnou, nebo dokonce nebezpečnou aplikaci, a to bez ohledu na to, jak hezky vypadá frontend.

Naopak když máte robustní backendovou aplikaci, kde je vše pěkně propojené a validované frameworkem, je i nasazení AI mnohem bezpečnější. AI dokáže vygenerovat kvalitní kód, který stačí jen minimálně doladit, a díky existující struktuře frameworku nevzniká duplicitní kód. Čím robustnější je aplikace, tím ochotněji do ní AI pustím. Více o programování s pomocí AI píšu v článku Vibecoding – programování pomocí AI.

Výhled do budoucna: Live Components

Pokud bych v budoucnu chtěl stavět čistě frontendovou aplikaci, hledal bych technologii, kde napíšu kód jednou a ten se vyexportuje nebo vygeneruje tak, aby například validace fungovala shodně na backendu i frontendu, bez duplicity.

Podobné nástroje už dnes existují – za zmínku stojí Laravel Livewire a Symfony UX Live Components. Jde o backendové projekty, ve kterých si nadefinujete, jak mají vypadat formuláře a jejich validace. Validace přitom probíhá na backendu, ale funguje interaktivně – frontend posílá data, backend je validuje a pošle odpověď zpět. Pro uživatele je výsledek plně interaktivní, přitom veškerá logika zůstává na backendu a s čistě frontendovou technologií se vývojář setká jen minimálně. Pro některé jednodušší validace se vygeneruje i frontendový kód a validace probíhá přímo v prohlížeči bez odesílání dat na backend.

Shrnutí

Frontendové technologie mají své nezastupitelné místo, ale ne každý problém je potřeba (nebo vhodné) řešit frontendově. Backendový přístup, pokud se naučíte například PHP a framework Symfony, přináší méně kódu, méně bezpečnostních rizik ve výchozím stavu, snazší testování, lepší znovupoužitelnost a efektivnější cachování. U existujících PHP projektů navíc nedává smysl vše přepisovat na moderní frontendový stack jen proto, že je to aktuální trend. A v době AI platí dvojnásob, že kvalitní backend je základ.

Pokud vás zajímá, co všechno práce programátora obnáší, přečtěte si článek Co je pracovní náplň programátora. A pokud byste si podobné postupy chtěli osvojit prakticky nebo potřebujete pomoct s vaší aplikací, podívejte se na školení vývoje webových aplikací nebo mě kontaktujte.