Proč nepoužívám tradiční frameworky?

Rychlost

Vývojové frameworky

Druhou věcí je pak zbytečná robustnost určitých funkcí. Rozsáhlé knihovny obvykle zahrnují více funkcí a kódu, než je pro daný úkol nezbytné. Navíc jsou častokrát závislé na dalších knihovnách třetích stran. Vezměme za příklad třeba knihovnu respect/validation.. ta slouží k validaci určitých vstupů. Jen všechny její funkce jsou rozloženy do 330 souborů ze celkového počtu 790 souborů na samotnou knihovnu.  Každý přístup k jednomu souboru aktivuje file system a zvyšuje režijní náklady pro exekuci kódu. Navíc většina těchto funkcí je jen přepis jednořádkové funkce z PHP.. ano, kvůli jednomu řádku a použití existující funkce se vytváří další funkce v samostatném souboru obsahující pouze tuto nativní funkci. Tato knihovna je pak například i součástí zmíněného Laravelu a implementuje se pro validaci vstupů, tedy třeba formuláře na webu.

Takže kompletní test emailu provedeme snadno pomocí:

$email="mpavlik@mpavlik.co.uk";
if(preg_match("/^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/u",$email)){
  $domain = substr($email, strpos($email, "@") + 1);
  if(checkdnsrr($domain,"MX")) {
    echo "Email OK";
  }else{
    echo "Chybný email";
  }
} else {
  echo "Chybný email";
}

To je pomocí 299 bytů včetně formátování. Tento kód si samozřejmě můžeme vložit do funkce a volat opakovaně již jen jako jednořádkový příkaz např. validuj_email($email), resp. $validator->validuj_email($email).

Pokud použijete Laravel, ten použije knihovnu respect/validation, ta pro validaci emailu potřebuje další knihovnu Egulias\EmailValidator, která má opět dalších 87 souborů a 130kB. Neřeším pak další napojené knihovny (lexer, polyfill,...), které tyto jmenované potřebují a instalují ještě pro potřebu dalších funkcí, které ani v našem příkladu nepoužijeme. Celkově se pro validaci emailu pomocí knihovny respect/validation nainstalovalo neuvěřitelných 1 347 souborů o velikosti 6.8MB
Bavíme se zde o nahrazení naší funkce.. neřeším, že dané knihovny mají více možností, ty v našem případě nevyužíváme a jsou tak pouze balastní zátěží.  To vše pro nahrazení funkce, která má 299 znaků. Navíc to rozložení do desítek složek a stovek souborů zamne způsobuje spíše chaos nežli použitelné uspořádání. To je jako když by vám někdo dal naučit se celou učebnici matematiky pro gymnázia a skipta vysokoškolské matematiky kvůli výpočtu druhé mocniny, ke kterému vám stačí základní násobení z druhé třídy ZŠ.

Základní framework (symfony, laravel) má kolem 20MB (2.000 souborů), se všemi knihovnami pak kolem 80MB (5.000 souborů)! A to ve chvíli samotné instalace.. ještě v té době nemá žádný soubor s funkcionalitou.

Pro srovnání třeba systém, který jsem dělal v čistém PHP pro společnost Propuls Solar a který obsahuje 41 modulů z toho: Správu zaměstnanců, odvodů a mezd, Adresář dodavatelů a odběratelů, Správu firemních dokumentů, Kalendáře, Výkazy práce, píchačky, docházku a nepřítomnosti, Správu vozového parku, Kompletní sklady, příjemky, výdejky, inventury, výr. čísla, ceníky, Pokladnu, Faktury, Formuláře, Stravné, Nabídky (přijaté/vydané), Objednávky (přijaté/vydané), Zakázky, Šablony emailů, Úkoly a Konfiguraci systému má celkově včetně datových pump, propojovacích můstků do Pohody, logovacích nástrojů a mého frameworku dohromady 3.2MB ve 261 souborech. Na každé stránce pak probíhá import základní knihovny funkcí o velikosti cca 50kB.

CMS frameworky

Kontrola nad kódem a bezpečnost

V předchozím odstavci jsme si řekli, že takový jeden pěkný framework je složen z tisíců souborů a funkcí nasazovaných i k velice triviálním úlohám. Kdo kdy tvořil něco velikého závislého na stovkách jiných elementů ví moc dobře, že to vede spíše k frustraci nežli k zjedodušení cesty k cíli. Problémem je tedy to, že programátor není schopen znát je všechny. Když by si programátor vzal na každý jeden z těch 5.000 souborů byť jen 10 minut, tak je bude studovat přes 100 pracovních dní. Pokud použiji takovéto předpřipravené kusy kódu a nevím, jak on samotný funguje, tak jak mohu ručit za jeho správnost? Navíc ne vždy musí fungovat přesně tak, jak zamýšlíte.
Doporučení vývojářů je navíc aktualizovat všechny knihovny na měsíční nebo lépe týdenní bázi.. a pak se modlit, že bude vše fungovat tak, jak jste původně zamýšleli a nic nezpůsobí nějakou kolizi. Samozřejmostí je pak provést testy aplikace. V realitě to pak může představovat i desítky tisíc v nákladech, kdy budete platit za aktualizaci, testy a opravy něčeho, co nejspíš váš systém nikdy ani nepoužil a nepoužije. V praxi tak není nic neobvyklého, že na jednoduchý web či aplikaci se použije framework místo čistého řešení, které by nepotřebovalo údržbu a klient musí platit měsíční udržovací poplatky a to vlastně jen za šlendrián dodavatelské firmy,
která toto neumí naprogramovat, tak musí použít hotové řešení a to udržovat bez jeho vnitřní znalosti.


