Rozhovor s Milanem a Vojtou, vývojáři z PeckaDesign

Jak si 20leté studio užívá vývoj s Nette Framework? Adaptuje nové frontedové technologie? Kudy směřuje jejich další vývoj a co pro ně znamená home office?

Ahoj Milane, Vojto. Jsem moc rád, že jste přijali pozvání na tento rozhovor. Firmu PeckaDesign vnímám jako velmi blízkou Nette Framework a obecně české PHP komunitě. Vím, že se od vás hodně lidí účastní brněnských #posobot a dost často i jezdíte do Prahy na přednášky. Možná pro čtenáře doplňte, co o vás ještě netuší, máte jednu–dvě věty, jak byste se dnes jako PeckaDesign studio popsali?

M: PeckaDesign je agentura, která funguje letos už 20. rokem, přičemž posledních 8 let používáme na našich projektech Nette. Tvoříme pouze e-shopy, jako jsou Benu, Electro World, Gant, Hudy, Megapixel, Pneumatiky.cz a další a technologicky to je PHP, MariaDB, Elasticsearch, RabbitMQ, Git, ale kluci v poslední době makají na novém projektu, čímž se nám firemní technologie trochu rozšiřují.

V: Myslím si, že by čtenáře mohlo zajímat, že v Pecce děláme hlavně dlouhodobé projekty. Po spuštění projektu tedy naše spolupráce nekončí a pro klienty jejich projekty dále rozvíjíme. Projekt Electro Worldu děláme od roku 2015 a Nay.sk od roku 2014. V poslední době se naše soustředění na Nay a EW ubírá hlavně k Vue.js, Nuxt.js a s tím souvisejícím vývojem API.

Bylo pro vás velké rozhodování mezi Reactem a Vue.js?

V: Myslím si, že jsme tuto otázku nikdy ani pořádně neřešili. Asi před rokem a půl začaly přicházet od klienta požadavky na implementaci nových funkcionalit u kterých už bylo jasné, že jsou rozsahem mimo možnosti jQuery. Pokud by to napsat šlo, tak by to nechtěl nikdo dále udržovat a upravovat. O Vue.js jsme v té době začali slýchávat čím dál více a zaujalo nás především jednoduchostí s jakou jej lze začít používat v „legacy“ prostředí jQuery. Vyzkoušeli jsme jej a už jsme u něj zůstali. Postupně jsme pak ještě přidali TypeScript a class based přístup k psaní komponent.

Tak to zní jako ideální zapojení SPA technologií do rozjetého projektu. Vzpomeneš si ještě co byla první komponenta, kterou jste takhle přidali?

V: Myslím, že jako první byla implementace widgetu pro Balík na poštu, kde se vybírá pobočka pošty pro doručení zásilky. Toto byla implementace ještě v čistém Vue.js, další už byly TypeScript a class based.

Tak u takové věci se možná využívá API třetí strany, nebo to už byly první kroky i do vaší aplikace dostat nějaké základy API komunikace? Vnímám, že SPA, nebo případně jen JS komponenty si s Nette aplikaci „povídají“ buď přes nějaké data atributy, ale hlavně přes API.

V: Co se týče způsobu komunikace s Vue.js komponentama tak používáme oboje, či přístupy kombinujeme. Najdeme případy kdy se inicializační data a konfigurace předají přes data atributy a dále už komponenta komunikuje s backendem přes API. Vývojem Rest API se zabýváme už několik let, takže to v tomto případě spouštěč nebyl. Dost často se jedná o synchronizační API s různými systémy třetích stran, ale pro zákazníky jsme například vyvíjeli a dále rozvíjíme API pro mobilní aplikaci, kterou má Electro World a Nay pro Android i iOS.

Pro psaní API používáte REST a PHP, nebo vás zlákal Node.js svět a GraphQL? Jak vnímáte dnešní vlnu JavaScriptu / TypeScriptu na serveru? Pohráváte si s tím? Případně už máte v produkci nějaké JS services?

V: Na produkci se zatím držíme REST a PHP, vychází to tak nějak přirozeně ze zázemí Pecky, které je postavené primárně na PHP. Někteří kolegové už ale v rámci sebevzdělávání po GraphQL pokukují. Jak už jsem zmínil na začátku, v poslední době se hodně věnujeme internímu projektu pro našeho klienta, kde vyvíjíme front-end aplikaci nad Nuxt.js. V rámci tohoto projektu jsme řešili distribuci lokalizovaných textů do aplikace. Jelikož jedna aplikace běží na vícero serverech, museli jsme zajistit real-time aktualizaci pro všechny. Výsledkem jsou consumeři běžící nad Node.js, kteří jsou připojení na frontu v RabbitMQ. Na jedné straně tedy máme administraci napsanou v PHP a na druhé straně „microservice“ nad Node.js. Možná by se to tedy dalo považovat za takovou první vlaštovku.

