Význam technologií v e-commerce

Autorem článku je Petr Humplík, Head of SW Development. Petr je zodpovědný za technologické zázemí námi realizovaných projektů.

To, co spolu s dalšími kolegy vytváří, nemusí být vždy na první pohled vidět, ale je to důležité pro stabilní provoz všech našich platforem. 

Již několikrát jsem se ve své praxi setkal s názorem, že zákazníkovi je jedno, na čem to běží, hlavně že to bude levné a brzo. Ano, je to jeden z možných pohledů na tuto problematiku, nicméně z hlediska současných trendů v oblasti e-commerce, a pro B2B segment to platí dvojnásob, je tento pohled silně krátkozraký. Použité technologie v jakémkoli řešení se promítají do oblastí:

• Pořizovací cena
• Cena údržby –⁠ opravy chyb, reakce na změny způsobené třetí stranou (změna chování webového prohlížeče, nové protokoly atd.)
• Rozvoj –⁠ implementace změnových požadavků
• Garance poskytovaných služeb

Z hlediska výše uvedeného se všechno odvíjí od toho, jak je řešení postaveno – jaké jsou jeho základní stavební bloky, jakým způsobem spolu komunikují, jak se dají automaticky testovat. To vše bychom mohli obsáhnout jedním krásným slovem architektura. A právě architektura celého řešení je do značné míry určena technologiemi, na kterých je řešení postaveno.

Obecně platí, že lze řešení budovat v zásadě na čemkoli. Otázkou je, co nám výsledek umožní, a jaký to bude dohromady dávat smysl do budoucna. Svět IT je plný řešení, která vznikla před mnoha lety a dodnes žijí pouze díky úspěšnému zkřížení kočky, psa a tuleně. Věřte, že jsem takové systémy ve své praxi nejednou viděl. Denně se s nimi setkáváte při brouzdání internetem i na úřadech státní správy.

Vše se odvíjí od architektury

Pokud má mít řešení nárok na úspěšný život, musí být jeho architektura koncipována správně. Minimálně nesmí obsahovat hrubé chyby. A stavíte-li nové řešení na zelené louce, stává se tento požadavek námětem na přemýšlení na dlouhou řadu bezesných nocí. Bohužel, žádná koncepce nevydrží věčně, a jednou za čas je potřeba toto martyrium podstoupit. Důvodem je to, že svět IT se velmi dynamicky vyvíjí, naši zákazníci chtějí (zcela po právu) další a další nové věci, a dosavadní řešení není už dále možno „dolepovat“ a „ohýbat“. Je empiricky ověřeno, že každé softwarové řešení po čase dospěje do tohoto bodu.

Do této situace jsme se před několika málo lety dostali i my, a po zralé úvaze jsme postavili zcela nové jádro našeho e-shopového řešení.  A nebyli bychom správní architekti, kdybychom si neřekli, co od naší nové architektury očekáváme:

• Bezpečnost
• Flexibilita – Jednoduše řečeno,⁠ aby byl systém snadno upravitelný. Stará poučka říká, že správně napsaný kód je takový, který při jakékoli změně vyžaduje co nejméně úsilí (časovou náročnost). Mimochodem to je také důvod, proč naše nové jádro nese interní označení Flex.
• Přívětivost k programátorovi – Ačkoli naši zákazníci programátory nejsou, tato klíčová vlastnost systému se jich přímo dotýká. Pokud je systém k programátorovi přívětivý, potom se v jeho zdrojovému kódu IT pracovník snadno vyzná, mnohem rychleji odhaluje vzniklé chyby a mnohem rychleji realizuje změnové požadavky. Toto se přímo promítá do ceny těchto úkonů.
• Přívětivý k mobilním zařízením – Ať se nám to líbí nebo ne, opět jsme se dostali na „malé obrazovky“. Zákazníci ze segmentů B2B i B2C stále častěji využívají mobilní zařízení v rámci své interakce s e-commerce platformami. Pokud postavíte webovou aplikaci tak, aby fungovala především na mobilních zařízeních, vždycky bude fungovat správně i na desktopových počítačích. Naopak to bohužel neplatí.
• Schopnost reagovat na to, co teprve přijde – Architektura řešení musí být do budoucna schopna pojmout technologické prvky, o kterých se v současnosti teprve diskutuje, nebo jsou v raných fázích svého vývoje. Zpět v roce 2017 to byla třeba PWA (Progressive Web Application), integrace Web Components nebo Headless e-commerce. S hrdostí můžeme dnes prohlásit, že vše výše uvedené jsme schopni do naší nové platformy nasadit, nebo to tam již máme.
• Škálovatelnost – Systém musí být připraven na to, aby se jednotlivé stavební prvky daly jednoduše výkonově posílit v závislosti na aktuálních požadavcích zákazníka.
• Přenositelnost – Čili schopnost běžet všude. Mám na mysli rozmanité možnosti hostingu našeho řešení, jmenovitě na naší infrastruktuře, na klientově infrastruktuře, nebo na infrastruktuře třetí strany (cloudová řešení), případně kombinace všech uvedených modelů v rámci jednoho řešení.

