Přejít k navigační liště

Zdroják » Různé » Návrh uživatelské části e-shopu

Návrh uživatelské části e-shopu

Články Různé

Druhý díl seriálu o tvorbě moderního e-shopu bude věnován vytvoření návrhu uživatelské části na základě požadavků z minulého dílu. Hlavním tématem bude vytvoření návrhu komunikace mezi API a uživatelskou částí.

Architektura aplikace

E-shop popsaný v minulém díle budeme vytvářet způsobem, který je odlišný od klasických způsobů tvorby aplikací. Středem celé aplikace bude REST API, se kterým budou komunikovat ostatní části, v tomto případě rozhraní k administraci a rozhraní k uživatelské části. Tímto způsobem je projekt rozdělen na tři samostatné části, jak ukazuje následující schéma:

Striktní oddělení tří částí přináší jednu velkou výhodu: můžeme vytvořit nejprve celou uživatelskou část, aniž bychom napsali jediný řádek kódu na straně serveru v Node.js.

Problémy při návrhu „klasickým“ způsobem

Všichni nejspíš máme tu zkušenost, že na papíře je možné vše hezky plánovat, ovšem jakmile se aplikace začne reálně programovat, dochází k četným změnám, které je ovšem nutné komunikovat s klientem, což stojí hodně času. A i když všechny změny klient odsouhlasí, jakmile je mu aplikace předvedena, okamžitě začne požadovat množství úprav. A úpravy v již naprogramovaném (hotovém) e-shopu stojí mnohem více času a peněz než úpravy „na papíře“.

Proto jsou zde různé agilní metodiky, které se snaží s klientem práci průběžně komunikovat a rozdělit projekt na menší iterace a vyhnout se tomu, že na konci práce nedostane to, co opravdu potřebuje. Tímto se ale nevyhneme četným úpravám kódu, s čímž některé metodiky již přímo počítají.

Abychom minimalizovali nutnost změn, snažíme se od klienta získat nejkvalitnější informace o tom, co vlastně potřebuje a z nich pak vytváříme návrh, který se mu snažíme co nejpřesněji odprezentovat (tímto tématem se zabývá skvělá kniha Požadavky na software od Karla E. Wiegerse, velmi doporučuji). Používá se k tomu např. prototypování.

Vůbec nejlepší by bylo, kdyby klient viděl přímo šablony s reálnými daty a mohl s nimi pracovat jako s klasickým webem. Viděl by již funkčnost reálného e-shopu, který poté dostane, a je tedy velmi pravděpodobné, že by dokázal většinu změn oproti návrhu odhalit již zde. Zároveň ale nechceme trávit žádný čas navíc něčím, co je pouze pro prezentaci a co pak zahodíme. A právě aplikace s REST architekturou takový způsob návrhu umožňuje.

REST API a Apiary

Nejprve vytvoříme celou uživatelskou část v AngularJS. Se serverem bude komunikovat pouze pomocí REST API. Protože API budeme programovat až po tvorbě uživatelské části, využijeme nástroj Apiary, který na předem dané HTTP požadavky bude odpovídat předdefinovanými HTTP odpověďmi. Z toho pak dostaneme také data pro lokální testování a vždy aktuální dokumentaci. REST API a Apiary se věnoval 8., 9. a 12. díl seriálu o Node.js.

Podobným způsobem budeme vytvářet i administraci (kterou může programovat i jiný vývojář zároveň s uživ. částí) i případně ostatní projekty, které budou získávat data také přes API (třeba nějaká mobilní aplikace).

Struktura uživatelské části

Při tvorbě návrhu budeme hledat nejjednodušší řešení, které splní zadané požadavky. Sepišme si seznam stránek, které se budou zobrazovat v uživatelské části:

  • Úvodní stránka
  • Detail kategorie
  • Detail produktu
  • Detail stránky
  • Vyhledávání
  • Košík
  • Výběr dopravy a platby (1. krok objednávky)
  • Zadání uživatelských dat (2. krok objednávky)
  • Potvrzení objednávky (3. krok objednávky)

Na těchto stránkách budeme zpracovávat několik operací, kvůli kterým bude potřeba komunikovat s API:

  • získání seznamu kategorií pro menu,
  • získání seznamu stránek (FAQ, obchodní podmínky ap.) pro další menu,
  • získání detailu stránky,
  • získání několika produktů pro úvodní stránku,
  • získání produktů pro danou kategorii,
  • získání dat pro detail produktu,
  • hledání produktů na danou frázi,
  • kontrola a vložení objednávky do databáze.