Ve Wordpressu bylo jen za poslední dva měsíce (k datu 12.7.2024) odhaleno více než 10 kritických chyb, které mohly vést k získání citlivých dat a nebo k převzetí kontroly nad celou stránkou.

V Laravelu jsou známé bezpečnostní chyby uvedeny třeba zde:
https://coderscotch.com/top-six-laravel-security-vulnerabilities-and-how-to-fix-them-in-2023/

V Symfony pak naleznete jejich výčet v pravidelných release notes na jejich blogu.
https://symfony.com/blog/symfony-7-1-2-released
https://symfony.com/blog/

Je dobré ale vědět, že většina se jich zatajuje z důvodu toho, aby nebyly lehce dohledatelné a zneužítelné širokou veřejností. Symphony třeba na webu uvádí, že je nemáte nikde zveřejňovat a pouze poslat na jejich email a oni se vám ozvou.
Stejně ale jakmile se nějaká díra objeví, proběhne tato informace přes komunitu hackerů velice rychle. Pokud tedy nebudete dané frameworky aktualizovat, brzy vám je napadnou. Hezky je to vidět například v logu přístupů na serveru, který ani wordpress neobsahuje.. vidíte ty pokusy...

Nezávislosti na třetích stranách.

Poslední bod se prolíná s předchozím a to převážně v otázce častých aktualizací a změn, které nejste schopni ovlivnit.
Buď budete mít systém, který bude v budoucnu s velikou pravděpodobností zranitelný nebo budete mít systém, jehož elementární prvky se budou klidně co měsíc měnit. Na řadu také může přijít zpoplatnění či zdražení daného nástroje. Novinkou by nebylo ani nahrazení za novou verzi, na kterou může být převod velice složitý. Toto byla věc třeba frameworku Zend1 a Zend2 nebo Symfony1 a Symfony2 (nyní jen Symfony), kdy přechod byl velice složitý, jelikož novinka přinesla změnu architektury a komponent bez zpětné kompatibility a navíc s nedostatečnou dokumentací.
Některé nadějné frameworky byly dokonce úplně ukončené. Jako Radiant, Kohana či CodeIgniter.

Vlastní řešení

Definice frameworku je "nosná konstrukce, kolem které lze něco postavit". Není to žádná superschopnost, žádná magie, ani hacky procesoru či záhadné zkratky do strojového kódu. Není to žádná raketová věda, něco, co by programátor nezvládl sám vyřešit. Pouze a jenom mu pomáhají rychleji k cíli a zjednodušují práci. Jak se říká v odborné komunitě "Pokud žádný framework nepoužíváte, nakonec si vytvoříte vlastní!" případně "Pokud používáte nějaký framework dostatečně dlouho, skončíte u jeho přepisováním." Toto je nicméně i to, jak vznikly tyto tradiční frameworky. Někdo prostě pro usnadnění svého vývoje napsal vlastní framework a ten pak uvolnil do světa. Nepoužívání tradičních frameworků tedy neznamená nepoužívání žádných. Jde spíše o cestu zkušenosti a toho, že používám za roky své praxe vlastní napsané knihovny a rámce (frameworky) či produkty. Mám tedy vlastní sadu jádra pro vytváření informačních systémů, k nim sadu pro práci s obsahem a číselníky. Sadu funkcí pro validace a pro řešení práv. Databázové funkce a řešení přihlašování. V případě, že potřebuji pro určité projekty další funkce, lehce je mohu rozšířit či doplnit. Dále mám vlastní sadu modulů v čistém PHP a JS, které zapadnou do každého řešení i frameworku :). Příkladem takových modulů je třeba Captcha, Wysiwyg editor (ve kterém píšu i tento blog), Fotogalerie (aka lightbox), API rozhraní, XML a CSV parser, Upload manager, SVG kontroler, SVG editor a jiné...

Z dnešního pohledu vám může připadat daný způsob mírně zkonstnatělý. Vždyť se o frameworcích mluví všude. Nicméně osobně programuji v PHP profesionálně již od roku 2003, kdy jsem udělal první eshop. To je přes 20 let. Až následně se objevily první ze jmenovaných frameworků a jednalo se o malé komunity. Postupně jsem mohl sledovat jejich vývoj a vzestup, problémy, úpadky a třeba v roce 2011 už po osmi letech v praxi vidět, jak byl opuštěn Radiant , Symfony s problémy přecházel na novou verzi a stejně tak Zend. Spousta firem řešila problémy jak a na co migrovat, co čekat a kam směřovat. Často se mi do rukou dostaly i zprávy o bezpečnostních dírách v daných řešeních. Navíc spousta obřích projektů napsaných za tu dobu v PHP jako Facebook, Wikipedia, Flickr nebo i CMS systémy jako Wordpress či Drupal jsou napsány v čistém PHP a používají případně své frameworky.
Jen pro úplnost pak uvedu největší projekty na Laravelu, což jsou ALISON, BARCHARTS, IvoiceNinja a MyRank. V Symfony pak třeba Spotify (pouze ale správa uživatelských účtů), Blablacar, Trivago a podobné.. velice často bookovací systémy.

Kam dál?

https://dev.to/francescostrazzullo/the-definition-of-framework-k70
https://en.wikipedia.org/wiki/Not_invented_here