M: V Pecce máme myslím nyní dobrý odhad na stabilitu používaných technologií. Nemůžeme nasazovat technologie podle toho, co aktuálně frčí, ale musí být stabilní a ověřené. Příkladem z druhého konce jsou projekty, které vznikaly v Pecce před přechodem na Nette. Jsou to weby a e-shopy postavené na Zend Framework 1 a Smarty, několik jich stále běží, protože pro klienta dávají stále smysl. Použité knihovny mají stále podporu a tak běží na PHP 7.1. Fungují tak bez větších zásahů 8–10 let. Máme jednoho programátora, který se o ně stará.

Na druhou stranu programátoři v rámci firemního sebevzdělávání sledují aktuální trendy a zkoušejí nasazovat, co dává smysl. Když tedy pominu udržování aktuálního stacku PHP, Nette, Kdyby a Contributte knihoven, jsou to právě frontendové záležitosti, ale i serverové a backendové. Lokálně vyvíjíme často v Dockeru nebo Vagrantu, máme vyzkoušených několik CI serverů, různé ORM frameworky. Máme zkušenosti také s nasazením dvoufaktorové autentizace, používáme interní OAuth2 server nebo přihlašování přes různé služby jako Facebook nebo Google.

Zend a Smarty to už je skoro jak retro edice dezertu metra, ale chápu, že některé projekty nemá moc cenu přepisovat. Máte nějaké Nette projekty na 0.9 verzi, nebo se snažíte běžet na aktuální verzi Nette 3? Co koukám na vaši opensource monitorovací aplikaci, tak ta ještě frčí na Nette 2.4.

M: První verze Nette, se kterou jsme začínali, byla 2.0-dev. V roce 2012 byla tato právě aktuální, než přišly 2.0 a 2.1. Všechny závislosti v Composeru tehdy byly na masteru. Z dnešního pohledu to byl velký punk, ale určitě se to ukázalo jako dobrá volba. Snadněji jsme tehdy projekty převedly na stabilní 2.1. Z verze 0.9 by to bylo horší. Úplně první e-shop postavený na Nette, Megapixel.cz, na kterém tehdy pracovalo několik členů Nette komunity, stále udává směr. Byl první na Nette a i nyní dostává jako první nové verze Nette a PHP. Zkusíme na něm kompatibilitu knihoven a pak převádíme ostatní projekty, které už sdílí společné jádro. Máme tedy vyzkoušené v produkci PHP 7.4 i Nette 3, připravili jsme i některé Kdyby knihovny, které spravujeme, poslali jsme pár pull requestů do Nette. Kluci nyní připravují migraci společného jádra na PHP 7.4 a potom přijde na řadu i Nette 3. Většina projektů má tedy Nette 2.4, ale brzy se to posune dál.

Jak tohle vnímáte s JS světem? Přijde mi, že tam je potřeba aktualizace skoro každý den. V tomhle má Nette po letech vývoje už nastavenou celkem příjemnou upgradovací politiku. Na obranu JS světa, Vue.js mi přijde, že přichází také s takovým klidnějším a hlavně zpětně kompatibilním přístupem.

V: Zatím jsme řešili pouze jeden problém u knihovny pro validaci formulářů, kde přechod mezi verzema nebyl úplně snadný, ale jinak nám to přijde srovnatelné s PHP světem. Snažíme se vybírat knihovny, které jsou kvalitní a hodně používané.

M: První důvod pro nasazení JS mimo prohlížeč byla kompilace LESSu, myslím, že to byl rok 2014. Nejdříve jsme zvolili Grunt. Zanedlouho přišel hype Gulpu a proběhlo přepsání na něj. Nyní se nasazuje Webpack. Mezitím jsme přešli od npm a boweru přes yarn zpět k npm. V porovnání s ekosystémem kolem PHP to je určitě komplikovanější. Ale jak říká Vojta, je to hodně o tom, co si člověk vybere za knihovny. Také v PHP jsme museli některé knihovny opustit, protože se nedostali z unstable verze dál, ačkoliv dělaly užitečnou věc. Je potřeba vybírat hodně používané knihovny se širokou nebo stabilní komunitou.

