URL rövidítő alkalmazás

A könyv eddigi részeiben elég sok mindenről volt szó állatorvosi póni példákon keresztül. Ezek sok specifikus dolgot mutattak be kis példákon, de méretükből és a kontextusból adódóan nem tekinthetőek valós életből vett példának, mivel a tervezés folyamatát nem feltétlen mutatták be. Éppen ezért a könyv ezen fejezetében egy valódi állatorvosi ló programot fogunk elkészíteni, ami közelebb áll a való világhoz. Az alkalmazás, amit el fogunk készíteni, egy URL rövidítő alkalmazás backendje lesz.

URL vagy URI?

A könyv ezen szekciójában URL-ekkel foglalkozunk, ami az Uniform Resource Locator rövidítése. Az URI pedig az Uniform Resource Identifier rövidítése. Minden URL egyben URI is, de nem minden URI egy URL, vagyis az URL-ek részhalmazai az URI specifikációnak.

A különbségeket azért érdemes tisztázni, mert a modern webfejlesztésben gyakran szinonimaként használják őket, de technikai szempontból különböznek. A .NET rendelkezik egy URI osztállyal, ami használható URL-ek és tetszőleges URI leírásra is.

Jellemző	URI	URL
Azonosítás	Kötelező	Kötelező
Helymeghatározás	Opcionális	Kötelező
Protokollmeghatározás	Opcionális	Kötelező
Erőforrás elérési út	Opcionális	Kötelező

Vágjunk bele

A való életben az ügyfelek ritkán érkeznek úgy, hogy nekik csak egy backend kell, de amint említettem, állatorvosi ló a programunk. Ezzel le is zárhatnám a témát, hogy ezt csináljuk és csak. Azonban a való élet nem ilyen. Játszunk egy kis szerepet.

Képzeljük el, hogy mi vagyunk a „Pénzért bármit lefejlesztünk Zrt” tulajdonosai és megkeres minket egy ügyfél, akiknek kellene egy olyan megoldás, amivel a céges hivatkozásokat lehetne rövidíteni. Mi a megbeszélésbe technikai tanácsadóként csatlakozunk be.

Az ügyféltől a megbeszélések alatt az alábbi követelmények körvonalazódtak:

• Egyszerű használat
• Statisztika: Hányan kattintottak a rövidített linkre.
• Lejárati idő: Egy rövidített URL esetén meg lehessen mondani, hogy meddig érvényes. Ez később módosítható.
• Lehessen megnézni a tárolt linkeket és azok adatait.
• A rendszert többen fogják használni, mindenki csak a saját linkjeit kezelheti.

Technikai tanácsadóként a követelmények alapján akár egy kulcsrakész, nyílt forráskódú megoldás is megfelelhetne az ügyfél igényeinek, azonban a cég egy saját megoldást szeretne szállítani az ügyfélnek, mivel ez a funkció jól jöhet egy másik termékébe is a cégnek.

Ezért azt javasoljuk, hogy a legkézenfekvőbb az lenne, ha REST szolgáltatásként implementálnánk le az alkalmazást, amihez valami frontend kapcsolódna. Ilyen módon a backend egy újra felhasználható mikroszerviz is lehetne, amit tovább lehetne értékesíteni más cégeknek is, akár személyre szabott kezelőfelülettel.

Ezen döntésünket alátámasztja az a tény, hogy a cégben két jól elkülönülő képességekkel rendelkező csapat van a fejlesztők között. Vannak azok, akik nem hajlandóak olyan nyelveket használni, ahol a háromdarab egyenlőségjel (===) operátor létezik és létjogosultsága van¹, illetve vannak azok, akik szeretik látni a munkájuk eredményét és inkább UI-al foglalkoznak, mintsem backend-el.

A csapatnak prezentálva a problémát úgy döntenek, hogy a backend ASP.NET-et fog alkalmazni, a frontend-es csapat pedig Angulart.

Nem funkcionális követelmények

Az ügyfél követelményei jó néhány megbeszélés után tisztázottak, de ez még nem azt jelenti, hogy minden követelmény adott az alkalmazás lefejlesztéséhez. A követelményeket két kategóriára szokás bontani. Vannak a funkcionális követelmények, amik azt írják le, hogy mit csináljon a rendszer és a nem funkcionálisak, amelyek azt, hogy hogyan.

Ezen követelmények lehetnek törvényi kötelezettségek. (Pl. Ha felhasználókat kezel a rendszer és az EU-ba szállítunk, akkor GDPR-nak megfelelés), szabvány kötelezettségek vagy más technikai követelmények. A példa alkalmazásunk esetén ezeket fogalmazzuk meg:

• RESTFul API szabványok követése JSON válasz formátummal
• REST API végpontok egyértelmű elnevezése
• Clean code elvek betartása
• Tesztelhetőség
• Moduláris felépítés. Az alkalmazás központi logikája független legyen a HTTP rétegtől.
• Egyidejűleg 150 darab link létrehozásának és 1500 darab link feloldásának támogatása.

A követelmények közül a REST és a JSON támogatás a technológiák miatt kell.

A tesztelhetőség, mint követelmény egy kakukktojás, hiszen ezt nem lehet mérni, illetve egy alkalmazást sokféleképpen lehet tesztelni. Ezért jobb követelmény, hogy legyenek a fontos részek automatizáltan tesztelve. Kód lefedettséget is meg lehetne határozni követelménynek, de nem biztos, hogy a legjobb ötlet. A lefedettség egy jó és hasznos jelzőszám a szoftver állapotáról, de nem érdemes kikötni, hogy például 85% felett legyen, mert csak a melegágya lesz az értelmetlen teszteknek, illetve attól, hogy 99%-os a teszt lefedettség, az nem azt jelenti, hogy az alkalmazásban nincs hiba.

A moduláris felépítés követelmény azért jelenik meg, mert később más termékbe is akarjuk integrálni a funkciót és nem feltétlen, mint HTTP API.

Webes alkalmazások esetén egy nagyon fontos NFR az egyidejűleg a rendszert használó felhasználók száma, amire méretezünk. Ez a becslés minél pontosabb, annál jobb, mivel nagyon nem mindegy, hogy egyszerre maximum 3-an használnak egy alkalmazást vagy 3 millióan. A 3 fő kiszolgálására kreált rendszer/architektúra nem feltétlen fog helytállni 3 millió felhasználóval szemben, maximum csak akkor, ha lehetőségünk van azt hazudni, hogy túlterheléses támadás érte a rendszert. A másik véglet sem ideális azonban, ha 3 millióra tervezünk és lesz 3 felhasználó, mivel ebben az esetben valószínűleg több időt és erőforrást öltünk a megvalósításba, mint kellett volna.

A példa esetén a 150 és 1500-as szám a megrendelőtől kapott adatok becslésén alapul. Egy tipikus munkanapon a cég 379 munkavállalójának 25%-a használja a rendszert és maximum 10 linket gyártanak egy nap a jelenlegi szokások alapján. Mivel a legrosszabb szituációra méretezünk, feltételezzük, hogy egyszerre akar mindenki linket gyártani és az egyszerre legyártott linkeket egyszerre akarja mindenki megtekinteni. Ez megmagyarázza a 150*10 = 1500-as számot, de a 379-nek 25%-a nem 150. Ez olyan 94 fő nagyságrend. Azonban feltételezhetjük, hogy az új rendszer kényelmesebb lesz és többen fogják használni.

Tags Alkalmazás, Funkcionális, követelmények, rövidítő, url