Všechny ostatní operace budeme zatím řešit na straně klienta. V prohlížeči bude uložen i obsah košíku, nicméně před vložením do databáze bude objednávka samozřejmě zkontrolována.

Podíváme-li se na operace, které budou zpracovány přes API, můžeme si všimnout, že s výjimkou vyhledávání a vkládání do databáze se dají všechny výborně kešovat. Třeba taková stránka FAQ se bude měnit jen výjimečně, proto můžeme na serveru přímo vygenerovat a uložit soubor faq.json a případný dotaz na FAQ pak může rovnou zpracovat třeba nginx a požadavek nedojde vůbec k Node.js. Pokud pro samotné vyhledávání použijeme specializovanou databázi jako ElasticSearch, se kterou se komunikuje také přes REST API, pak se bude z pohledu uživatelské části komunikovat s databází pouze při vložení objednávky do databáze. Celý e-shop je tak vlastně statický web složený z HTML šablon a JSON souborů.

Návrh REST API

Dále budeme navrhovat samotné API z pohledu uživatelské části webu. Každá z URL bude prefixovaná řetězcem /api/v1. Všechna níže uvedená URL se týkají pouze komunikace s API, nejde o URL, která uvidí zákazník.

Získání seznamu kategorií pro menu

Budeme chtít získávat všechny kategorie ve stromové struktuře, takže dotaz bude stejný jako v administraci:

GET /categories

Jako návratovou hodnotu můžeme očekávat pole se všemi kategoriemi na nejvyšší úrovni (případné podkategorie budou vráceny jako položka rodičovské kategorie). Jedna vrácená kategorie bude mít tyto atributy:

  • Název (name)
  • URL (url)
  • Podkategorie (children, pole potomků, opět mohou mít položky název, URL a podkategorie).

Získání seznamu stránek

Pro získání všech stránek použijeme klasický HTTP GET požadavek a přidáme také seznam polí, které chceme vrátit (jinak bychom měli vrátit všechny):

GET /pages?fields=name,url

Návratovou hodnotou je pole se všemi stránkami, přičemž každá obsahuje název a URL. Parametr fields budeme přidávat i u dalších adres, pokud budeme chtít vrátit jen určité položky.

Získání detailu stránky

Získání jedné stránky je jednoduchý dotaz:

GET /pages?url={url}

Pokud stránka s touto URL neexistuje, bude vrácen HTTP kód 404, jinak HTTP kód 200 a v odpovědi budou tyto položky:

  • Název (name)
  • URL (url)
  • Text (text)

Adresa nemá formát /pages/{id} , protože při HTTP požadavku na danou stránku nemáme k dispozici ID stránky. To budeme mít až v administraci, proto má dotaz na stránku tento formát.

Získání produktů pro kategorii

V kategorii se budou vždy vypisovat jen produkty z dané kategorie.

GET /products?category={kategorie}&limit={kolik}&offset={odkud}

Jako návratovou hodnotu očekáváme pole se všemi produkty, přičemž jeden vrácený produkt bude obsahovat tyto položky:

  • Název (name)
  • URL (url)
  • Krátký popisek (perex)
  • Fotografie (photo)
  • Výrobce (producer)
  • Kategorie (category, název a url kategorie)
  • Dostupnost (availability)
  • Cena vč. DPH (price)
  • DPH (vat)

URL by také mohlo být /categories/{id kategorie}/products. Protože však později budeme přidávat sofistikovanější filtrování produktů v kategorii, bude výhodnější nechat tento formát URL.

Získání produktů pro úvodní stránku

Na úvodní stránce se budou vypisovat produkty, které jsou označeny atributem homepage. Mezi požadavky tento atribut uveden nebyl a vznikl, až když jsme začali navrhovat úvodní stránku.

GET /products?homepage=true

Jako návratovou hodnotu budeme očekávat pole všech produktů s tímto atributem. Jeden vrácený produkt bude mít stejný formát jako produkty vrácené v kategorii.

Získání produktu pro detail produktu

V detailu produktu budeme vracet téměř všechny atributy, které máme u produktu uloženy:

GET /products?url={url}