Jako vedoucí týmu pro vývoj nového jádra bych to asi neměl říkat, známe to s tou samochválou, ale myslím, že se nám podařilo všech výše uvedených požadavků dosáhnout. Nepopírám, že je ještě stále co vylepšovat či opravovat, ale žádný z problémů, na který jsme v nedávné době narazili, nebyl v rozporu s architekturou řešení – tj. byl vždy relativně snadno odstranitelný.

Staré osvědčené versus nové neosvědčené

Pokud bych to chtěl říct úplně prostě, lze dodavatele e-shopových platforem rozdělit na dvě skupiny: ti, co staví na PHP a ti druzí.

Většina dodavatelů e-commerce řešení staví své produkty buď na hotových open source řešeních, nebo in-house vyvinutých aplikacích používající PHP a frameworky postavené nad ním. Ačkoli jsou tyto systémy lety ověřené a jejich použití se pozitivně promítá do pořizovací ceny řešení, přece jen to má své nevýhody. V tomto případě se jedná o model tlustého serveru a tenkého klienta, u nějž k vykreslování stránky dochází na serveru a hotová vykreslená stránka je předána prohlížeči. Takovéto řešení poznáte snadno podle toho, že při navigaci z jedné stránky na druhou v rámci e-shopu dochází k plnému překreslení stránky v prohlížeči. Samozřejmě, leccos se dá dohnat správně nastavenou vyrovnávací pamětí prohlížeče, leč stále je to plné vykreslení stránky při změně URL.

Citelnou slabinou tohoto pojetí je obvykle slabší výkon na mobilních zařízeních, které kromě menší obrazovky disponují malým výkonem ve srovnání s desktopovým počítačem nebo notebookem. Tuto poměrně zásadní nevýhodu lze částečně omezit použitím kvalitní optimalizace, nicméně je principiálně u takovýchto aplikací neodstranitelná – kompletní přenačítání stránky při navigaci po e-shopu je pro mobilní zařízení zkrátka nevhodné.

Do druhé skupiny dodavatelů, kam spadáme i my, řadíme firmy používající technologii tlustého klienta a tenkého serveru. Jedná se o celou rodiny frameworků, jež slouží k tvorbě tzv. SPA (Single Page Application).

Jistě jste už alespoň něco zaslechli o technologiích jako je Angular, React, nebo Vue.js. Hlavním rozdílem oproti předchozímu přístupu je to, že k vykreslení hlavní kostry stránky (s často se opakujícím kódem) dochází pouze při prvotním načtení. Při navigaci po e-shopu pak dochází pouze k načítání čistých rozdílových dat pro tu či onu stránku. Například při přechodu z jedné stránky katalogu na druhou se již jednou vykreslené hlavní menu, hlavička a patička nevykreslují znovu, ale dochází pouze k načtení sekce s produktovými dlaždicemi, která jediná se liší oproti předchozí stránce. Je nasnadě, že mezi serverem a klientem (vaším webovým prohlížečem) se vyměňuje daleko menší objem dat. Z tohoto také vyplývá, že SPA aplikace jsou mnohem výkonnější na mobilních zařízeních.

Toto byl také jeden z hlavních důvodů, proč jsme při tvorbě nového jádra naší e-commerce platformy sáhli právě po SPA. V našem případě SPA postavené na open source frameworku Angular, který je vyvíjen společností Google.

Samozřejmě, tím, že jsme jako první v oblasti e-commerce v ČR šli touto cestou, museli jsme řešit celou řadu dílčích problémů, které se na dvacet let starých technologiích řešit nemusí. Shodli jsme se však na tom, že toto není důvod nejít s dobou, a přece jen nám to stojí za to.

Tragéd mezi jazyky, kterého se jen tak nezbavíte