Z jiného soudku. Pokoukáváte i po cloudu? AWS? Azure? Nebo politika klientů vás zatím drží primárně na svých serverech? PHP beru jako stabilní a co tak sleduji, tak se přidávají spíše věci evoluční než revoluční (záleží na úhlu pohledu), ale kde to dle mě žije je určitě docker/k8s svět a teď k tomu hodně SPA/JS. Co takový serverless přístup?

M: Zatím všechno provozujeme shodně na managed serverech. Máme různé konfigurace: více projektů na jednom serveru, jeden projekt na server, aplikační + databázový server, případně různé servery pro různé služby na jeden projekt. Záleží od velikosti e-shopu. Toto řešení managed serverů je zatím cenově nejvýhodnější a zároveň je efektivní na údržbu. Aktualizace provádí hosting na naši žádost. V podstatě jednou za pár měsíců necháme aktualizovat PHP a další potřebné programy, jednou za rok až dva celý systém. Vážných problémů bylo za ty roky minimum a na všechno se dá spolehnout.

Při přechodu na novější verze PHP nás trochu omezuje souběh více projektů na jednom serveru. Ale není to tak strašné, protože se snažíme všechny aktivní projekty mít aktuální. Beztak tedy migrujeme všechny projekty zhruba ve stejný čas. Jakmile bychom jeden projekt ponechali pozadu, pracně bychom ho vraceli na špici.

V PHP naštěstí dobře fungují migrace mezi dvěma verzemi, kdy může být kód kompatibilní na obě strany. Výpadky služeb tak děláme prakticky minimálně právě při aktualizaci operačního systému.

Před dvěma roky jsme začali řešit otázku přechodu na Kubernetes a Docker v produkčním prostředí. Zatím jsme nevyřešili ekosystém, jestli všechno přenést na jeden cluster nebo na více clusterů, jaké služby mít na fyzickém serveru, které virtualizované. Je to dost o penězích, protože všechna řešení vychází dráž než současný stav. Naše projekty mají prakticky celý den náročný provoz v importech z ERP, razantní peaky v návštěvnosti přichází jen 2–3× do roka. Porovnáváme nabídku čistých cloudů, jako DigitalOcean nebo AWS, ale také možnost managed K8S, kdy zůstaneme u současného hostingu. Máme to ještě otevřené a uvidíme, jak se to vyvine dál.

To davá smysl, chvilku vyčkat jakmile se půda stabilizuje a prověří trochou času. Prošli jsme dotazy od frontendu, přes backend až po servery a napadá mě poslední z otázek a to jak jste prožívali COVID stav? Byla to pro vás příležitost změnit nějaké procesy ve firmě? Jak se díváte na home office do budoucna?

V: Myslím, že jako firma jsme na to byli připravení skvěle. Nemuseli jsme ani měnit procesy ani nasazovat nové technologie. Co se týče home office, tak si myslím, že je to v mém týmu tak půl na půl. Některým home office vyloženě vyhovuje a někteří rádi chodí do kanclu. Já osobně jsem z té druhé skupiny a více produktivní se cítím v kanceláři. Z pohledu komunikace v týmu jednu kancelář nic nenahradí. Není nic jednoduššího než zvednout hlavu a hodit otázku do pléna, když si s něčím nevím rady. Myslím si, že jakmile pomine korona období, tak se zase vrátíme do režimu home office podle potřeby.

M: Já jsem v našem týmu byl na home office zvyklý, protože jeden kolega pracuje pár dní v týdnu pravidelně z domu. Po dvou týdnech jsem tomu také přišel na chuť. Prostě zaklapnete počítač a věnujete se rodině. Žádná cesta domů. Podle mě se to zalíbilo více kolegům, začali více jezdit na kole, okolí Brna je pro to ideální. Ale chybělo mi to, co popisuje Vojta. Nemohl jsem se poradit ihned, musel jsem napsat na Slack a čekat na odpověď.

Firmu situace nijak nezasáhla. Práce jsme měli stále stejně, protože e-shopy fungovaly bez výjimky. Porady přešly do video režimu, tak jsme se občas i viděli. Teď už chodíme do kanceláří, podle toho, jak to komu vyhovuje. Home office u nás nikdy nebyl problém, jen na něm nikdy nebylo tolik lidí najednou.

Akorát jsme tedy museli odřeknout poslední dva srazy Péhapkařů (https://www.peckadesign.cz/pehapkari-brno). Pořádáme je u nás v kancelářích téměř každý měsíc od roku 2018. Uvidíme, kdy budou další. Určitě ale v tradici budeme pokračovat.

Díky oběma za inspirativní rozhovor

Děkujeme Honzo za tu možnost.