V případě, že produkt nebude na dané URL nalezen, bude vrácen HTTP kód 404, jinak očekáváme HTTP kód 200 a tělo odpovědi bude obsahovat tyto položky:

  • Název (name)
  • URL (url)
  • Kód (code)
  • Krátký popisek (perex)
  • Dlouhý popisek (text)
  • Fotografie (photos, pole)
  • Parametry (parameters, pole)
  • Výrobce (producer)
  • Kategorie (category, název a url kategorie, pole)
  • Dostupnost (availability)
  • Cena vč. DPH (price)
  • DPH (vat)

Vyhledávání produktů

Vyhledávat budeme pouze na kolekci s produkty. URL bude vypadat takto:

GET /products?q={dotaz}&limit={kolik}&offset={odkud}

Jako návratovou hodnotu budeme očekávat:

  • celkový počet nalezených produktů (count)
  • vrácené produkty dle stránkování (jeden záznam bude mít stejný formát jako v případě získání produktů pro kategorii)

Vložení objednávky do databáze

Obsah košíku bude uložen na straně klienta (v prohlížeči) a vložení objednávky proběhne metodou POST:

POST /orders

Jako obsah požadavku zašleme ve formátu JSON data z nákupního košíku (kód produktu, počet ks), zadanou doručovací a případně kontaktní adresu a typ dopravy a platby.

V případě, že bude objednávka v pořádku vložena do databáze, bude vráceno číslo vytvořené objednávky. V opačném případě bude navrácena informace o chybě, kvůli které nebylo možné objednávku zpracovat.

Co dále

V dalším kroku vytvoříme rozhraní API v Apiary a následně základní podobu všech šablon, které pak rozhýbeme pomocí frameworku AngularJS.

Na tvorbě tohoto článku se svými připomínkami podílel také Pavel Lang. Díky!

Komentáře

Subscribe
Upozornit na
guest
19 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
https://tomasfejfar.mojeid.cz/#bLGPpVT97A

Jak to Kubo bude fungovat pro vyhledávače, když to bude JS frontend k REST API. Nehodí se tenhle typ aplikace spíš na „aplikace“ (typu Gmail, Facebook, atp) – prostě na stránky, které nechceš indexovat?

vidya

je s tym rochu roboty ale ide to. vecsinou sa renderuje obsah pre vyhladavace v niecom ako phantomjs. nedavno som robil mobilny web v angularjs, backend je express kde mam nainstalovany middleware Crawlme. ked detekujem ze mi prisiel request z googlu, tak mu neposlem standardny response ale to vyrenderujem do obycajneho html tymto pluginom (interne pouziva headless browser – zombie.js)

5o

Toto nechapem. To akoze ako byt kuul guru a naprogramovat eshop co najzlozitejsie?

Aky to ma prakticky vyznam? O rok, dva vyjde zase nieco exotickejsie, nejaky prekladac prekladaneho kodu, nejaky superscript alebo co. Bude sa v nom lepsie programovat? Neviem, ale viem, ze je to o vysledkoch. Mat eshop, ktory nic nevie, bez poriadneho CMS ale na najnovsom jazyku mi prijde zbytocne. Navyse zhanat profikov, ktory to vedia je drahe. A to nehovorim o podpore na hostingoch.

Akosi stale nechapem tie prakticke vyhody (v ralnom zivote), oproti PHP napr.

5o

Vdaka za vysvetlenie. Tieto vyhody chapem. Chapem ze Node.js sa hodi na real-time aplikacie. Ten sposob vyvoja aky opisujes sa da podobne aplikovat aj na PHP + to cachovanie (mimo to ze sa nacitava cely framework, ale ani to nie je pravda, iba sa vykona dispatch cycle, ale aj to sa da obyst statickym cachovanim), to je mimo. Rozdiel s Node je v tom, ze server sa sprava ako service voci aplikaciam (CMS atd). Lenze som si nieco precital o tom, ze je to problem, ze Node bezi na jednom procaku, dalej kedze je to dlho zijuci proces, nastavaju pri (nedobre napisanych) aplikaciach mem leaks. Dalej ak jeden request vyhodi error tak padne cely Node, cize treba osefovat hosing dalsimi servicami co ho budu drzat nazive atd. Takze ked sa nad tym tak zamyslim, nad schopnostami vacsiny programatorov vo firmach atd, kde maju problem pochopit studenti OOP v PHP, tak prakticke vyhody ma Node.js iba teoreticky (myslim pri tvorbe klasickych web stranok).

