Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Využití technologie GraphQL pro webové aplikace
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Informační systémy a technologie
Autor: Bc. Lukáš Kadoch
Vedoucí diplomové práce: Ing. Jan Černý Praha, prosinec 2020
Prohlášení
Prohlašuji, že jsem diplomovou práci Využití technologie GraphQL pro webové aplikace vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Praze dne 7. prosince 2020 ...
Bc. Lukáš Kadoch
Poděkování
V prvé řadě bych chtěl poděkovat panu Ing. Janu Černému za vedení práce a za cenné rady, které mi velmi pomohly při tvorbě. Dále bych poděkoval své rodině a přátelům, kteří za mnou stáli a podporovali mě po celou dobu studia.
Abstrakt
Diplomová práce se zabývá využitím moderní technologie GraphQL k vytvoření prototypu aplikace pro propojení zaměstnanců, projektů a technologií. Pro dosažení tohoto cíle je práce rozdělena na několik dílčích cílů, které společně vedou k jeho řešení. Jednotlivé cíle tvoří popis použitých technologií, vytvoření aplikačního serveru, implementace základních modulů, propojení s externími službami a definice klíčových rolí. Součástí je i využití agilní metodiky Scrum, která je nastavena podle potřeb projektu i budoucího vývoje. Posledním cílem je srovnání rychlosti odezvy se současnou verzí aplikace. Přínosem práce je vytvořený prototyp, který bude sloužit jako jádro pro přestavbu současného řešení ve společnosti. To povede k navýšení kvality aplikace pro všechny zaměstnance, kteří ji využívají. Práce je rozdělena do dvou hlavních bloků. První blok obsahuje zejména teoretickou část, jako je popis technologií, zvolenou metodiku a GraphQL. Druhý blok se zabývá samotným vývojem řešení a průběhu iterací v rámci metodiky Scrum. Součástí je implementace modulů, konfigurace prostředí, technická vylepšení a správa metodiky. Závěrečná kapitola obsahuje i souhrn výsledků a měření v rámci definovaných cílů.
Klíčová slova
GraphQL, Javascript, Typescript, API, Node.js, agilní vývoj, Scrum
Abstract
This diploma thesis aims for use of modern technology GraphQL to implement prototype application for employees, projects, and technologies connection. The main goal of this thesis is divided into multiple partial goals which leads to its solution. These goals include description of chosen technologies, creation of application server, implementation of basic modules, connection to external services and definition of key roles. It also includes agile methodology Scrum, that is configured to its needs for the project and future development.
Last goal is to compare latency speed with current version of the application. The benefit of the thesis is the implemented prototype which will serve as a core for reconstruction of current solution in the company. This will lead to increase the quality of use for all employees. Thesis is divided into two main sections. First section contains theoretical part such as description of technologies, Scrum methodology and GraphQL. Second section describes the implementation of the solution and iteration progress in Scrum. It contains modules implementation, environment configuration, technical improvements, and methodology management. Final chapter also includes summary of all goals and results of measurement for latency comparison.
Keywords
GraphQL, Javascript, Typescript, API, Node.js, agile development, Scrum
Obsah
Úvod ... 11
1 Rešerše ...14
1.1 Způsob a zdroje vyhledávání ...14
1.2 Výsledky vyhledávání ...14
2 Teoretická část ... 17
2.1 Metodika ... 17
2.1.1 Agilní metodiky ... 17
2.1.2 Agilní manifesto ... 17
2.1.3 Scrum ... 18
2.1.4 Trello ... 21
2.1.5 Využití metodiky a nástrojů v práci autora ... 22
2.2 Technologie ... 23
2.2.1 Javascript ... 23
2.2.2 Typescript ... 24
2.2.3 Node.js ... 25
2.2.4 Relační databáze a SQL ... 26
2.2.5 Objektově relační model (ORM) ... 27
2.2.6 HTTP a REST API ... 28
2.2.7 Docker ... 29
2.3 GraphQL ... 30
2.3.1 Dotazovací jazyk GraphQL ... 30
2.3.2 GraphQL schéma ... 31
2.3.3 GraphQL metody ... 34
2.3.4 Stránkování ... 35
2.3.5 Řešitel (Resolver) ... 36
2.3.6 Validace ... 37
2.3.7 Vykonání (Exekuce) ... 37
2.3.8 Introspekce... 38
2.3.9 Výhody ... 38
2.3.10 Nevýhody ...41
2.3.11 Apollo ... 42
2.3.12 Projekty využívající GraphQL ... 42
3 Praktická část ... 44
3.1 O aplikaci Hakkastack ... 44
3.2 Současný stav ... 45
3.3 Zadání a kritéria pro vývoj ... 47
3.3.1 Moduly ... 47
3.3.2 Připojení firemních služeb ... 47
3.3.3 Přidání rolí ... 48
3.3.4 Technická vylepšení ... 48
3.4 Vývoj v metodice Scrum... 50
3.4.1 Nastavení metodiky ... 50
3.4.2 Iterace ... 51
3.4.3 Trello ... 53
3.5 Prototyp... 54
3.5.1 Prostředí a konfigurace ... 54
3.5.2 Použité knihovny třetích stran ... 56
3.5.3 Aplikační server Express a Apollo ... 57
3.5.4 Databázový model ... 58
3.5.5 TypeORM ... 59
3.5.6 TypeGraphQL ... 60
3.5.7 Externí služby ...61
3.5.8 Přihlášení ... 63
3.5.9 Modul Zaměstnanci ... 66
3.5.10 Modul Projekty ... 69
3.5.11 Modul Technologie ... 72
3.5.12 Modul Klienti ... 74
3.5.13 Modul Kurzy ... 76
3.5.14 Optimalizace, utility a formát ... 81
3.6 Shrnutí dosažených kritérií... 83
3.6.1 Rychlost odezvy ... 83
3.6.2 Role v aplikaci ... 85
3.6.3 Shrnutí a zhodnocení ... 85
Závěr ... 88
Použitá literatura ... 90 Přílohy ... I Příloha A: Konfigurace formátovacích a lintovacích pravidel ... I Příloha B: Struktura dotazu při testování rychlosti odezvy ... III
Seznam obrázků
Obrázek 1: Výsledky vyhledávání Google Scholar (autor) ...14
Obrázek 2: Princip metody Scrum (SCRUM.ORG, 2020) ... 18
Obrázek 3: Ukázka aplikace Trello (TRELLO, 2020) ... 22
Obrázek 4: Aplikace Trello v druhé iteraci (autor) ... 54
Obrázek 5: Databázové schéma ... 58
Obrázek 6: Kontext aplikace ... 59
Seznam tabulek
Tabulka 1: Mapování GraphQL typů na Typescript ... 32Tabulka 2: Popis zápisů typu List ... 33
Tabulka 3: Požadavky na rychlost odezvy ... 50
Tabulka 4: Výpis user stories ... 51
Tabulka 5: Průběh iterací ... 52
Tabulka 6: Štítky v aplikaci Trello ... 53
Tabulka 7: Hardwarová specifikace ... 54
Tabulka 8: Softwarová specifikace ... 55
Tabulka 9: Výpis knihoven třetích stran v aplikaci ... 56
Tabulka 10: Výsledky testu rychlosti odezvy ... 84
Tabulka 11: Shrnutí dosažení cílů a požadavků zadání prototypu ... 86
Seznam výpisů programového kódu
Výpis kódu 1: Ukázka dotazovacího jazyka GraphQL (autor) ... 31
Výpis kódu 2: Ukázka GraphQL schéma ... 31
Výpis kódu 3: Ukázka typu Výčet ... 33
Výpis kódu 4: Ukázka struktury Rozhraní ... 33
Výpis kódu 5: Ukázka struktury Spojení ... 34
Výpis kódu 6: Ukázka Vstupního typu ... 34
Výpis kódu 7: Ukázka typů GraphQL metod ve schématu ... 34
Výpis kódu 8: Ukázka metody Dotaz ... 35
Výpis kódu 9: Ukázka metody Předplatné ... 35
Výpis kódu 10: Ukázka stránkování limit a offset ... 36
Výpis kódu 11: Ukázka JSON dat z GraphQL ... 37
Výpis kódu 12: Ukázka dotazu introspekce (GRAPHQL, 2020) ... 38
Výpis kódu 13: Hlavní iniciační soubor index.ts ... 57
Výpis kódu 14: Konfigurační soubor TypeORM ... 60
Výpis kódu 15: Ukázka vytvoření entity Zaměstnanec ... 60
Výpis kódu 16: Ukázka TypeGraphQL na entitě Zaměstnanec ... 60
Výpis kódu 17: Ukázka vrstvení notací v TypeGraphQL ...61
Výpis kódu 18: Vytvoření instance axios ...61
Výpis kódu 19: Cachování externích dat ... 62
Výpis kódu 20: Ukazatel dat v cachi ... 62
Výpis kódu 21: Konfigurace AD ... 63
Výpis kódu 22: Funkce ověření totožnosti ... 63
Výpis kódu 23: Přihlašování ... 65
Výpis kódu 24: Ověření požadavku uživatele ... 65
Výpis kódu 25: Funkce výpisu zaměstnanců ... 66
Výpis kódu 26: Funkce přidání a změny zaměstnance ... 68
Výpis kódu 27: Funkce deaktivace zaměstnance ... 69
Výpis kódu 28: Funkce výpisu projektů ... 70
Výpis kódu 29: Funkce přidání a změny projektu ... 71
Výpis kódu 30: Funkce deaktivace projektu ... 71
Výpis kódu 31: Funkce výpisu technologií ... 72
Výpis kódu 32: Funkce přidání a změny technologie ... 73
Výpis kódu 33: Funkce deaktivace technologie ... 74
Výpis kódu 34: Funkce výpisu klientů ... 75
Výpis kódu 35: Funkce přidání a změny klienta ... 75
Výpis kódu 36: Funkce deaktivace klienta ... 76
Výpis kódu 37: Funkce výpisu kurzů ... 77
Výpis kódu 38: Funkce přidání a změny kurzu ... 78
Výpis kódu 39: Funkce deaktivace kurzu ... 79
Výpis kódu 40: Funkce přihlášení zaměstnance ke kurzu ... 80
Výpis kódu 41: Funkce odhlášení zaměstnance z kurzu ... 80
Výpis kódu 42: Optimalizace výkonu databáze ... 81
Výpis kódu 43: Logování ... 82
Výpis kódu 44: Ukázka validace délky kurzu ... 82
Seznam zkratek (akronyma)
API Application Programming
Interface
JSON JavaScript Object Notation
ORM Object Relational Mapping
URI Uniform Resource
Indentifier
URL Uniform Resource Locator
UI / GUI Graphical User Interface
IDE Integrated Development
Environment
CMS Content Management
System
CRUD Create Read Update Delete
SP Story Point
DI Dependency Injection
AD Active Directory
JWT JSON Web Token
Úvod
V dnešní době je vývoj moderních webových aplikací velmi populární téma ve světě informačních technologií. Každá společnost vlastní své webové stránky nebo portály, ve kterých uvádí svůj byznys nebo je používá jako informační zdroj. Střední a větší firmy ovšem využívají i jinou formu těchto aplikací, a to jako interní systémy. Aby byli zaměstnanci spokojení a nebyli prací se systémem frustrováni, je třeba dbát na rychlou odezvu a zejména přínos této aplikace do jejich každodenního pracovního života.
Tato práce má za cíl pomocí moderní technologie GraphQL oživit stávající interní systém jisté společnosti a docílit tak zrychlení aplikace a možnosti jednoduché údržby pro vývojáře do budoucna.
Motivace výběru tématu
Vývoj webových aplikací je má hlavní pracovní náplň a mimo jiné i dlouhodobý koníček.
Když jsem se před lety začal zajímat o vývoj, vždy jsem měl tendence psát kvalitní a dobře čitelný kód. V některých situacích mě ovšem tato „obsese“ nepřinesla jen to dobré. Ve vývoji je nejdůležitější se soustředit na přidanou hodnotu pro zákazníka než na vlastní touhy ideální kódové báze.
Společnost, ve které pracuji, využívá jako hlavní interní systém pro zaměstnance aplikaci Hakkastack, kterou jsem vytvořil já společně s dalším kolegou. Když jsme tuto aplikaci tvořili, nevěděli jsme, jestli bude mít úspěch, jelikož byla složena z poměrně jednoduchých technologií a modulů. Během prvního roku v produkci se ovšem stala velmi populární, jak z pohledu managementu, tak zaměstnanců.
Tím, jak aplikace rostla o další funkcionality, se ovšem kvalita kódu začala značně snižovat.
To bylo dáno zejména tím, že se na vývoji aplikace začalo střídat mnoho vývojářů a nebyla nastavena pravidla pro psaní kódu. Během užívání v dalších letech nastaly i problémy s rychlostí zpracování požadavků a celkové škálovatelnosti, která zahrnovala i nemožnost rozdělení rolí v systému.
Tato situace mě velmi motivovala k zamyšlení, jak v průběhu let zaměstnanci aplikaci používali a hledat největší úskalí. Rozhodl jsem se tedy vytvořit kvalitní jádro této aplikace, které bude stavět na moderních technologiích a bude dodržovat daná pravidla pro vývoj, předcházející problémům se střídáním vývojářů v dalších letech. Jelikož je výkon serveru při zpracování požadavků hlavním zdrojem současných problémů, navrhl jsem jako zásadní změnu přechod architektury do světa GraphQL.
Cíle práce
Hlavním cílem této práce je implementace prototypu aplikace pro propojení projektů, technologií a zaměstnanců založeném na technologii GraphQL, která bude sloužit jako podklad pro přestavbu aktuálního řešení využívající REST API.
Tento cíl je dále rozveden do dílčích cílů, které společně vedou k jeho řešení:
• Využití agilní metodiky Scrum pro vývoj prototypu, včetně úpravy jejího nastavení v rámci práce. Součástí je i použití aplikace Trello pro správu požadavků.
• Popis jednotlivých použitých technologií, včetně jejich konkrétního využití v prototypu.
• Podrobný popis technologie GraphQL a její výhody a nevýhody.
• Vytvoření aplikačního serveru pomocí programovacího jazyka Typescript v prostředí Node.js propojeného s hlavní technologii GraphQL, která bude sloužit jako komunikační vrstva mezi klientskou a serverovou stranou.
• Propojení aplikace s dalšími službami společnosti, které přináší dodatečné informace o zaměstnancích a projektech.
• Vytvoření základních modulů aplikace, kterými jsou zaměstnanci, technologie, projekty, klienti a kurzy.
• Přidání základních rolí do systému, které budou škálovatelné bez nutnosti větších zásahů do architektury v budoucnu.
• Konfigurace pravidel pro psaní kódu a další optimalizace rychlosti požadavků pomocí cachovacích nástrojů.
• Srovnání rychlosti odezvy se současnou verzí aplikace k ověření zvýšení výkonu.
Potenciální přínosy
Nejdůležitějším přínosem této práce je samotný vytvořený prototyp, který bude sloužit jako podklad pro nové jádro aplikace Hakkastack ve společnosti. Tím, že je cílem aplikaci vylepšit o mnoho potřebných komponent, dojde k navýšení celkové kvality a zlepšení práce s touto aplikací pro všechny zaměstnance.
Dalším přínosem může být návod, jak z vybraných technologií vytvořit moderní serverové řešení ve světě Javascriptu v rámci metodiky Scrum. To zahrnuje i známá úskalí vývoje a osvědčené praxe.
Struktura práce
Struktura práce je rozdělena do tří hlavních kapitol, Rešerše, Teoretická část a Praktická část. Jednotlivé kapitoly se dělí na dílčí celky, které obsahují jádro této práce.
První kapitola obsahuje vyhledané rešerše podobných témat kvalifikačních prací. Dále jsou zde uvedeny způsoby hledání zdrojů k tomuto tématu. Jsou zde vybrány hlavní citační zdroje pro technologii GraphQL.
Teoretická část se skládá ze třech bloků. První blok představuje popis agilních metodik a vybrané metodiky Scrum. Je zde zahrnut i hlavní nástroj na správu této metodiky a také její
konfigurace v rámci práce na projektu. Druhý blok se skládá z použitých technologií v prototypu. Důležitou součástí je uvedení konkrétního použití technologie v aplikaci.
Poslední a nejdůležitější blok je popis technologie GraphQL. Tato část obsahuje všechny hlavní aspekty této technologie, včetně ukázek kódu, využití a srovnání výhod a nevýhod.
Další součástí je i konkrétní využití knihovny Apollo jako nadstavby nad GraphQL a společnosti jež tuto technologii používají v produkci.
Praktická část obsahuje šest základních sekcí. První sekce popisuje samotnou aplikaci Hakkastack, její přínos pro společnost a základní moduly, které obsahuje. Druhá sekce se věnuje současnému stavu této aplikace, jejím nedostatkům a předmětům ke zlepšení, které navazují na cíle této práce. Třetí sekce obsahuje konkrétní zadání pro vývoj prototypu schválené vedoucím práce. Součástí zadání jsou moduly k implementaci, propojení s firemními službami, role v systému a další technická vylepšení. Čtvrtá sekce je věnována agilní metodice Scrum, jejímu nastavení pro projekt, jednotlivým iteracím, požadavkům a práci s nástrojem Trello pro správu. Pátá sekce je nejobsáhlejší a popisuje celkovou implementaci prototypu. Součástí je prostředí a konfigurace tvorby, využité knihovny třetích stran a popis hlavních bloků struktur aplikace. Dalšími body jsou jednotlivé cíle práce jako jsou implementované moduly, propojení a optimalizace. Poslední sekcí praktické části je shrnutí dosažených kritérií v přehledné formě. Je zde analýza rychlosti odezvy v porovnání se současnou verzí aplikace, výčet možných rolí a jejich následná konfigurace a celkové zhodnocení splněných cílů a požadavků práce.
1 Rešerše
Tato část práce představuje způsob vyhledávání zdrojů pro tvorbu výsledného řešení a teoretické části. Vyhledávané rešerše slouží jako podklad pro agilní vývoj v metodice Scrum, návrhové vzory v technologii GraphQL a přístupy k řešení obecných problémů při implementaci serverové části aplikace pomocí Node.js.
1.1 Způsob a zdroje vyhledávání
Za hlavní zdroj vyhledávání je využit Google Scholar, který představuje webovou službu pro globální vyhledávání zdrojů, jako jsou knihy, odborné články a citace při zadání klíčových slov. Téma GraphQL není zcela běžné, tudíž je zapotřebí rozšířit vyhledávání použitím méně konkrétní škály klíčových slov. Vyhledávací dotaz vypadá následovně:
(graphql OR node.js) AND agile
Další z klíčových zdrojů je portál Theses.cz, který umožňuje uživatelům vyhledávat vysokoškolské kvalifikační práce. Pro vyhledávání jsou použita tato klíčová slova:
• graphql API
• node.js a graphql
• implementace graphql server
1.2 Výsledky vyhledávání
Z výsledků pomocí webové služby Google Scholar bylo nalezeno zhruba 4 000 záznamů.
Jedním z hlavních zdrojů je zejména kniha GraphQL API Design od autora Matthiase Biehla ze Švédska, která popisuje, jak vytvářet robustní API pomocí GraphQL. Další zajímavý zdroj je e-kniha The Road to GraphQL od Robina Wierucha, která se přímo zabývá implementací technologie GraphQL v prostředí Node.js.
Obrázek 1: Výsledky vyhledávání Google Scholar (autor)
Portál Theses.cz odhaluje, že kvalifikačních prací na dané téma je velmi málo. Jelikož GraphQL je stále poměrně mladá technologie je patrné, že více obdobných prací se bude objevovat v budoucnu. Jako hlavní rešerše na obdobné téma jsou vybrány kvalifikační práce, Porovnání implementací REST a GraphQL API od Ing. Šimona Podlipského a
Modelové řešení aplikace klient-server využívající GraphQL, kterou napsal Ing. Ondřej Zicha.
PODLIPSKÝ, Šimon. Porovnání implementací REST a GraphQL API. Praha, 2018.
Diplomová práce. Vysoká škola ekonomická v Praze. Fakulta informatiky a statistiky.
Katedra informačních technologií.
„Diplomová práce se věnuje porovnání implementací API skrze HTTP protokol s využitím principu REST a s využitím GraphQL. Odpovídá na otázku, jestli je jedna forma API vhodnější než druhá. GraphQL mezi vývojáři v posledních letech nabírá na popularitě a často bývá považováno za nadřazené REST API. Práce však dojde k závěru, že náročnost implementace je pro obě formy podobná. Zároveň je zdůrazňováno, že se možnosti využití obou forem kryjí, avšak každá má navíc něco, co ta druhá nemá, a tak hlavně záleží na kontextu, v jakém je konkrétní forma API realizována. S GraphQL se snadněji pracuje na frontendu, kde klientská aplikace nemusí transformovat získaná data, protože je API flexibilně předá ve formě, kterou si klientská aplikace sama definovala. GraphQL API zároveň samo automaticky generuje plnohodnotnou dokumentaci, zatímco REST API z části vyžaduje manuální tvorbu dokumentace, na což je z pohledu vývoje negativně nahlíženo vzhledem ke vznikajícímu prostoru pro chyby. Na druhou stranu REST API lépe využívá vlastností HTTP protokolu na rozdíl od GraphQL, které musí vynalézat vlastní konvence. Obě formy tak mají své výhody a nevýhody, nedá se však jednoznačně říci, že by jedna byla lepší než ta druhá. Zároveň je možné využívat obě formy najednou podle toho, kde je která vhodnější. Navzájem se nijak nevylučují. Práce také úspěšně demonstruje ideální techniky realizace obou způsobů API.“ (PODLIPSKÝ, 2018)
Autor v práci porovnává dva přístupy k implementaci API. Na jedné straně využívá vzor REST a na druhé právě technologii GraphQL. Práce také obsahuje ukázku použití zmíněných technologií na jednoduché aplikaci synchronizace dopravních kamer. Ze závěrů práce vyplývá, že se nedá jednoznačně určit, která technologie je výhodnější a záleží tudíž na kontextu, ve kterém se API tvoří.
Autor zmiňuje, že technologie REST se dá použít v podstatě na jakékoliv řešení, za to GraphQL se více hodí na řešení, kde klient a server nejsou svázáni nebo server využívá více klientů najednou s různými potřebami.
Hlavním rozdílem této práce oproti práci autora je, že se více zaměřuje na implementaci reálného systému v praxi, který řeší konkrétní firemní problém a je více zaměřen na technologii GraphQL. Tato práce nemá za cíl porovnávání GraphQL a REST, avšak využívá rozhraní REST jako jednu z interních služeb firmy.
Zicha, Ondřej. Modelové řešení aplikace klient-server využívající GraphQL. Praha, 2018.
Diplomová práce. Vysoká škola ekonomická v Praze. Fakulta informatiky a statistiky.
Katedra informačního a znalostního inženýrství.
„Tato diplomová práce se zabývá technologií GraphQL a její aplikací na modelové řešení klient-server. První část je věnována teoretickým aspektům komunikace mezi dvěma propojenými zařízením sítí internet, tradičnímu přístupu REST API a jeho porovnání s konceptem GraphQL jak na straně serveru, tak i na straně klienta. V práci jsou rozebírány principy a metodiky tvorby REST API, specifikace GraphQL, výhody a rozdílnosti oproti tradičnímu přístupu REST API, návrhové principy, typový systém, SDL jazyk a metody introspekce a validace kódu, tvorba dotazu a mutací za účelem získávání a modifikace dat v databázi. Praktická část je zaměřena na použití této technologie s cílem vytvoření modelového řešení webové aplikace komunikující mezi serverovou a klientskou částí prostřednictvím technologie GraphQL. V úvodu této části jsou popsány implementační nástroje, které výsledná aplikace používá. Dále jsou popisovány jednotlivé části aplikace ve sledu reflektujícím postup jejího vývoje až po její samotné spuštění. Závěrečná část shrnuje výsledek a naplnění cílů této práce spolu s návrhem na možnost jejího dalšího rozšíření.“ (ZICHA, 2018)
Autorova práce se zabývá porovnáváním technologií REST a GraphQL. Rozdílem oproti předchozí práci je technologie, ve které je API implementováno. Zde je použita technologie Node.js, přitom v předchozí práci je server řešen v jazyce PHP. Dalším rozdílem je implementace klientské strany pomocí technologie React.js.
2 Teoretická část
První z hlavních kapitol práce se zabývá teorií a základní problematikou vytvářeného řešení.
Podkapitola Metodika popisuje využití agilního přístupu při vývoji prototypu aplikace a zároveň zahrnuje kontext a prostředí, ve kterém vývoj aplikace probíhá. Další podkapitola zahrnuje základní popis jednotlivých použitých technologií projektu a jejich konkrétní zapojení u implementovaného řešení. Poslední podkapitola se zabývá hlavní technologií práce – GraphQL. Tato podkapitola detailně popisuje, jak technologie funguje, její vlastnosti, výhody, nevýhody a její přínos pro implementované řešení.
2.1 Metodika
Pro vývoj řešení je zvolena agilní metodika Scrum. Tato kapitola se zabývá základním popisem agilních metodik a k čemu slouží. Zároveň obsahuje i rozdíl oproti tradičním metodikám a důvod zvolení právě metodiky Scrum v rámci externího prostředí a kontextu vytvářeného řešení. Součástí je i zvolený jednoduchý nástroj pro správu.
2.1.1 Agilní metodiky
V dnešní době jsou agilní metodiky velmi populární. Velké společnosti jako jsou Google, Yahoo nebo Microsoft mají v mnoha svých projektech použitu právě jednu z metodik agilního vývoje pro pružnou změnu specifikace, rychlé dodávání a nižší náklady na zpracování dokumentace. (SHORE, 2008)
2.1.2 Agilní manifesto
Skládá se ze čtyřech základních pilířů, které představují výhody a klíčové prvky agilního vývoje a jeho přístupu k řešení jednotlivých oblastí v rámci celého hlavního procesu v projektu.
Lidé a jejich spolupráce před procesy a nástroji
Jedním z hlavních pilířů je spolupráce zapojených vývojářů, testerů, analytiků a dalších rolí, které společně pracují na projektu. Interakce mezi nimi je v agilním světě velmi důležitá.
Oproti tradičním metodikám zde komunikují všechny zainteresované role během celého vývoje projektu, aby dosáhly nejvyšší kvality a zejména přidané hodnoty pro zákazníka, který může sledovat a interagovat jednotlivé osoby a jejich práci.
Fungující software před obsáhlou dokumentací
Druhým pilířem je přednost fungujícího softwaru před psaním rozsáhlé dokumentace, které může být velmi nákladné. Důraz je kladen zejména na investování času do výsledného
produktu a tím docílení připravenosti pro produkční prostředí bez kritických chyb. Základní dokumentace je vytvářena při samotném psaní kódu.
Spolupráce se zákazníkem před sjednáváním smluv
Třetím pilířem je spolupráce realizačního týmu se zákazníkem. Významnou předností tohoto přístupu je šetření času při realizaci podmínek smluv a dalších bodů. Pokud má zákazník požadavek na změnu ve struktuře projektu nebo zásadní zásah do produktu, lze tyto změny řešit v rámci domluv při setkání. Sjednávání smluv je velmi neflexibilním řešením při realizaci agilních projektů.
Reakce na změnu před dodržováním plánu
Posledním pilířem je rychlá reakce na požadovanou změnu v produktu. Tato výhoda oproti rigorózním metodikám je zásadní a v mnohých případech zlomová při výběru mezi tradičním a agilním přístupem. Zákazník má možnost kdykoliv během vývoje změnit svoje požadavky a přidat funkcionalitu do produktu tak, aby splňovala jeho potřeby. Zákazníci často využívají změn v reakci na „tvarování“ jejich produktu nebo při změně potřeb jejich klientů. Tím lze docílit, že výsledný produkt bude opravdu na míru při aktuální situaci.
(APKE, 2015)
2.1.3 Scrum
Jedná se o nejpopulárnější agilní metodiku, která se skládá ze sady událostí (neboli ceremonií), rolí, artefaktů a nejlepších praktik pro vývoj a organizaci projektu. Scrum je poměrně jednoduchý framework, který zajišťuje optimální spolupráci při budování softwaru, ale v mnoha případech je ohýbán různými směry podle potřeb jednotlivých projektů.
Obrázek 2: Princip metody Scrum (SCRUM.ORG, 2020)
Role
Metodika Scrum se skládá z několika rolí, které mají specifický účel během budování projektu. Důležitou vlastností všech zúčastněných rolí je sebeorganizace a schopnost pracovat v rámci projektu bez zásahu vnějších zdrojů. Scrum definuje tři základní role.
Vlastník produktu (Product Owner)
Nejdůležitější rolí z pohledu zákazníka je takzvaný „vlastník produktu“. Jedná se o roli, která zastupuje zákazníka. V některých případech je tato role zastoupena členem společnosti, která produkt vyvíjí. Vlastník produktu má na starosti zejména přípravu požadavků, které je zapotřebí vykonat. Dále akceptační kritéria, která definují body pro splnění požadavku a jeho uzavření. V neposlední řadě je vlastník produktu i povinen zodpovědět případné otázky ostatních rolí. Ve výjimečných případech, pokud je vlastník produktu technicky schopný, pomáhá i vybírat technologie, které by měly být implementovány.
Tým (Development Team)
Vývojový tým se skládá ze všech rolí nutných pro vývoj produktu. To znamená, že sem patří vývojáři, analytici, testeři a další, kteří technicky přispívají do budování projektu. Podstatou schopností vývojového týmu je jeho sebeorganizace. Budování produktu by mělo probíhat bez nutnosti zásahu externích rolí. Je samozřejmé, že netechnické otázky je nutné směřovat na vlastníka produktu nebo Scrum Mastera.
Scrum Master
Každý tým musí mít svého lídra, který zajišťuje, aby chod projektu byl hladký. V metodice Scrum tuto roli obstarává Scrum Master. Jeho hlavní povinností je správa nástroje pro agilní vývoj jako je například „JIRA“ a moderování všech událostí, které jsou obsaženy v této metodice. V některých případech obstarává roli Scrum Mastera projektový manažer. Toto běžně platí pro velké organizace, které používají agilní vývoj na části svých projektů.
Důležitou součástí práce Scrum Mastera je i komunikace s vlastníkem produktu o organizaci a správě.
Události
V agilní metodice Scrum se repetitivně koná několik událostí, které tvoří dohromady průběh celého procesu vývoje produktu. Každá z událostí má svou specifickou roli a váhu. Mnoho společností některé z událostí vynechávají anebo modifikují pro potřeby projektu v daném prostředí nebo kontextu.
Stand-up (Daily Scrum)
Jedná se o každodenní událost, kde jednotliví členové projektu probírají aktuální situaci.
Každý člen zmíní, jaké činnosti dělal předchozí den, které bude dělat dnes a zda ho v řešení blokují některé závislosti. Toto setkání trvá zhruba 10-15 minut, ale velmi záleží na rozsahu
projektu, ale jen po dohodě všech členů. Stand-up je moderován Scrum Masterem, který by měl mít přehled o situaci na projektu.
Sprint
Hlavní událostí každého projektu, který využívá metodiku Scrum je takzvaný Sprint. Jedná se o iteraci v rámci celého průběhu vývoje produktu. Tato iterace probíhá v rozmezí 2-4 týdnů. Součástí iterace je přírůstek funkcionality pro výsledný produkt. Podstatnou informací je, že na konci každé iterace by měl být funkční celek produktu, což znamená, že vybrané úkoly by měly tvořit propojení částí produktu. V některých případech je délka iterace proměnlivá. To se stává zejména v situaci, kdy se objeví nečekaná událost na projektu, jako je kritický výpadek nebo zásadní strukturální změny.
Plánování sprintu (Sprint Planning)
Další z událostí je plánování sprintu. Členové týmu se sejdou a domlouvají, které požadavky a úkoly provedou další iteraci. Klíčovou roli zde hraje vlastník produktu, který je zodpovědný za výběr nejprioritnějších úkolů. Součástí bývá i oprava chyb z předchozí iterace a další možná vylepšení technických prvků produktu. Poté, co jsou všechny vybrané požadavky odsouhlaseny, začíná další iterace.
Demo (Sprint Review)
Jedná se o ukázku vytvořené části produktu za předchozí iteraci. Vývojový tým předvádí hotovou práci, kterou vlastník produktu schvaluje a případně komentuje vylepšení, která je zapotřebí vykonat. Zákazníkovi je dodán takzvaný „inkrement“, neboli přírůstek, který by měl být plně funkční a měl by splňovat akceptační kritéria vedená v seznamu požadavků.
Retrospektiva (Sprint Retrospective)
Méně častou událostí je i retrospektiva. Během setkání členové týmu diskutují, jaké věci by bylo potřeba změnit. Každý z členů si připraví seznam věcí, které chce do projektu přidat (Start), zachovat (Continue) nebo zrušit či přerušit (Stop). Jednotlivé seznamy se poté kontrolují a porovnávají s předchozí retrospektivou, kde se hledají rozdíly a možná vylepšení. Tato událost by měla probíhat jednou za iteraci, avšak velmi častým úkazem je, že týmy organizují retrospektivu v delších intervalech, například jednou za tři sprinty. Je to z toho důvodu, že pokud není rozsáhlý tým, tak se uvedené seznamy vylepšení nemění.
Artefakty
Definují jednotlivé „nástroje“, které jsou potřeba k vedení metodiky Scrum. Úkolem je zejména transparentnost a souhrnné porozumění pro všechny členy projektu. Agilní metodika Scrum obsahuje tři artefakty, které zpravidla spravuje Scrum Master. Ačkoliv častou variantou správce je i vlastník produktu nebo lídr vývojového týmu.
Produktový seznam (Product Backlog)
Takzvaný „backlog“ je místo, kde jsou uchovány všechny úkoly, požadavky a uživatelské příběhy („user stories“). K úspěšnému dokončení projektu je potřeba splnit všechny uvedené úkoly, které jsou zpravidla zadávány vlastníkem produktu, včetně akceptačních kritérií. Vlastník produktu by měl úkoly seřadit podle jeho priority. Pozdější správu má na starosti Scrum Master, který dohlíží, aby vývojový tým a vlastník produktu splnili všechny potřebné akce k dokončení.
Nástěnka iterace (Sprint Board)
„Sprint board“ je část úkolů vybraná realizačním týmem pro aktuální iteraci vývoje produktu. Jednotliví členové týmu si postupně rozebírají úkoly a jejich cílem je dokončit všechny požadavky v termínu iterace. Nástěnka je rozdělena do několika sloupců, mezi kterými lze jednotlivé úkoly přesouvat. V základní definici jsou sloupce rozděleny na:
Připravené (ToDo), Ve vývoji (In Progress) a Dokončené (Done). V praxi se ovšem přidávají i další sloupce pro rychlou orientaci, v jaké fázi se úkol nachází. Příkladem může být testování nebo kontrola kódu (Code Review).
Inkrement
Jedná s o přírůstek všech dokončených úkolů během iterace. Tyto úkoly dávají dohromady celek, který ve spojení s aktuálním produktem tvoří funkční řešení. Často se zde přidávají i opravy chyb v produktu a technická vylepšení, která jsou potřeba pro hladký průběh a zvýšení kvality výsledného produktu.
Zdroje: (SCRUM.ORG, 2020), (SCHWABER, 2004), (KNIBERG, 2015)
2.1.4 Trello
Aplikace Trello je jednoduchý nástroj na správu agilního vývoje. Je vhodný zejména při použití metodiky Scrum, jelikož obsahuje funkcionalitu na vytváření „Product Backlogu“ a jednotlivých sloupců nástěnky.
Trello umožňuje jednotlivým týmům spolupracovat velmi efektivně a při jeho snadné organizaci lze docílit velmi flexibilního výsledku, který má tendenci udělat projekt živější a zábavnější. Jeho významnou výhodou je bezplatné použití, tudíž je vhodný pro jakékoliv týmy nebo organizace. Informace jsou v Trellu uložené na jednou místě, které je dostupné pro přihlášeného a verifikovaného uživatele. Jednotlivé úkoly lze jednoduše tahat pomocí myši i klávesnice mezi sloupci nástěnky. K úkolům lze přidávat popis, termín dokončení, jednotlivé body procesu vývoje i komentáře. Nástroj má i automatickou notifikační funkcionalitu, která pošle e-mail přihlášeným uživatelům o změně. Výhodou je i synchronizace pomocí mobilních telefonů a široká podpora komunity. (TRELLO, 2020)
Obrázek 3: Ukázka aplikace Trello (TRELLO, 2020)
2.1.5 Využití metodiky a nástrojů v práci autora
Agilní metodika Scrum je v této práci použita jako hlavní způsob vývoje prototypu. Výběr této metodiky je zejména v množství zkušeností autora i vlastníka produktu a je součástí požadavků v zadání práce. Pomocí iterací lze snadno vidět přibývající části funkcionality.
Významnou výhodou je i transformace aktuálního stavu projektu do budoucího vývoje bez zásadního zásahu do aktuální konfigurace.
Jednotlivé prvky metodiky Scrum jsou mírně upraveny pro minimalizaci časové náročnosti.
Role Scrum Mastera a vlastníka produktu byla sjednocena, jelikož se v tomto případě překrývají. Role týmu je zastoupena autorem, který provádí vývoj, test i analýzu. Události byly upraveny následovně:
• Délka sprintu jeden měsíc
• Stand-up dvakrát týdně
• Retrospektiva pouze jako nástroj na diskusi zlepšení produktu
Jako hlavní nástroj pro správu metodiky Scrum bylo zvoleno Trello. Výhodou je již zmíněno bezplatné využití, rychlá konfigurace a snadná údržba. Sloupce byly rozděleny na:
• Připraveno
• Ve vývoji
• Dokončeno
• Akceptováno
Poslední sloupec byl přidán z důvodu zpětné kontroly a akceptace po dokončení iterace.
2.2 Technologie
Tato kapitola obsahuje jednotlivé technologie použité pro vývoj prototypu aplikace, včetně jejich konkrétního využití v řešení.
2.2.1 Javascript
Tento jazyk byl stvořen z potřeby provádět skripty přímo v HTML dokumentu. V roce 1995 se stal Javascript novinkou a rychle se začal utvářet do podoby, se kterou budou budoucí vývojáři spokojení. Jeho hlavními pilíři, které pomohly k úspěchu, se staly následující body.
Syntaxe podobná Javě
Jedním z klíčových kroků k vytvoření Javascriptu byla tendence napodobit syntaktický zápis nejpoužívanějšímu jazyku pro programátory appletů – Javě. Vývojáři, kteří chtěli přejít od Javy k Javascriptu byli příjemně překvapení, jelikož syntaxe pro psaní aplikací a skriptů byla velmi podobná. Důležitým vylepšením byla i možnost psát kód bez tříd, typových deklarací a nutnosti používat středník na konci výrazu.
Události pro HTML elementy
Dalším významnou součástí Javascriptu jsou takzvané „události“, které umožňují elementům jednoduchou interakci s uživatelem. Například tlačítko používá metodu
„onClick“, která slouží k aplikování funkce, která se má vykonat po jeho stisknutí.
Formuláře umí zpracovávat zaznamenaná data, která uživatel zadal do příslušných polí pomocí metody „onSubmit“. V dnešní době moderních prohlížečů mají vývojáři s pomocí Javascriptu velmi flexibilní a téměř úplnou kontrolu nad veškerými událostmi, které na stránce vzniknou.
Objekty bez tříd
Třetí vlastností Javascriptu je možnost psaní objektů bez deklarace třídy. Jelikož Javascript není typovaný jazyk, mohou se zde vytvářet primitivní objekty bez nutnosti specifikování jejich přímé třídy. Pro takovou funkci byly vytvořeny takzvané prototypy, které se automaticky přidávají ke každé metodě. Interní engine aplikuje dědičnost pro pohodlné používání v kódu. Programátor tedy nemusí nic řešit a může vytvářet anonymní objekty velmi jednoduše.
Generování HTML
Poslední důležitou známkou Javascriptu je možnost vytvářet kusy HTML kódu kdekoliv v rámci dokumentu stránky. Jinými slovy lze jednoduše generovat například tlačítka, zadávací pole nebo celé tělo stránky pomocí krátkých skriptů, což přináší programátorům výhody při vytváření dynamických stránek a interaktivních aplikací, které pomáhají ke zlepšení uživatelských zkušeností (UX) při používání stránky. (GOODMAN, 2007)
Využití v prototypu
Javascript slouží jako základní programovací jazyk, ve kterém běží prototyp aplikace.
Jelikož původní aplikace funguje jako „fullstack“ Javascriptu na straně API i na straně klienta, je částečné přepoužití kódu výhodou. Pro vylepšení stávajícího kódu a zvýšení škálovatelnosti a údržby je pro konkrétní implementaci použita nadstavba Typescript.
2.2.2 Typescript
Typescript je jazyk, který byl stvořen společností Microsoft a vydán jako open-source projekt pod licencí Apache 2.0. Jeho zaměřením jsou především Javascriptové aplikace, které jsou určeny k vysoké škálovatelnosti a robustnímu zpracování. Typescript přináší statické typování, které umožňuje kompilátoru najít syntaktické a typové chyby již během kompilace. To znamená, že výrazně zamezuje vývojářům udělat chyby ve volání funkcí s nesprávnými argumenty nebo měnit přiřazování odlišných typů do stejné proměnné.
Základní specifikace
Jde o nadstavbu Javascriptu, která přináší statické typování. Typescript se při kompilaci transpiluje do čistého Javascriptu, který lze spouštět v kterémkoliv prohlížeči, ale i na serveru. Dokonce je možné za pomocí Typescriptu psát i nativní aplikace. Jazyk se hodí zejména do škálovatelných projektů v produkčním prostředí, kde jakákoliv větší chyba může způsobit střední až velké dopady na společnost. Typescript lze využít i na serverové části, které se nejčastěji používají k výkonným API.
Prototypová dědičnost
Typescript se snaží vyřešit některé nedostatky Javascriptu. Jedním z nich je nemožnost využívat jmenné prostory a jakoukoliv formu rozhraní. Jazyk zavádí do tohoto světa třídy, jmenné prostory, moduly a rozhraní, což umožňuje programátorům převádět existující znalosti mezi jednotlivými projekty. Zároveň přidává možnost automaticky vytvářet stejná rozhraní mezi různými jazyky, které podporují typování.
Rovnost a typové záměny
Další z možných nevýhod Javascriptu je rovnost typů proměnných a jejich jednoduchá záměna. Nejčastěji se zaměňují typy „string“ a „number“, neboli řetězec a číslo. Při psaní může vývojář způsobit i fatální chybu, pokud například chce sestavit výraz a použije různé typy, které skloubí dohromady. V Typescriptu tato chyba není možná. Kompilátor nepustí vývojáře spojit dva odlišné typy do jednoho.
Podpora vývojových prostředí
Jazyk přináší podporu do mnoha vývojových prostředí jako jsou například Visual Studio nebo WebStorm. S pomocí statického typování je možné využívat takzvaný „IntelliSense“, který vývojářům přináší napovídání při psaní kódu podobně jako je to například u objektově orientovaných jazyků, jako jsou například Java nebo C#. (FENTON, 2018)
Využití v prototypu
Typescript je využit jako hlavní nástroj pro vývoj prototypu. Jeho významné výhody, jako je škálovatelnost, údržba nebo statické typování jsou velmi cenným prostředkem pro vývoj robustního systému. Celá aplikace je během sestavení („build“) transpilována do Javascriptu, který běží v prostředí Node.js.
2.2.3 Node.js
Node.js je platforma, která se používá k vývoji webových aplikací, API serverů nebo mikroservisní architektury. Hlavní výhodou je poměrně snadná škálovatelnost a vysoký výkon provádění operací v kombinaci Javascriptu, asynchronních vstupů a výstupů a anonymních funkcí. Node.js je v dnešní době populární volbou při vývoji nových moderních webových aplikací, jelikož umožňuje psát Javascript na straně klienta i serveru. To znamená, že je pro zaměstnavatele výhodnější hledat vývojáře, kteří ovládají právě jeden jazyk, a poté pracovat jako takzvaný „fullstack“, tedy vývoj jak klientské, tak serverové strany.
Nástroje pro vývoj
Platforma je velmi populární pro vytváření nových nástrojů využívající příkazovou řádku pro pomoc při vývoji softwaru. Jedním z těchto nástrojů je například „Babel“, který je běžně používán jako transpilační engine pro moderní syntaxi Javascriptu. To znamená, že lze používat nejnovější syntaxi a zároveň zachovat kompatibilitu pro starší systémy. Dalším populárním nástrojem je „PostCSS“, který pomáhá vývojářům s běžnou prací se styly.
Jedním z příkladů je optimalizace stylů pro všechny prohlížeče, nebo automatická korekce sémantických chyb.
Testování uživatelského rozhraní
Výhodou využití Node.js je jeho rozsah možností práce s prohlížečem v kombinaci s operačním systémem. To poskytuje dostatek funkcionality pro testování (nejen) uživatelských rozhraní. Jedním z frameworků, který umožňuje testování je například
„Cypress“. Tyto frameworky slouží k simulaci činností uživatele, který se pohybuje po webové stránce. Jejich výhodou je, že se nemusí jejich výkonný kód transpilovat do Javascriptu, jelikož v něm přímo pracuje. Mezi další populární testovací frameworky patří i Selenium pro Javascript, WebdriverIO, Puppeteer nebo Nightwatch.js. (HERRON, 2018)
Využití v prototypu
Node.js slouží v projektu jako prostředí, ve kterém běží celý prototyp aplikace. Jako základní nástroje, které pomáhají při vývoji, jsou využity zejména knihovny třetích stran jako je například „Webpack“ pro sestavení produkční verze aplikace, Babel pro transpilaci moderního Javascriptu, „Prettier“ pro přehlednost kódu a jeho formátování nebo „Eslint“
jako „lintovací“ nástroj pro udržení konzistence pravidel psaní kódu. Do prostředí Node.js je zapojena i SQL databáze pro uchování dat vyvíjeného prototypu, která využívá ovladače a propojení MySQL.
2.2.4 Relační databáze a SQL
Robustní systémy vyžadují uchovávání dat v databázích, které poskytují dostatečný výkon, škálovatelnost, snadnou údržbu a bezpečnost. Databáze slouží pro organizaci a správu dat.
Typů zpracování dat v databázi je mnoho, patří sem například relační, objektové nebo NoSQL. Relační databáze jsou nejčastěji používány právě pro systémy, které obsahují mnoho vazeb mezi entitami. V dnešní době existuje mnoho systémů pro řízení báze dat, které umožňují snadnou manipulaci a zobrazení dat, včetně uživatelského rozhraní. Tyto systémy pracují s dotazovacím jazykem SQL, pomocí kterého lze s databází komunikovat.
Tabulka jako entita
Ve světě relačních databází představuje entitu tabulka. Tabulka se skládá ze sloupců a řádků, které obsahují uložená data. Každá tabulka má jako unikátní identifikátor název, například pokud by tabulka obsahovala seznam projektů, její název (v angličtině) by mohl být „Projects“. Každý sloupce představuje atribut, který má daná entita obsahovat.
Z předchozího příkladu sem lze zařadit jméno projektu nebo jeho popis. Řádky tabulky představují jednotlivé záznamy dat s konkrétními hodnotami. Každá hodnota je reprezentována jako pole.
Relace pomocí klíčů
Vazby mezi entitami v relační databázi se realizují pomocí takzvaných klíčů. Pokud je zapotřebí propojení entit, musí mít každá z tabulek unikátní identifikátor, který se nazývá primární klíč. Pomocí něj lze propojit tabulky mezi sebou. Například, pokud by tabulka
„Projects“ vyžadovala pro každý záznam odpovědnou osobu, která je uložená v tabulce
„Persons“, přidá ke svým sloupcům takzvaný cizí klíč neboli primární klíč připojené tabulky.
Tím je zaručeno, že i při změně dat nedojde k nekonzistenci mezi záznamy.
Strukturovaný dotazovací jazyk – SQL
Relační databáze komunikují s uživatelem pomocí dotazovacího jazyk SQL. Pokud uživatel chce získat data z databáze, potřebuje zapsat dotaz pomocí krátkého skriptu. Jedním z nich jsou „SELECT“ a „FROM“. Tyto výrazy umožňují zobrazit požadovaná data z konkrétní tabulky. Pro manipulaci s daty jako je přidání, změna nebo odebrání, lze využít „INSERT“,
„UPDATE“ a „DELETE“. Důležitou součástí dotazu by měla být i podmínka, která data se mají zobrazit nebo změnit. V tomto případě se používá „WHERE“. Výsledný dotaz může vypadat například takto. (DONAHOO, a další, 2013)
SELECT name FROM Projects WHERE id = 1 Využití v prototypu
Relační databáze MySQL je použita jako hlavní uložiště dat. Volba tohoto typu zahrnuje možnost škálovatelnosti a zejména správu množství vazeb mezi moduly. Další výhodou je zachování stejného typu databáze, jako v původním systému.
2.2.5 Objektově relační model (ORM)
Javascript používá pro jakékoliv složitější datové struktury objekty a pole. Je tedy žádoucí, aby bylo možné mapovat objekty na záznamy z databáze a zároveň automatizovat některé databázové dotazy. Objektově relační modely se snaží o propojení obou světů objektově orientovaných jazyků a dotazovacích jazyků pro databáze. Pomocí nástrojů lze docílit jednoduchého a zejména objektově orientovaného způsobu práce s databází. To s sebou nese mnoho výhod, jako je například optimalizace složitých dotazů za účelem zvýšení výkonu.
Komunikace mezi systémy
Výhodou využití ORM je jeho univerzální komunikace s jakýmkoliv operačním systémem a prostředím bez nutnosti specifické konfigurace nebo vytváření speciálních ovladačů pro každé prostředí. ORM představuje vrstvu, které dokáže interně změnit nastavení podle aktuálního prostředí.
Přenositelnost
Jedním ze znaků ORM je i jeho vysoká přenositelnost mezi jednotlivými typy databází a jejich druhy, jako jsou například MySQL, Oracle DB nebo MSSQL. ORM automaticky změní databázové dotazy na korektní syntaxi podle vybrané databáze pomocí konfiguračního souboru, kde je zapotřebí pouze vložit příslušný ovladač. Většina ORM systémů obsahuje tyto ovladače při instalaci, tudíž je potřeba pouze výměna názvu.
Optimalizace dotazů a výkonu
Většina ORM dokáže, bez nutnosti konfigurace, automaticky optimalizovat dotazy vedené na databázi. Příkladem mohou být spojované tabulky, které mají složité vazby typu M:N.
Systém automaticky vybere pouze potřebné tabulky a sloupce, které jsou uvedené v objektovém zápisu, bez nutnosti konkrétní specifikace v kódu. (KOURAKLIS, 2019) Srovnání zápisu TypeORM a SQL:
SELECT * FROM Projects INNER JOIN Employees ON product_ownerID = Employees.id projectRepository.findAll({ relations: [‘employees‘] })
Využití v prototypu
ORM je v prototypu použit jako hlavní nástroj pro práci s databází a zároveň jako vhodná kombinace při použití GraphQL. Jako knihovna třetí strany je zvolena TypeORM. Tato knihovna je velmi dobře kombinovatelná s knihovnou pro technologii GraphQL – TypeGraphQL. Obě knihovny využívají dekorátory a třídy objektově orientovaného stylu Javascriptu a jsou na míru řešené při použití nadstavby Typescript. To znamená, že dokážou automaticky rozpoznat, jaké typy atributů databáze používá a vytvářet pro ně typové definice.
2.2.6 HTTP a REST API
V dnešní době je běžné používat webové služby, které poskytují specifickou funkcionalitu nebo data k dalšímu využití. Jedním z návrhů, jak takové služby tvořit je REST. Jedná se o architektonický návrhový vzor, který umožňuje konzistentní a udržovatelnou strukturu přístupových bodů k datům. Jedním z příkladů mohou být služby poskytující předpověď počasí, které vývojáři mohou využít ve svých aplikacích k zobrazení příslušných dat. Dalším typickým příkladem je mikroservisní architektura, kde jednotlivé uzly spolu komunikují pomocí REST API.
Návrh URI adres
Zdrojové adresy se skládají z několika prvků, které umožňují definovat přesný ukazatel požadovaných dat. Jako první je definováno přenosové schéma, což mohou být například protokoly http, https nebo ftp. Další částí je doména požadovaného serveru. Třetí součástí může být cesta ke zdroji na doménovém serveru. Poslední možností je specifikace dotazovaného zdroje, například konkrétní objekt v databázi. Výsledný formát vypadá následovně:
schéma://doména.cz/cesta?dotaz#fragment
Interakce s http protokolem
Pro komunikaci s webovou službou v prostředí REST se používají stavové kódy, které představují stav událostí, které proběhnou během dotazu a odpovědi od serveru. Stavové kódy jsou reprezentovány číslem v rozmezí 200–599. Pokud je provedená operace úspěšná je zapotřebí použít kód v rozmezí 200–299. Stavové kódy 400-599 představují chybu v operaci. To znamená, že klient může zareagovat a zobrazit například chybovou hlášku.
Metadata
Při přenosu lze využít takzvaná metadata v hlavičkách jednotlivých požadavků a odpovědí.
Tato metadata pomáhají s přenosem informací o typu dat, délce jejich životnosti nebo autorizaci zdroje. Nejpoužívanějším typem hlavičky je „Content-Type“, neboli typ obsahu požadavku. V dnešní době se nejčastěji používá typ „JSON“. Další hlavičkou, která je využita i v prototypu je „Authorization“, která se používá zejména pro přenos autorizačních tokenů.
(MASSÉ, 2012)
Využití v prototypu
Ve vyvíjeném prototypu se používá interní webová služba, která využívá návrhový vzor REST. Tato služba dodává informace o zaměstnancích a projektech. Služba je využita pro propojení a konzistenci informací v rámci společnosti, což v kombinaci s daty uloženými v prototypu dává kompletní údaje. Aplikace využívá data z interního systému, která následně uloží do svého cachovacího nástroje s živostností jedné hodiny. Jelikož data ze systému nejsou často měněná, není potřeba cache aktualizovat častěji.
2.2.7 Docker
Vývoj s pomocí izolovaných kontejnerů je v dnešní době velmi populární volbou. Docker je jeden z nejpoužívanějších nástrojů pro vývoj škálovatelných a udržovatelných aplikací. Jeho hlavní předností je izolace projektu a jeho závislostí do takzvaného kontejneru, který lze použít jako celek na jakémkoliv prostředí. To znamená, že vývojář nemusí mít dostupné všechny závislosti na svém lokálním prostředí, ale může využít Docker, který nainstaluje potřebné věci do virtuálního prostředí. Docker se nejčastěji používá na prostředí třetích stran, které se zabývají zprostředkováním sestavení a distribucí aplikací a dalších systémů či nástrojů. Příkladem mohou být Amazon Web Services nebo Microsoft Azure.
Pro vývojáře
Běžným problém dnešní doby je množství prostředí, které vyvíjené aplikace potřebují k finální distribuci na produkční prostředí. Aby vývojáři mohli testovat jejich kód na stejném prostředí jako jsou všechna ostatní, je zapotřebí sjednotit veškeré závislosti projektu do jednoho kontejneru, který mohou využívat pro vývoj a zároveň se nemusí obávat jiných podmínek na ostatních prostředích, jako mohou být například testovací, před- produkční prostředí atp.
Pro operátory – DevOps
Správa mnoha prostředí je každodenním chlebem mnoha operátorů DevOps. Pro zachování stejných podmínek na všech prostředích se využívá nejen Docker, ale i další kontejnerové nástroje, jako je například Kubernetes, který umožňuje orchestraci aplikačních serverů.
Docker je v dnešní době pro operátory nezbytným nástrojem pro rychlou a snadnou aplikaci vyvíjeného systému na různá prostředí a jejich správu. Výhodou Dockeru je i jeho vysoká parametrizace, což umožňuje zadávat různé podmínky pro specifická prostředí. Příkladem mohou být adresy serverů a jejich interní konfigurace.
Pro podniky
Poměrně častým problémem společností, které využívají složitější architekturu a propojení svých jednotlivých aplikací, je budoucí škálovatelnost ve smyslu přidávání nových modulů a dalších systémů mezi stávající prvky. V tomto případě je problém kompatibilita systémů a jejich verze závislostí. Docker dokáže automaticky vyhledat a správně propojit závislosti jednotlivých aplikací a zároveň je možné vytvořit kopie stávajících kontejnerů s jinými parametry. Vytváření kopií kontejnerů může pomoci i při A/B testování, kdy na jednom prostředí běží aplikace s verzí A, a na druhém verze B. (McKENDRICK, a další, 2017)
Využití v prototypu
V prototypu se Docker využívá na přípravu prostředí databáze, kdy v kontejneru běží server MySQL pro rychlé a pohodlné vytvoření prostředí se stejnými podmínkami napříč všemi vývojáři a distribučními servery. V budoucnu se rozšíří kontejner o aplikační server a klientskou stranu systému.
2.3 GraphQL
V dnešní době je úspora času a dat velmi důležitým klíčem k úspěšnému podnikání ve světě technologií. Lidé tráví mnoho času používáním svých mobilních zařízení v rámci placené datové sítě. GraphQL je framework, který dokáže vyřešit řadu problémů spojených právě s úsporou cenného času a umožňuje lepší zážitek pro potenciální uživatele. Velkou výhodou je přenesení části zodpovědnosti za výběr správných dat ze serverové části na zobrazovací.
To může pomoci při balancování vývojových týmů a zejména budoucí spolupráci při budování nového systému.
Pokud je bráno v úvahu síťové propojení mezi klientem a serverem, mezi nejpopulárnější metody patří již zmíněný REST. Pomocí jednoduchých URL lze získat potřebná data, kde nelze ovlivnit jejich množství, strukturu nebo jejich validaci. Vše je připraveno přímo na serveru, na kterém jsou klienti závislí. GraphQL je deklarativní dotazovací jazyk, který byl vyvinut společností Facebook. Ten začal využívat jádro této nové funkcionality již o roku 2012, kdy největší podíl měly jejich mobilní aplikace. V roce 2015 se stala technologie GraphQL open-source projektem, což umožnilo ostatním podílet se na jeho dalším vývoji.
(WIERUCH, 2018)
GraphQL umožňuje stavět škálovatelná API, která jsou schopna přijímat, modifikovat a synchronizovat data. Výhodou je schopnost klientské strany v kompletní kontrole nad daty, která dostane z odpovědi serveru. To znamená, že ačkoliv server může obsahovat mnoho dat, klient vždy dostane jen to, co požaduje. Technologie tvoří jakousi vrstvu mezi aplikačním serverem a klientem, kdy server má na starosti manipulaci s daty a jejich selekci, za to GraphQL jejich validaci, strukturu a korekci. (BIEHL, 2018)
2.3.1 Dotazovací jazyk GraphQL
Jedním z přínosů GraphQL je nový dotazovací jazyk, který využívá deklarativního přístupu k programování. To může být velkou výhodou zejména pro kombinaci mnoha týmů klientské strany se stejným serverem.
Důležité je rozdělit, jaká data klient vyžaduje a kde data získat. Jazyk pouze umožňuje deklarativně popsat, jakou strukturu dat má server dodat v odpovědi požadavku, ale o jejich výpočet se musí postarat aplikační server. Typickým příkladem je dotaz na data do databáze.
(BIEHL, 2018)
Tím, že klient má možnost přesného výběru a struktury dat, snižuje se redundance informace, kterou klient získá, a tím i velikost přenesených dat po síti. Výsledkem je zvýšení výkonu odezvy dotazu, snížení datové náročnosti a prediktivní struktura.
Zápis jazyka je soubor množin a jejich atributů. Nejprve je potřeba specifikovat metodu, kterou chce vývojář použít, viz kapitola 2.3.3. Poté lze vybrat jednotlivá pole, která jsou potřeba k zobrazení. K oddělení množin se využívají složené závorky „{}“. Příklad kódu může vypadat takto:
query { projects { id
name
description methodology productOwner { id
name } } }
Výpis kódu 1: Ukázka dotazovacího jazyka GraphQL (autor)
2.3.2 GraphQL schéma
Jednou z hlavních funkcionalit GraphQL jsou takzvaná schémata. Ta se skládají z definic jednotlivých typů a datových struktur, které popisují, jak má vypadat celá struktura GraphQL serveru. Výhodou GraphQL je, že jde o silně typovaný jazyk, což umožňuje robustní architekturu, jak na straně serveru, tak klienta. Schémata se dají vhodně kombinovat dohromady a vytvářet tak škálovatelnou strukturu v rámci serveru. Příkladem mohou být Projekty a Zaměstnanci. Každá z těchto entit definuje vlastní schéma popisované struktury dat, kdy ve finální fázi dojde ke kombinaci obou schémat do jednoho a jejich vzájemné referenci.
type Employee { id: ID!
name: String!
}
type Project { id: ID!
name: String!
productOwner: Employee!
}
type Query {
projects: [Project!]!
project(id: ID!): Project }
Výpis kódu 2: Ukázka GraphQL schéma
Typy a pole
Typy představují jednotlivé množiny dat, které lze definovat v rámci GraphQL schématu.
V předešlé ukázce tyto typy reprezentují „Project“ a „Employee“. Jednotlivé typy se dají rozdělit na kořenové, skalární a uživatelsky definované. Každý z typů obsahuje jeden až více polí, která představují strukturu dat dostupnou pro klienty.
Některá uživatelská pole jsou definovaná přímo z GraphQL. Jde například o pole „ID“, které představuje jednoznačný identifikátor objektu. Dále je možné jednotlivá pole označit jako
povinná nebo nepovinná pomocí znaku „!“. To znamená, že server musí vrátit hodnotu pro povinná pole. Naopak pro nepovinná pole server může vrátit hodnotu „null“. Další možností je využití programátorského pole hodnot, kdy server vrátí list objektů, které jsou požadovány. V ukázce je použit tento styl u výpisu všech projektů „projects“. (BIEHL, 2018)
Kořenové typy
Jako hlavní navigaci ve schématu používá GraphQL takzvané kořenové typy. Ty se používají k definování jednotlivých dostupných funkcí serveru. Jinými slovy, pokud server definuje funkci pro výpis projektů, vloží ji do jednoho z kořenových typů.
Existují tři hlavní kořenové typy: „Query“, „Mutation“ a „Subscription“. (BIEHL, 2018) První z typů „Query“, neboli Dotaz se využívá k získání dat ze serveru. V návrhovém vzoru REST se využívá obdobná metodu „GET“. Mutace zajišťují, jak už název napovídá, mutování nebo editaci dat na serveru. Typickým příkladem je úprava dat v databázi, změna tokenů, nebo mazání. „Subscription“ neboli Předplatné je vhodný pro specifický případ serveru, kdy je nutné udržet persistenci spojení mezi klientem a serverem. Příkladem mohou být chatovací služby, hry a různé druhy aplikací, které běží v reálném čase.
Skalární typy
Dalším typem jsou skaláry. Jedná se o generické typy, které jsou vytvořeny přímo v GraphQL frameworku. Jsou velmi podobné klasickým typům z programování jako je například Java nebo C#. Vývojář může vytvořit i vlastní skalární typ, který následně musí být podložen takzvanou „parsovací“ funkcí. Tato funkce určuje, jak se má s tímto typem naložit v kódu. Následující tabulka popisuje mapování skalárních typů GraphQL na Typescript.
Tabulka 1: Mapování GraphQL typů na Typescript
GraphQL Typescript
Int number
Float number
String string
Boolean boolean
List (Array)
Typ List je jeden ze základních stylů, jak definovat, zda pole má vrátit celý seznam zadaných hodnot a objektů, nebo pouze jedno. Používá se zejména u základních entit, jako jsou (konkrétně) projekty, zaměstnanci apod.
Zapsání tohoto typu může být trochu nepřehledné. Pro základní rozdělení je připravena
Tabulka 2: Popis zápisů typu List
Zápis Význam
[Typ] Seznam s možností nulových prvků
[Typ!] Seznam bez nulových prvků
[Typ]! Nenulový seznam s možností nulových prvků
[Typ!]! Nenulový seznam bez nulových prvků
Výčet (Enum)
Jedná se o klasický výčet hodnot známý i z jiných programovacích jazyků. Jeho velkou předností je restrikce hodnot, které klient může použít při zadávání. Zároveň lze výčet využít i k restrikci hodnot pro jednotlivá pole. Tyto výčty jsou dostupné v generované dokumentaci pro klienty, což přináší velkou výhodu v synchronizaci typových rozhraní. Pro vytvoření výčtu se používá klíčové slovo „enum“.
enum Role { ADMIN USER HR }
Výpis kódu 3: Ukázka typu Výčet
Rozhraní
Na rozdíl od ostatních typů se rozhraní vytvářejí za účelem znovupoužití definice polí v jiných typech. To znamená, že pokud je definováno mnoho uživatelských typů, je možné některá pole spojit pod jedno rozhraní, které se klíčovým slovem „implements“ propojí s uvedenými typy. Tím se zaručená vyšší škálovatelnost a konzistence v celé aplikaci.
interface Basic { id: ID!
name: String!
}
type Project implements Basic
Výpis kódu 4: Ukázka struktury Rozhraní
Spojení (Union)
Další z možných GraphQL struktur je Spojení. Jde o generický typ pro více různých typových definic. To znamená, že pokud například metoda obsahuje funkci, do které lze vložit jakýkoliv z definovaných typů, lze použít právě strukturu Spojení pro aktivaci validace v GraphQL. Klient poté může využít jeden ze zvolených typů pro svůj dotaz.