Ano, mám na mysli JavaScript. Jeho úloha v současném světě webových aplikací (a tedy i e-commerce) je naprosto klíčová. Ať už stavíte své řešení výhradně na serverových technologiích Microsoftu nebo na PHP, vždycky na e-shopu budete potřebovat JavaScript. Budete ho zkrátka potřebovat hodně, ať se vám to líbí nebo ne.

Důvodem je fakt, že uživatelé webových aplikací již dnes berou celou řadu funkčností jako naprostou samozřejmost: vyskakovací okna, carousely (rotující bannery), 3D náhledy produktových obrázků, načítání určitých oblastí stránky odděleně od dalších, a mnoho, mnoho jiného. To vede k dalšímu důležitému „poznávacímu znamení“. JavaScriptový kód, který na vašich stránkách zcela jistě bude, je možno napsat dvěma základními způsoby: systematicky a nesystematicky.

Systematicky navržený JS kód se obvykle vyznačuje těmito vlastnostmi:

• Je modulárně rozdělený podle funkčností, které v aplikaci plní.
• Jednotlivé moduly se načítají podle potřeby, ne při prvotním načtení stránky všechny najednou.
• Je automaticky testovatelný.
• Je napsaný čistě a bezpečně (bezpečnost především).

Vzhledem k tomu, že jsme sáhli po SPA aplikaci na Angularu, máme všechny žádoucí vlastnosti našeho JavaScriptového kódu takříkajíc „out-of the-box“, čili „přímo v balení“.

Aplikace výše zmíněného staršího modelu, tj. aplikace s tlustým serverem, musejí JavaScriptový kód obsahovat rovněž. Důvody jsem již uvedl výše. Ze zkušeností vím, že kvalita, modularita a bezpečnost takového kódu jsou mnohdy na pováženou. Důvod je jednoduchý – s touto technologií, která funguje výhradně na straně klienta, nebylo počítáno prvoplánově při počátečním návrhu systému. JavaScriptový kód byl dolepován průběžně, několika vývojáři a většinou bez koncepce. Výsledkem je často vysoká chybovost na této aplikační vrstvě spojená s dodatečnými náklady. Vzhledem k vrozené tvrdohlavosti JavaScriptu jsou jím způsobené chyby mnohdy pořádně záludné, a bohužel, jsou to zpravidla ty, kterých si koncový zákazník všimne nejdříve.

Bezpečnost především

„Aby bylo něco bezpečné, musí to být odpojené od internetu.“

Toto moudro jsem slyšel tolikrát a od tolika zkušených lidí, že jsem naprosto přesvědčen o jeho pravdivosti. Bez legrace. Ale řekněme, že tato možnost není, protože předmětem naší činnosti je právě výroba webových aplikací na internetu dostupných.

Bezpečnostní experti a hackeři dobře vědí, že každou aplikaci na internetu lze lidově řečeno „prostřelit“. Jediné, co můžeme udělat, je snažit se o to, aby případných bezpečnostních děr bylo v našem systému co nejméně. Co určitě můžeme udělat, je snažit se odstranit všechny potenciální hrozby, o kterých víme a umíme je odstranit.

Toto vede k další důležité vlastnosti, kterou by správná webové aplikace měla mít – bezpečnost jako integrální součást systému. Bezpečnost, na kterou se dbá od prvních řádků kódu nově stavěného řešení.

A jak se bezpečnost dá integrovat přímo dovnitř vaší aplikace již při její stavbě? V prvé řadě vhodně zvolenou architekturou (jsme opět u toho), vhodnou volbou technologické báze (použitých frameworků), vhodnou volbou balíčků třetích stran, automatizovanými bezpečnostními testy na všech vrstvách aplikace.

Nejčastější vektory útoku na webové aplikace jsou dobře známy a existuje celá řada testovacích nástrojů a metodik, které vám prozradí, na kolik je vaše aplikace bezpečná či nikoli.

Například použitím vhodně zvolené serverové technologie pro komunikaci s databází jste schopni do značné míry snížit riziko útoku typu SQL Injection. A riziko tohoto typu útoku musíte mít na paměti po celou dobu návrhu této vrstvy vašeho řešení.

Vhodnou volbou technik pro psaní JavaScriptového kódu jste schopni výrazně snížit riziko útoků z rodiny XSRF. Tedy za předpokladu, že tento fakt budete mít na paměti celou dobu výstavby klientské části vaší aplikace.

