Tato kapitola se zabývá zadáním práce na prototypu a jednotlivými kritérii, která se z velké části vážou na řešené nedostatky v současném stavu aplikace. Podkapitoly se dělí na moduly, které jsou zapotřebí implementovat, připojení firemních služeb pro přihlášení a dodatečné informace. Dále správu rolí na úrovni aplikace, která umožní přístup do sekcí pouze oprávněným osobám. Poslední podkapitolou jsou vylepšení, která řeší aktuální nedostatky technické části systému, jako jsou různé vývojové nástroje.
3.3.1 Moduly
Jedním z cílů nového prototypu je implementace klíčových modulů, které spojují jádro celé aplikace. Těmito moduly jsou:
• Zaměstnanci
• Projekty
• Technologie
• Klienti
• Kurzy
Pro každý z modulů je připravena logika pro správu v rámci „CRUD“ operací. To znamená, že lze přidávat, upravovat, mazat a listovat jednotlivé prvky každého modulu.
Speciální případ je modul pro kurzy, kde je zapotřebí přidat další funkce pro přihlašování a odhlašování zaměstnanců z kurzů, včetně možnosti přidávání jeho učitelů.
Pro přístupové body bude dostupná dokumentace pomocí nástroje GraphQL Playground, která umožní vývojářům snadnou orientaci v použitelných metodách.
Konkrétní pole budou převzata od současného řešení pro zachování zpětné kompatibility obou aplikací.
3.3.2 Připojení firemních služeb
Aplikace bude obsahovat připojení externích firemních služeb, které budou sloužit k doplnění informací o zaměstnancích a projektech a k přihlašovaní se stejnými údaji jako k ostatním systémům společnosti využívající „active directory“.
Přihlašování bude probíhat pomocí uživatelského jména a hesla, kdy jméno bude automaticky přetransformováno na e-mail z důvodu dosazení do autorizace serveru LDAP.
Informace použité ze služby „Timur Services“ budou sloužit jako dodatečná data bez duplikace v databázi, aby byla zaručena synchronizace mezi systémy a šetření kapacity disků.
Vytvořit jednoduchou strukturu pro budoucí externí služby, které by mohl systém integrovat. Všechny datové externí služby budou využívat cachovací systém za účelem snížení náročnosti zdrojů.
3.3.3 Přidání rolí
Dalším požadavkem je přidání skupiny rolí do prototypu. Role budou sloužit jako zástupné objekty pro sadu akcí, které uživatel může užívat. Struktura by měla být flexibilní a škálovatelná pro budoucí změny rolí. Konkrétní přiřazení akcí k rolím bude předmětem další fáze vývoje.
Systém by měl obsahovat následující role:
• Superadmin – Role se všemi akcemi, sloužící zejména pro hlavní administrátorský účet.
• Admin – Jsou povoleny všechny akce, kromě akcí pro vývoj a logování.
• HR – Role pro zaměstnance lidských zdrojů.
• PM – Role založená pro projektové manažery s možností vytváření projektů.
• User – Běžná role pro uživatele s minimálním množstvím pravomocí.
3.3.4 Technická vylepšení
Poslední skupinou kritérií jsou technická vylepšení. Ta patří k velmi důležité části implementace nového prototypu, jelikož řeší mnoho z nedostatků, které jsou uvedeny v kapitole 3.2.
Vylepšení zahrnují i změny v použití konkrétních knihoven třetích stran za účelem kompatibility s novým prostředím. Jednou z těchto změn je například náhrada stávajícího ORM řešení, které se nehodí do prototypu používající programovací jazyk Typescript.
Obsahem jsou i strukturální změny pro zvýšení škálovatelnosti a přehlednosti kódu.
Implementace frameworku GraphQL přidává i možnost konfigurace dokumentace a testovacího prostředí, které bude sloužit jako základ pro vývoj a propojení s klientskou stranou.
Typescript
Jednou z nejdůležitějších změn je volba typované verze současného programovacího jazyku Javascript. Typescript je ideální volbou pro budoucí škálovatelnost a robustnost systému, jelikož je možné tvořit typová rozhraní, která mohou být pomocí speciálních knihoven automaticky transformována na typy GraphQL.
Typescript bude v další fázi vývoje použit i na klientské straně, čímž dojde k možnosti sdílení některých typů mezi oběma stranami. Jazyk zvyšuje zejména robustnost systému a snižuje náchylnost k syntaktickým a běhovým chybám.
Změna ORM řešení
Současná aplikace využívá na serverové straně knihovnu „Sequelize“ jako ORM řešení, které je napojené na MySQL databázi. Toto řešení se stalo bohužel velmi nepopulárním ve společnosti a mezi vývojáři, kteří pracují na serverové straně. To je dáno zejména jeho složitou dokumentací a mnohdy obtížně nastavitelným způsobem dotazu.
Nové řešení by mělo zahrnovat změnu této ORM knihovny. Ideální volbou je silně podporované ORM v jazyce Typescript pro zachování nejvyšší kompatibility s prostředím a možností využívat jednotlivé předpřipravené typy pro GraphQL.
Formát a lintovací pravidla
Dalším požadavkem je příprava formátovacích a lintovacích pravidel pro psaní kódu.
Aktuální řešení neobsahuje knihovnu Eslint, která je v moderním řešení velmi důležitou součástí. Je zapotřebí sjednotit styl psaní kódu pro všechny budoucí vývojáře, aby nedocházelo k obtížným revizím, které mohou být zdlouhavé a neefektivní.
Řešení by mělo obsahovat i formátovací pravidla pomocí nejnovější verze programu Prettier, která zaručí, že kód zůstane čitelný a jednotný v celé bázi. Součástí prototypu jsou i skripty, které jsou použitelné pro sestavovací proces, který dokáže určit, zda kód splňuje všechna zadaná pravidla podmínky.
Škálovatelnost
Implementovaný prototyp by měl být strukturován do škálovatelné podoby pro budoucí vývoj. Struktura by neměla obsahovat mnoho zanoření pro zachování jednoduchosti a přehlednosti.
GraphQL by mělo pomoci pro vytvoření dokumentace a možnosti přidávání nových polí pro budoucí rozšíření bez nutnosti verzování. Databázový model bude reflektovat základní propojení, které je navržené v současném řešení.
Posledním požadavkem na škálovatelnost je příprava databázového prostředí ve frameworku Docker, která zaručí stejné podmínky pro vývojáře bez nutnosti konfigurace.
Cachování a odezva
Optimalizace výkonu a efektivní využívání externích služeb je dalším požadavkem, který musí být implementován v novém prototypu. Současné řešení využívá neefektivní ukládání odpovědí serverů bez cachování na straně databáze.
Nový prototyp by měl implementovat cachování jak na straně externích služeb, které je konfigurovatelné přes externí soubor, tak cache na straně databáze, která bude sloužit pro
složité a časově náročné dotazy. Všechna měření jsou prováděna na lokálním stroji viz kapitola 3.5.1.
Celková odezva by měla být v rozmezí specifikovaném v následující tabulce:
Tabulka 3: Požadavky na rychlost odezvy
Typ požadavku Odezva v milisekundách (ms)
Komplexita dotazu větší jak tři spojené entity,
včetně externích služeb < 1 200 ms
Komplexita dotazu větší jak tři spojené entity
bez externích služeb (cache) < 600 ms
Komplexita dotazu pro přímou entitu, včetně
externích služeb < 1 000 ms
Komplexita dotazu pro přímou entitu bez
externích služeb (cache) < 200 ms
Přihlášení (ovlivněno externí službou) < 300 ms