Způsob, jak se vyvíjejí aplikace v PHP, se v posledních 5 letech dramaticky proměnil. Nejprve jsme opouštěli čisté PHP a učili se používat frameworky, později přišel Composer a s ním instalace knihoven z příkazové řádky a nyní nastává konec frameworků, jak je známe.
Monolitické frameworky se postupně rozpadají do samostatných (decoupled) komponent. A to přináší řadu výhod. Zatímco dříve bylo použití jen jedné části frameworku obtížné až nemožné, dnes si prostě nainstalujete jeho komponentu. Vývojový cyklus jednotlivých komponent může mít různé tempo. Mají vlastní repozitáře, issue trackery, mohou mít vlastní vývojářské týmy.
Komponenty můžete aktualizovat na nové verze průběžně, bez čekání, než vyjde další verze celého frameworku. Nebo naopak se můžete rozhodnout určitou komponentu neaktualizovat, třeba kvůli BC breaku.
Význam slova framework se tak posouvá, o verzích už takřka nelze hovořit. Místo frameworku XYZ ve verzi 2.3.1 používáte sadu komponent v různých verzích, které spolu fungují.
Rozdělení frameworku na komponenty je dost složité. Nette to trvalo 2 roky a hotovo bylo loni. Naprostou nutností bylo prosazení se Composeru a také důsledné používání dependency injection. Nette dnes tvoří přes 20 samostatných repozitářů a v tom původním zbyla jen jediná třída.
Všechny významné frameworky, jako Symfony, Zend, Laravel nebo CakePHP, jsou rozčleněné do komponent, byť k dotažení chybí ještě jeden krok: rozdělení do samostatných repozitářů (namísto náhražky v podobě Git subtree split). Zend slibuje, že s tím přijde ve verzi 2.5, uvidíme, co Symfony.
Komponování Nette
Dlouhým úvodem jsem se vás snažil přivést na myšlenku, že dívat se na Nette jako na framework v nějaké konkrétní verzi je překonané. Že šikovnější je k němu přistupovat jako k sadě komponent.
Tj. namísto uvádění závislosti na nette/nette
uvádět
závislosti na konkrétních komponentách. Tak to nyní dělá
i Sandbox. Jako základ budoucí aplikace může posloužit i Nette Web Project, což je
úplně minimalistická obdoba Sandboxu. Stáhněte jej pomocí
composer create-project nette/web-project
a vyhoďte z composer.json
komponenty, které nepotřebujete.
Zrychlíte tak operace Composeru.
Rychleji se k vám dostanou i bugfixy. Po opravení chyby lze hned u příslušné komponenty tagnout novou verzi, zatímco cyklus uvolňování verzí celého frameworku je mnohem pomalejší.
Pokud tvoříte doplňky pro Nette, tak vůbec neváhejte a hned nahraďte
závislost na nette/nette
výčtem skutečně požadovaných
komponent.
Samozřejmě i nadále budou vycházet nové verze frameworku jako doposud,
bude fungovat require nette/nette
a pro verzi 2.3 budou vycházet
i distribuce v archivech ZIP. Ale jejich význam bude pomalu upadat.
Komentáře
Vojtěch Kohout #1
Očesaný sandbox, jupí! :) Díky!
Pepa #2
Dneska hodně moderní pojem Full Stack Developer… Jak to vidím kolem sebe, tak frameworkům jako takovým asi odzvonilo. (Určitě odzvonilo…) Osobně už asi nerozumím ani tomu, jak někdo může říct: „Já jsem PHP/Python/Ruby programátor.“
Tohle je super, ale ještě dál jde asi NodeJS, spolu s jeho NPM.
Na vše je nějaký balíček. Balíčků přibývá neuvěřitelným tempem.
V balíčcích jsou i věci jako Express, včetně Bootstrapu, template enginů a já nevím co všechno. Opravdu VŠECHNO.
Skvěle jsou vyřešené závislosti, testování a vše s tím souviející. Instalace probíhá jediným příkazem…
Když vidím kam se posouvá JavaScript, nemyslím si, že o PHP bude někdo ještě za pár roků/měsíců stát…
Prosím, neberte to jako jako kopání do PHP, ale zkuste se odpoutat od svých knihoven, podívat se na to co řešíte a nahlédněte na to nesvázaným pohledem, jestli by se to co programujete, nemělo řešit/programovat jinak…
David Grudl #3
Ano, JavaScriptová platforma prochází překotným vývojem, neboť dotahuje konkurenci. Zatím prochází telecími léty, věci rychle vznikají a zanikají, komfort zdaleka nedosahuje toho, na co je člověk zvyklý u jiných platforem. Ale jde to rychle kupředu a výsledkem bude nějaká symbióza se současnými serverovými jazyky a technologiemi. Což je fajn, těším se na to.
Vojtěch Kohout #4
#2 Pepa, „Use the right thing on the right part of your business.“
Úplně nejlepší je použít PHP tam, kde to dává smysl, použít JavaScript tam, kde to dává smysl, použít Clojure tam, kde to dává smysl, použít
<whatever>
, kde to dává smysl.Oblastí, kde PHP + Nette komponenty + Symfony komponenty dávají smysl, je požehnaně.
Jakub Kulhan #5
Nemyslím si, že subtree split je náhražka, ale naopak dobře vypočítaný krok. I když by bylo fajn a všechny komponenty frameworku byly naprosto decoupled, i tak se najdou věci, které přesahují hranice jednotlivých komponent (hlavně různé utilities). Refactoring přes X repozitářů je pak docela porod.
Poslední zkušenost s ReactPHP, kdy framework rozdělili na více repo, každé si začalo žít vlastním životem a rozjelo se jim číslování verzí, některé komponenty zaostávaly za ostatními… Hrůza s tím pracovat.
Mít jedno velké repo má svoje výhody – viz zkušenosti FB https://web.archive.org/…book-s-scale
David Grudl #6
#5 Jakub Kulhan, Jedno repo, jednotné verzování = monolit.
Monolit s možností nainstalovat výřez – všechny ostatní výhody uvedené v článku padají. Dochází i k absurdním situacím, kdy vycházejí nové verze komponent, které se od těch předchozích neliší ani komitem navíc, jen prostě v rámci monolitu vyšla nová verze něčeho jiného.
Co popisuješ je situace, kdy se rozdělení frameworku do komponent prostě nepovedlo. Důvod může být ten, že framework ještě nebyl dostatečně zralý (dělit Nette před 2.0 bych si netroufl). Nebo se řez vedl špatným směrem.
Subtree split je pak způsob, jak rozdělení emulovat, jak si ho vyzkoušet nanečisto. Což je naprosto ok, ale je to provizorium.
ivan #7
#3 David Grudl, …JavaScriptová platforma …dotahuje konkurenci…komfort zdaleka nedosahuje toho, na co je člověk zvyklý u jiných platforem…
No – ne že by to nebyla v některých ohledech pravda. Ale pod článkem, který má v pozadí to, jak se php snaží dotáhnout komfortem konkurenci (včetně javascriptové platformy a npm) to působí trochu legračně ;)
Marty #8
Líbí se mi, jak PHP ekosystém jako celek postupuje kupředu. Skalarní datové typy + zrychlení očekáváne v PHP 7, rozšíření používání Composeru (ústup PEARu), HHVM a kvalitní IDE jako je PhpStorm.
Miroslav Koula #9
#2 Pepa, Tak nějak mě baví sledovat ty názory, že PHP má už odzvoněno 🙂 David jako pamětník se mnou zavzpomíná na vlny, kdy se objevila platforma .NET, JSP. Pak bylo chvíli ticho a přišel boom Djanga následovaný RoR, ale tak nějak mi pořád přijde, že v globálu se PHP vedle Javy profiluje jako jedna z nejsilnějších platforem v komerčním vývoji…
null #10
#5 Jakub Kulhan, #6 David Grudl Keď som videl to video od FB, tak som si hneď spomenul na Nette ako sa rozbilo do niekoľkých Git repo a vďaka tomu vznikli nové problémy, napr. ako sledovať zmeny zo všetkych repo na jednom mieste, viac administratívnej práce na spravovanie, a pod…
FB vyriešil ten jeden veľký „monolitický“ repo tak, že zavrhol pomalý Git a použili rýchly Mercurial a jeho Sparse checkouts a Shallow history, čo mu umožnilo lepšie narabať s jednotlivými projektami v jednom repo. Odporúčam to video pozrieť. Zaujímavé veci sa človek dozvie, napr. ako musí FB už inak pristupovať k vývoji pri jeho veľkosti.
error414 #11
Jsem rád že se to hejbe tímto směrem, Jeden čas jsem chtěl používat PEAR jako repozitář ale bylo to nepoužitelné, ovládaní a obsah PEARu byl pod psa.
OnGe #12
Skládat si aplikaci z jednotlivých komponent je bezva věc, sám to dlouhé roky prohlašuji za ideál, ale má to i své proti. A myslím si, že za to proti může Composser. Tedy nepřímo.
Že hlídání závislostí řeší nějaký nástroj je dobrá věc, ale pak se stane, že člověk závislosti neřeší vůbec. A tak když si stáhnu pár balíčků řešících různé věci, stáhnu si s nimi, kvůli závislostem, ještě komponenty pro práci s databází, request/response, případně nějakou cool vychytávku co třeba dělá nějaké debugovatelnější exceptions. A legrační na tom je, že každá komponenta používá na ten který úkon jinou komponentu.
Takže ve výsledku mám s 6 cizími komponentami 5 databázových vrstev, 4 request/response handlery a 3 cool vychytávky, které dělají nevím co. Zbytečně. Z „hlídat závislosti není problém“, (což je pravda) se vyklubalo „závislosti nejsou problém“ (což je průser).
František Maša #13
#12 OnGe, Problém bych viděl spíš ve vývojářích konkrétních balíčků. Composer podporuje suggest (pro doporučení, co dál k balíčku nainstalovat), které bohužel spostu vývojářů nepoužívá. Co si budeme nalhávat, je jednoduší udělat knihovnu, která má napevno zadrátované závislosti, než knihovnu modulární. :)
Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.