Striktním dodržováním a správným nastavením komunikačních protokolů, jako je například TLS, jste schopni snížit riziko útoku typu Man-in-the-Middle.
Jak vidíte, dá se něco dělat, a není toho málo. Zcela klíčovým faktorem je to, zda je bezpečnost již přímo součástí návrhu vašeho řešení, nebo zda tam byla v průběhu času dolepena jako „bezpečnostní doplněk“.

Vlastnit či nevlastnit zdrojový kód, to je oč tu běží

Velice často se setkáváme s dotazy našich klientů, zda je možné odkoupení zdrojových kódů naší aplikace. Obecná odpověď zní obvykle tak, že to možné je, ale…

Motivace klientů k odkoupení zdrojového kódu je obvykle strach z budoucnosti jejich internetového podnikání v případě našeho výpadku nebo zániku. Nebudeme hovořit o tom, na kolik je tento scénář pravděpodobný. Podívejme se spíše na technickou stránku věci.

E-commerce řešení je jako jakákoli jiná datově řízená webová aplikace. Jako taková není nikdy ze své podstaty dokončená. Je stále živá. Odkoupíte-li zdrojové kódy jako „bezpečnostní pojistku“, je třeba mít na paměti, že i když dojde k tomu, že je použijete, dostáváte se teprve na začátek dlouhé a trnité cesty. Zásadními problémy, na které v takovém případě narazíte, jsou:

• Potřeba sehnat tým vývojářů se znalostí použitých technologií (vzhledem k rozsahu si nevystačíte s jedním vývojářem). Na tomto místě jsme vám vyšli v naší architektuře vstříc tím, že nepoužíváme další námi vyvinuté obalující frameworky. Vývojářům, které byste hypoteticky potřebovali, postačí znalosti obecně známých frameworků, které mají dostatečnou a dobře dostupnou dokumentaci.
• Potřeba aplikaci poměrně rychle vytáhnout ze zakonzervovaného stavu. Odkoupené zdrojové kódy po dobu svého uložení nepodléhaly aktualizacím a bezpečnostním záplatám, rovněž se změnilo chování internetových prohlížečů. V tomto ohledu bude potřeba řešení doladit.
• Potřeba se zorientovat. U jednodušších řešení v řádu týdnů, u složitějších v řádu měsíců. Po tuto dobu bude mít váš vývojový tým citelně sníženou efektivitu.
• Cena

Neberte prosím tento odstavec ani jako odrazování, ani jako vybízení. Byl míněn jak obecná odpověď na poměrně často kladenou otázku.

Internet plný nástrojů, co s nimi

Současná paleta nástrojů k testování e-commerce aplikací (webových aplikací obecně), které můžete zdarma najít na internetu, je opravdu široká. Ať už je uživatelem kdokoli, koncový zákazník B2C, váš obchodní partner, nebo vy, máte možnost otestovat celou řadu parametrů z pohodlí vašeho prohlížeče.

Můžete si ověřit nastavení SEO, výkon aplikace na desktopu či na mobilu, přívětivost k mobilním zařízením, bezpečnost, nebo třeba nastavení marketingových nástrojů.

Naši zákazníci nám často posílají výstupy různých takových nástrojů a nemáme s tím problém. A protože určitě chcete slyšet nějaké ale, tak vám jedno dám. Ať již budete testovat naše, nebo konkurenční řešení, mějte prosím na zřeteli, že výstupní těchto testovacích nástrojů jsou určeny primárně vývojářům nebo SEO specialistům. Nejen že se to v nich hemží odbornými pojmy, ale často rovněž dochází k „falešné detekci problému“. Je to způsobeno tím, že nástroj je automatický a není schopen vyhodnotit všechny scénáře, které mohou nastat. Zároveň si obvykle dokáže vytvořit pouze omezený obraz o testované vrstvě, nezná ovšem celou aplikaci a tudíž neví, jaké mechanismy jsou použity za touto vrstvou (typicky u bezpečnostních testů). Jednoduše řečeno, nezná celý obraz.

Ideální postup je samozřejmě ten, že pokud nejste schopni se v testovacím protokolu (výsledku měření) vyznat, obraťte se na nás. Rádi vám s vyhodnocením testu pomůžeme a vysvětlíme, co je popsáno pro vás nesrozumitelnou formou.

Slovo závěrem

Na několika pohledech jsme si ukázali, proč mají použité technologie naprosto zásadní vliv na úspěšný život vašeho e-commerce řešení.

I přesto zůstává klíčovým faktorem jakéhokoli podnikání člověk a přidaná hodnota, kterou může pouze člověk vytvořit. Obklopte se správnými lidmi a polovinu problémů máte vyřešenou.