Mall

Problém

Marketingové oddělení mall.cz potřebovalo nástroj, jehož pomocí bude moci rychle a dle aktuálních potřeb udělat změny v menu webu, například pro sezónní zboží, různé akce, apod. Zároveň bylo třeba zajistit, aby se ukládala historie změn a v případě potřeby bylo možné se k jednotlivým úpravám vracet.

Výzva

Hlavní výzvou bylo, jak ukládat data tak, aby byla snadno udržená historie změn v menu: jaké úpravy kdo a kdy vytvořil. Dále pak také propagace změn jako takových až k zákazníkovi na web.

Řešení

Pro uložení dat jsme využili tzv. event stream a snapshotting. Data se v takovém případě neukládají jako celek, ukládají se pouze operace, které se s daty provádí. Aplikací těchto událostí na výchozí stav se dostaneme k výsledným datům.

Základními operacemi je vytvoření / editace a smazání položky. Výchozím stavem je prázdné menu.

Důležitým faktorem je to, jak jednotlivé operace přicházejí za sebou. Vždy se musí při aplikaci operací postupovat od nejstarších po nejnovější.

Díky tomuto systému jsme schopni ke každému časovému okamžiku sestavit přehled, jak data v daném čase vypadala. Když ke každému záznamu přidáme i uživatelské informace, máme pak rovnou vyřešený výpis historie, protože jasně víme, jaké operace, v jakém čase a kdo provedl.

Problém ale nastane v případě, kdy je nutné aplikovat hodně eventů najednou. Není dobré vycházet vždy z původního stavu, protože aplikace všech eventů postupně bude časově narůstat. Tento problém redukuje snapshotting. Jedná se o průběžné ukládání výsledného stavu dat v konkrétní čas. Máme-li nějaký stav v čase uložený, pak se k dalšímu stavu dostaneme aplikováním událostí od tohoto času dál. Dejme tomu, že ukládáme snapshoty s každým stým eventem. Máme pak jistotu, že se od předchozího stavu k aktuálnímu dostaneme vždy po aplikování maximálně 100 událostí, a jsme schopni počítat s konstantním časem na sestavení aktuálního stavu dat.

Problém

Jednou z krizových oblastí každé webové aplikace je rychlost načítání obrázků. Cílem práce vývojářů je to, aby si uživatel vlastně ani nevšiml, že se mu nějaké obrázky načítají. Pokud si všimne, není to dobré znamení a nikdo by se v takové situaci uživateli nedivil, kdyby z e-shopu z tohoto důvodu odešel.

Řešení

Rozhodli jsme se pro AWS serverless řešení kvůli velmi variabilnímu škálování služby. Jsme tak schopni celé řešení škálovat během velmi krátké doby a optimalizovat tak miliony obrázků.

Celá služba pracuje zcela nezávisle na jiné službě. Proto, abychom dokázali rychle měnit průtok danou službou, jsme připravili REST API, které funguje pouze na příjem požadavků na optimalizaci. Jeho cílem je předat požadavek k optimalizaci do fronty a současně předat informaci žadateli o tom kde výsledný obrázek nalezne.

Poté probíhá samotná optimalizace obrázků. Pracujeme se dvěma variantami. Nejdříve probíhá velmi agresivní komprese, která dokáže obrázek optimalizovat na dřeň ale zároveň vizuálně beze změny. Nicméně v mnoha případech (přibližně pod 1 procento všech obrázků) se nepodaří obrázek optimalizovat. Pro tyto případy používáme záložní variantu, která dokáže zoptimalizovat (i když ne tak dobře) prakticky každý obrázek.

Proces

Během procesu jsme se museli vyrovnat s velkou rozlišností vstupních obrázků, avšak s jedním nastavením výsledné optimalizace. V jednom z řešení jsme počítali i se spuštěním více optimalizací a následným porovnáním s původním obrázkem – tj. vybrat ten typ optimalizace, který vizuálně nedestruuje výsledný obrázek strojově. Po několika testech měření se však ukázalo, že ve většině případů vítězí jedna metoda.

Problém

Zákazníci e-commerce si možná neuvědomují, že rozsáhlé e-shopy jsou téměř permanentně vylepšovány velkými týmy vývojářů tak, aby průběh nákupu byl pro uživatele stále více přívětivý a jednoduchý. Je třeba věnovat pozornost i takovým jednotlivostem jako je hlášení chyby, která může zákazníka odradit od dalšího nákupu. Objeví-li se na stránce chyba, je třeba ji co nejdříve nahlásit, aby došlo k rychlé nápravě. My jsme pro MALL pracovali na aplikaci, která dokáže kdekoliv na webu vyvolat formulář pro hlášení chyby. Tento formulář se po odeslaní dostane do systému JIRA a zde se založí požadavek s veškerými údaji a detaily tak, aby byla chyba co nejlépe specifikována a mohla tedy být co nejrychleji vyřešena.