5o

Myslim, ze Node je idealny na HTML5 hry s WebSockets. Taky clanok by som uvital urcite viac, mozno aj ostatny.

petersirka

1. node môžeš spustiť aj vo viacerých vláknach (len je to trochu iné) viď. http://petersirka.sk/development/spustenie-partial-js-v-module-cluster/ … Filozofia node.js je veľmi dobrá, väčšinou ti jedno vlákno stačí na komunikáciu s klientom.

2. Ak jeden request vyhodí error, tak padne celá aplikácia … Toto je vec používaného frameworku, ak používaš node.js holí bosí áno, ak používaš framework – nie. To isté máš v PHP alebo v .NET. Čo sa stane ak vo Windwose alebo v OSX aplikácia vyhodí Application Exception? Padne celá aplikácia (pokiaľ ju kóder nezachytí).

Mne príde node.js menej náchylnejší na chyby, pretože nemusíš riešiť multithreading.

Node.js je holý bosí, je to framework, do ktorého si buď nákodiš frameworku (ako ja) alebo použiješ existujúci framework napr. expressjs.

Každý jazyk má niečo lepšie a horšie. Netreba sa pozerať na node.js ako na spasenie, node.js priniesol trošku iný prístup ku kódovaniu a to najpodstatnejšie je to, že je to JavaScript.

petersirka

Podľa mňa je to veľmi zlé riešenie, pretože Googlu dávaš nereálne výsledky, pozor aby ťa nepenalizoval. Generovať obsah u klienta v internetovom obchode cez JS mi príde ako veľmi zlá úchylka :-) a bodaj by som sa mýlil.

vidya

huh ??? dostane presne to iste co klient. je to uplne standardne riesenie pri tomto type aplikacii.

https://tomasfejfar.mojeid.cz/#bLGPpVT97A

Ne každý robot to podporuje (čti: žádný jiný)

vidya

pravda. povodne som to neriesil ale vas koment ma prinutil sa trochu zamysliet a zistil som ze zombie.js podporuje history api, takze pre roboty a browsre s podporou hist. api skusim generovat standardne url a hashbang urls budu ako fallback (v mojom pripade by sa to tykalo len starsich androidov). myslim ze by to mohlo fungovat.

petersirka

Áno AJAX crawling je bohužiaľ jediná možnosť, ktorá nebude veľmi efektívna voči klasickým webom (možno sa mýlim). Hádať sa určite nejdem a ak ti to funguje – potom je to skvelé.

Tomáš Fejfar

No, já tam nevidim ten přínos používání node.js – pokud pak musíš vyvinout relativně velké úsilí, aby to bylo aspoň minimálně použitelné. Jakože je hezké, že to máš celé AJAXové, ale ve výsledku mi dává větší smysl nette a komponenty – kdy si to v případě nouze prostě celé vyrenderuješ na serveru a když je JS, tak se pošle jen kousek…
Samozřejmě chápu výhody node před PHP, Pythonem a jinými interpretovanými jazyky, ale podle mého je eshop přesně ten typ aplikace pro kterou je node extrémně nevhodý. Jsem fakt zvědav, jestli se tenhle můj názor do konce seriálu nějak zásadněji změní, ale zatím to tak nevypadá (resp. držím si ho od prvního dílu, ale tam mi přišlo předčasné to vytahovat).

Tomáš Fejfar

Samozřejmě, když píšu „nodejs“ myslím „node,js jako REST API a k tomu AngularJS“ ;)

Tomáš Jurman

Ahoj
článek se mi velmi líbí. Číst o tom jak je možné používat nové technologie jako node.js a Angular, a vidět jak navrhovat REST API je krásné a poučné.
Jsem rád, že si mohu na Zdrojáku takové progresivní články přečíst.

Kdo chce programovat eshop v PHP nechť si koupí knihu PHP od pana Koska.

Zdraví
echo „Tomáš“;

cl1d3

Zaujimalo by ma ako je to s kompatibilitou. Takto naprogramovana aplikacia pojde vo vacsine prehliadacov v pohode? Myslim iPad, iPhone, SAMSUNG Galaxy Tab, IE, Firefox, Opera, Safari …
Paci sa mi napad programovat veci takouto formou len ci to neprinesie v praxi viac problemov ako radosti spoliehat na JavaScript.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.