ZalednisistemzaprogramOdisej NejcJamnik

(1)

Univerza v Ljubljani

Fakulteta za raˇ cunalniˇ stvo in informatiko

Nejc Jamnik

Zaledni sistem za program Odisej

DIPLOMSKO DELO

UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE

RA ˇCUNALNIˇSTVO IN INFORMATIKA

Mentor :prof. dr. Janez Demˇsar

Ljubljana, 2021

(2)

besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.

Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita programska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/

licenses/.

Besedilo je oblikovano z urejevalnikom besedil L^ATEX.

(3)

Kandidat: Nejc Jamnik

Naslov: Zaledni sistem za program Odisej

Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika

Mentor: prof. dr. Janez Demˇsar

Opis:

Odisej je program za sestavljanje pustolovskih iger, namenjen predvsem os- novnoˇsolcem, ki se lahko z njim uˇcijo osnov programiranja. Program teˇce v brskalniku in temelji Blocklyju. Njegova osnovna pomanjkljivost je, da vse podatke shranjuje v brskalniku, njihova velikost pa - predvsem, ˇce igra vkljuˇcuje slike - hitro preseˇze brskalnikove omejitve. Zato je potrebno pri- praviti zaledni sistem (back end). Ta naj omogoˇca, da se uporabnik vpiˇse, odpira nove projekte (igre), shranjuje trenutno razliˇcico igre in pripadajoˇce datoteke (trenutno slike, nekoˇc morda tudi zvoˇcne posnetke). Ob tem bo seveda potrebno poseˇci tudi v obstojeˇci program in urediti shranjevanje v zalednem sistemu.

Razviti sistem naj temelji na sploˇsno razˇsirjenih knjiˇznicah, da ga bo mogoˇce vzdrˇzevati tudi v prihodnosti.

Title: Odisej - Back end system Description:

Odyssey is a program for composing adventure games, intended primarily for elementary school students, who can use it to learn the basics of programming. The program runs in the browser and is based on the Blockly library.

Its main drawback is that it stores all the data in a browser, and their size - especially if the game includes images - quickly exceeds the browser’s limits.

Therefore, it is necessary to prepare a back end system which should allow the user to log in, open new projects (games), save the current version of

(4)

the existing program and arrange storage in the back-end system.

The developed system should be based on widespread libraries so that it can be maintained in the future.

(5)

Iskreno se zahvaljujem mentorju, prof. dr. Janezu Demˇsarju, za vso pomoˇc pri izdelavi diplomske naloge.

Zahvaljujem se tudi druˇzini in prijateljem, za vso podporo med ˇstudijem.

(6)

(7)

Kazalo

Povzetek Abstract

1 Uvod 1

2 Aplikacija Odisej 3

2.1 Primer kreiranja igre . . . 5

2.2 Razlogi za nadgradnjo . . . 10

3 Uporabljene tehnologije 11 3.1 Arhitektura zalednega sistema . . . 11

3.2 Izbira podatkovne baze . . . 13

3.3 Uporabljena orodja in knjiˇznice . . . 15

4 Zaledni sistem 19 4.1 Komunikacija med deli aplikacije . . . 19

4.2 Prijava in registracija . . . 21

4.2.1 Kreiranje uporabniˇskega raˇcuna . . . 21

4.2.2 Poˇsiljanje potrditvene e-poˇste . . . 21

4.2.3 JWT ˇzeton . . . 23

4.2.4 Generiranje JWT ˇzetona . . . 23

4.2.5 Avtorizacija zahtevkov . . . 23

4.3 Pregled lastnih iger . . . 25

4.4 Kreiranje nove igre . . . 25

(8)

4.7 Podatkovne sheme . . . 30

4.7.1 Uporabnik . . . 31

4.7.2 Igra . . . 31

4.7.3 Slika . . . 33

5 Docker 35 5.1 Konfiguracija vsebnikov . . . 35

5.1.1 Dockerfile za zaledni del aplikacije . . . 35

5.1.2 Dockerfile za ˇcelni del aplikacije . . . 37

5.2 Docker Compose . . . 39

6 Zakljuˇcek 43

Clanki v revijahˇ 45

Clanki v zbornikihˇ 47

Celotna literatura 49

(9)

Povzetek

Naslov: Zaledni sistem za program Odisej Avtor: Nejc Jamnik

Aplikacija Odisej je namenja spoznavanju temeljnih konceptov programiranja skozi proces ustvarjanj pustolovskih iger. V sklopu diplomske naloge so najprej predstavljene glavne funkcionalnosti aplikacije, v nadaljevanju je prikazana primerjava mikro-storitvene in monolitne arhitekture nato pa ˇse primerjava nerelacijskih in relacijskih podatkovnih baz. Temu sledi opis de- lovanja novega zalednega sistema, ki aplikaciji Odisej omogoˇca shranjevanje podatkov v oddaljeno bazo ter tako reˇsi njeno glavno pomanjkljivost. Zale- dni sistem poleg shranjevanja podatkov omogoˇca tudi registracijo, prijavo, deljenje ustvarjenih iger in nalaganje slik. Na koncu pa je predstavljen ˇse postopek kreacije Docker slik, ki omogoˇcajo enostavno namestitev vseh delov aplikacije.

Kljuˇcne besede: Odisej, Node.js, React.js, MongoDb.

(10)

(11)

Abstract

Title: Odisej - Back end system Author: Nejc Jamnik

The Odyssey app is designed to teach the basic concepts of programming through the process of creating adventure games. As part of the diploma thesis, the main functionalities of the application are first presented, followed by a comparison of micro-service and monolithic architecture and then a comparison of non-relational and relational databases. This is followed by a description of the functionalities of the new back-end system, which allows the Odyssey application to store data in a remote database, thus solving its main drawback. In addition to storing data, the back-end system also enables the users to register, log in, share created games and upload images.

Finally, the process of creating Docker images is presented, which allows easy installation of all parts of the application.

Keywords: Node.js, React.js, MongoDb.

(12)

(13)

Poglavje 1 Uvod

Programiranje postaja vse bolj kljuˇcen del naˇsega vsakodnevnega ˇzivljenja.

Morda bomo v prihodnosti na nepoznavanje programskih jezikov gledali po- dobno, kot danes gledamo na nepismenost.

Seveda to ne pomeni, da se bomo v prihodnosti vsi ukvarjali s programi- ranjem, kljub temu pa je koncept ’raˇcunalniˇskega razmiˇsljanja’ nekaj, ˇcesar bi se morali nauˇciti vsi, saj omogoˇca sistematiˇcno reˇsevanje problemov ter boljˇse razumevanje tehnologij, ki nas obdajajo na vsakem koraku.

Da bi se koncepta raˇcunalniˇskega razmiˇsljanja nauˇcilo ˇcim veˇc ljudi, je pomembno, da lahko osnovne koncepte predstavimo na enostaven naˇcin. Apli- kacija Odisej uporabniku omogoˇca kreiranje pustolovskih iger, preko ˇcesar se na interaktiven in zanimiv naˇcin sooˇci s temeljnimi koncepti programiranja.

V svojem magistrskem delu [27] je ˇSpela Zavrl s poskusno uporabo pro- grama Odisej potrdila, da so vizualna programska okolja primerna za uvedbo pustolovskih raˇcunalniˇskih iger, s katerim se uˇcenci sreˇcajo z osnovnimi pro- gramerskimi koncepti in kreativno uporabljajo veˇcpredstavnost za pripove- dovanje zgodb skozi sam scenarij igre.

Cilj diplomske naloge je izdelati zaledni sistem za aplikacijo Odisej, ki bo uporabnikom omogoˇcal dostop do lastnih iger z razliˇcnih naprav ter deljenje svojih izdelkov z drugimi.

V diplomski nalogi sem najprej predstavil aplikacijo Odisej, primer upo- 1

(14)

rabe in razloge za njeno posodobitev. Temu sledi poglavje, v katerem sem predstavil in primerjal monolitno in mikro-storitveno arhitekturo ter utemeljil lasten izbor. Poglavje vsebuje tudi primerjavo relacijskih in nerelacijskih podatkovnih baz, na koncu pa ˇse opis uporabljenih orodij in knjiˇznic. V 4. poglavju, je predstavljeno delovanje kljuˇcnih funkcionalnosti novega zalednega sistema, ˇcemur sledi opis kreacije Docker slik za vse dele aplikacije.

(15)

Poglavje 2

Aplikacija Odisej

Aplikacija Odisej je grafiˇcni vmesnik, s pomoˇcjo katerega lahko zdruˇzimo vse nujno potrebne elemente za izdelavo pustolovskih iger. Podpira moˇznost upravljanja s predmeti, premikanja med lokacijami in pogovore z liki v igri [27].

Glavni komponenti aplikacije sta:

• urejevalnik zemljevida (slika 2.1), preko katerega uporabnik defi- nira lokacije, po katerih bo potoval igralec. Lokacije so predstavljene z ikono osemkotnika, le-te pa uporabnik nato poveˇze z enosmernimi ali pa dvosmernimi povezavami.

• urejevalnik lokacije(slika 2.2), kjer lahko uporabnik poimenuje lokacijo, tako da v polje, ki je oznaˇceno z oranˇznim pravokotnikom, vnese njeno ime. Urejevalnik omogoˇca tudi nalaganje slike lokacije, ki je potem vidna na zemljevidu, in med igranjem igre. To lahko stori s klikom v polje, ki je oznaˇceno z rdeˇco. Vsaka lokacija lahko vsebuje tudi opis, ki ga uporabnik vnese v modro oznaˇceno polje. Glavni namen urejevalnika lokacije pa je definiranje akcij, ki so igralcu na voljo med igranjem igre. To lahko uporabnik stori tako, da v zeleno oznaˇcenem delu urejevalnika dodaja ukazne bloke.

3

(16)

Slika 2.1: Urejevalnik zemljevida

Slika 2.2: Urejevalnik lokacije

(17)

Diplomska naloga 5 Aplikacija vsebuje tudi inventarni sistem, v katerega lahko igralec shranjuje predmete, ki jih je naˇsel med igranjem igre. Prav tako lahko uporabnik z uporabo logiˇcnih pogojev (kot na primer ’Ali je igralec ˇze obiskal lokacijo?’

ali pa ’Ali ima igralec doloˇcen predmet?’) svoji igri doda naloge, ki jih mora igralec reˇsiti, da zmaga.

Na sliki 2.3 je prikazan primer uporabe logiˇcnih pogojev, ki igralcu omogo- ˇci, da izvede akcijoOdkleni Skrinjo, le ˇce je s seboj prinesel predmet z imenom Kljuˇc in ˇce skrinje ˇse ni odklenil.

Slika 2.3: Primer uporabe logiˇcnih pogojev

2.1 Primer kreiranja igre

V nadaljevanju je predstavljen postopek kreiranja igre, v kateri bo igralec igral vlogo uˇcenca, ki je pozabil narediti domaˇco nalogo. Da se reˇsi iz zadrege, bo moral prepriˇcati soˇsolca, da mu pusti prepisati nalogo. V zameno za domaˇco nalogo bo moral prijatelju prinesti rogljiˇcek, ki ga lahko najde v jedilnici. Preden ga lahko vzame, pa bo moral zamotiti kuharja. Da bo igra bolj zanimiva, se lahko igralec med lokacijami premakne najveˇc 8-krat, sicer se igra konˇca.

Igralec se bo med igranjem igre lahko gibal po treh razliˇcnih lokacijah.

Zaˇcel bo v uˇcilnici, od koder se bo lahko premaknil na hodnik, nato pa v jedilnico. Kreacijo igre zaˇcnemo na urejevalniku zemljevida, kjer lahko z dvojnim klikom dodamo posamezno lokacijo. Le-te nato poveˇzemo z dvosmernimi potmi ter tako oblikujemo pot, po kateri se lahko giblje igralec.

Konˇcna slika zemljevida je prikazana na sliki 2.1.

(18)

V naslednjem koraku bomo dodali akcije, s katerimi se bo uporabnik lahko reˇsil iz zagate. Akcije, ki so na voljo na posamezni lokaciji, lahko ustvarimo preko urejevalnika lokacij, ki ga odpremo z dvoklikom na ˇze obstojeˇco lokacijo. Nekatere akcije se lahko sproˇzijo same, druge pa mora s klikom sproˇziti igralec.

Zaˇceli bomo s kreacijo preproste akcije, ki ob zaˇcetku igre igralcu izpiˇse sporoˇcilo: ’Pozabil si narediti domaˇco nalogo, vpraˇsaj prijatelja, ˇce ti lahko pomaga.’ To bomo naredili tako, da akcijo zaˇcnemo z blokomob zaˇcetku igre, ki pomeni, da se bodo ukazi, ki so povezani s tem blokom, avtomatsko izvedli ob zaˇcetku igre. Na ta blok potem poveˇzemo blok izpiˇsi, ki bo uporabniku izpisal sporoˇcilo. Konˇcan ukazni blok je prikazan na sliki 2.5.

Na lokaciji uˇcilnica, kjer bo igralec zaˇcel igro, bo uporabnik lahko prijatelja prosil za pomoˇc. Ta akcija je sestavljena iz bloka ukaz, s katerim definiramo akcije, ki jih mora sproˇziti uporabnik. Nanj poveˇzemo blokizpiˇsi, ki igralcu sporoˇci, da mu bo prijatelj dovolil prepisati domaˇco nalogo, ˇce mu prinese rogljiˇcek iz jedilnice. Na koncu bloka nastavimo zastavico Prosil za pomoˇc, ki pomeni, da je uporabnik to akcijo ˇze izvedel. Ker ˇzelimo, da je akcija lahko sproˇzena le enkrat, dodamo na zaˇcetek ˇse pogojni stavek prosil za pomoˇc ni postavljena, ki pomeni, da je akcija na voljo le, ko zastavica prosil za pomoˇc ni nastavljena. Konˇcni ukazni blok je prikazan na sliki 2.6.

Uporabnik se mora v nadaljevanju prestaviti na lokacijo hodnik, kjer je obveˇsˇcen, da se lahko s pomikom v levo vrne v uˇcilnico, s pomikom na desno pa se lahko prestavi v jedilnico. Ta navodila smo dodali v opis lokacije.

Ko vstopi na lokacijo jedilnica, se mu izpiˇse naslednje sporoˇcilo: ’Na ho- dniku si zavil desno in priˇsel v jedilnico. Pred seboj vidiˇs pladenj z rogljiˇcki in kuharja, ki peˇce palaˇcinke.’ Na tej lokaciji sta uporabniku na voljo dve akciji. Prva jevzemi rogljiˇc (glej sliko 2.7), ki je sestavljena iz blokaukaz, na katerega je povezan pogojni stavek, ki izvajanje akcije loˇci na dve veji. V primeru, da zastavica kuhar je zaseden ni nastavljena, igralcu s pomoˇcjo ukaza izpiˇsi izpiˇsemo sporoˇcilo: ’Preden ti uspe vzeti rogljiˇcek, te ujame kuhar, ki te poˇslje nazaj na hodnik’, nato z ukazom poˇcakaj 5s izvajanje prekinemo za

(19)

Diplomska naloga 7 5 sekund, na koncu pa uporabnika prestavimo nazaj na lokacijo hodnik. V primeru, da je zastavica nastavljena, pa se namesto prve veje izvede druga, ki uporabniku izpiˇse sporoˇcilo: ’Na hitro vzameˇs rogljiˇcek’, nato pa mu v nahrbtnik doda predmet Rogljiˇcek. Druga akcija, ki je na voljo igralcu, je prikazana na sliki 2.8. Njen namen je, da igralec z njo zamoti kuharja, kar mu omogoˇci, da vzame rogljiˇcek. Ukazni blok se zaˇcne z blokom ukaz, na katerega je povezan ukaz izpiˇsi, ki izpiˇse sporoˇcilo: ’Kuhraju reˇceˇs, da se mu bodo zaˇzgale palaˇcinke. Kuhar se obrne, sedaj imaˇs priloˇznost, da vzameˇs rogljiˇcek’, nato pa nastavi zastavico Kuhar je zaseden, kar pomeni, da se bo ob naslednjem izvajanju akcijeVzemi rogljiˇcek izvedla druga veja.

Sedaj, ko je igralec uspeˇsno pridobil rogljiˇcek, se mora skozi hodnik vrniti v uˇcilnico, kjer lahko izvede do sedaj skrito akcijoprepiˇsi domaˇco nalogo. Ta je sestavljena iz bloka ukaz, kateremu je dodeljen pogojni stavek pokaˇzi, ˇce igralec ima Rogljiˇcek, ki pomeni, da je ukaz na voljo le, ko uporabnikov nahrbtnik vsebuje predmet rogljiˇcek. Ko se akcija izvede, se uporabniku izpiˇse sporoˇcilo Hitro zaˇcneˇs prepisovati nalogo, nato se izvajanje prekine za 3 sekunde, za tem pa se izpiˇse ˇse sporoˇcilo Pravoˇcasno prepiˇseˇs nalogo in se usedeˇs za svojo mizo. Izgleda, da danes ne boˇs dobil enke. Na dnu ukaznega bloka je ˇse blok konec igre, ki oznaˇcuje, da se igra na tem mestu konˇca.

Konˇcni ukazni blok je prikazan na sliki 2.9.

Osnovni tok igre je sedaj pripravljen, da pa igra ne bo preenostavna, bomo igralca omejili na vstop v najveˇc 8 lokacij. To storimo tako, da z dvoklikom na lokacijo z imenomAll locations odpremo urejevalnik vseh lokacij. Ta je po videzu enak urejevalniku lokacij (slika 2.2), vendar pa se razlikuje po tem, da so akcije, ki so definirane v njem, na voljo na vseh lokacijah. V urejevalniku bomo definirali dve akciji. Prva se bo sproˇzila avtomatsko, ko se igra zaˇcne, kar doseˇzemo z uporabo bloka ob zaˇcetku igre in nastavi spremenljivko St.ˇ preostalih korakov na 8. Druga akcija se avtomatsko izvede, ko uporabnik vstopi na katerokoli lokacijo. Njen ukazni blok se zaˇcne z blokomOb vstopu, v naslednjem koraku se vrednost spremenljivkeSt. preostalih korakovˇ zmanjˇsa za 1. Nato sledu pogojni stavek, ki preveri, ˇce je vrednost spremenljivke

(20)

enaka 0. V primeru, da je pogoj veljaven, se uporabniku izpiˇse sporoˇcilo Uˇciteljica se je vrnila v uˇcilnico, preden ti je uspelo prepisati nalogo, nato pa se igra konˇca. Obe akciji sta prikazani na sliki 2.4.

Slika 2.4: Ukazi, ki se kliˇcejo avtomatsko

Slika 2.5: Ukaz, ki se izvede na zaˇcetku igre

Slika 2.6: Ukaz ’Prosi prijatelja za pomoˇc’

(21)

Diplomska naloga 9

Slika 2.7: Ukaz ’Vzemi rogljiˇc’

Slika 2.8: Ukaz ’Zamoti kuharja’

Slika 2.9: Ukaz ’Prepiˇsi domaˇco nalogo’

(22)

2.2 Razlogi za nadgradnjo

Aplikacija, ki jo je pred nekaj leti ustvaril mentor, ima v trenutni razliˇcici nekaj pomanjkljivosti. Njena glavna pomanjkljivost je, da trenutno ne komunicira s streˇznikom oz. nima zalednega sistema, poslediˇcno pa se morajo vsi podatki shranjevati neposredno v spomin brskalnika, ki je omejen. To pomeni, da ima igralec v brskalniku lahko shranjeno najveˇc eno igro, druge pa si mora prenesti na raˇcunalnik, ˇce jih ˇzeli urejati ali pa igrati v prihodnosti.

Poleg tega je omejeno tudi ˇstevilo lokacij.

Namen posodobitve aplikacije je torej izdelava zalednega sistema, preko katerega bo aplikacija podatke shranjevala v oddaljeno podatkovno bazo, kar poslediˇcno pomeni, da bodo uporabniki lahko do lastnih podatkov dostopali z razliˇcnih naprav. Zaledni sistem bo omogoˇcal tudi shranjevanje veˇc iger, kar pomeni, da uporabniku prenaˇsanje iger na lasten raˇcunalnik ne bo veˇc potrebno. Seveda to pomeni, da bo treba narediti tudi nekaj sprememb v ˇze narejenem ˇcelnem delu. Dodati bo treba pogled, ki bo uporabniku omogoˇcal pregled nad lastnimi igrami, to zajema kreiranje novih iger ter urejanje, igranje in brisanje ˇze obstojeˇcih. Jedro aplikacije, torej urejevalnika zemljevida in lokacij pa bosta ostala kar se da nespremenjena.

Ker lahko do podatkov dostopa le njihov lastnik, bo zalednemu sistemu seveda treba dodati tudi registracijo in avtentikacijo, uporabnikom pa bo omogoˇceno tudi deljenje ustvarjenih igric z drugimi. Prav tako bo treba na ˇcelnem delu dodati pogled, ki bo omogoˇcal brskanje med igricami, ki so jih objavili drugi uporabniki.

Tudi za vzpostavljanje komunikacije med ˇcelnim in zalednim delom bo treba poseˇci v ˇze narejen ˇcelni del, zato bom priloˇznost izkoristil tudi za posodobitev nekaterih knjiˇznic.

(23)

Poglavje 3

Uporabljene tehnologije

3.1 Arhitektura zalednega sistema

Preden se lotimo samega razvoja zalednega sistema, je pomembno, da se odloˇcimo za najbolj primerno arhitekturo. Pri izboru se najpogosteje odloˇca- mo med monolitno in mikro-storitveno. V tem poglavju bom na kratko opisal prednosti in slabosti vsake ter tako utemeljil lasten izbor.

Slika 3.1: Primerjava monolitne in mikro-storitvene arhitekture. Vir: [22]

V monolitni arhitekturije vsa funkcionalnost implementirana kot ena sama aplikacija. Kljub temu, da je aplikacija razdeljena na module, so le-ti

11

(24)

tesno povezani, zato jih ni mogoˇce izvajati neodvisno [20].

Prednost monolitne arhitekture je enostavnejˇsi nadzor sistema kot pri drugih arhitekturah, saj je celoten sistem sestavljen iz ene same aplikacije.

Prav tako je poenostavljena sama namestitev aplikacije, saj je potrebno pri- praviti izvajalno okolje za eno samo aplikacijo, kateri ni potrebno komunicirati z ostalimi loˇcenimi aplikacijami oz. storitvami [11].

Eden izmed glavnih problemov monolitov predstavlja razˇsirljivost posa- meznih modulov aplikacije, saj je le-te najprej potrebno izolirati [2]. Tesna povezanost med moduli tudi oteˇzuje berljivost, saj uporaba uvoˇzenih odvi- snosti v aplikaciji ni takoj oˇcitna ob branju kode. Ker so monolitne aplikacije celote, moramo za razvoj vseh funkcionalnosti uporabljati isti programski jezik [11].

Mikro-storitvena arhitekturaje pristop k razvoju ene same aplikacije kot zbirke majhnih storitev, ki se izvajajo vsaka v svojem procesu in komunicirajo preko lahkih mehanizmov, kot npr. HTTP API [21]. Tak naˇcin razvoja je v zadnjih ˇcasih postal izjemno priljubljen, saj tradicionalne monolitne arhitekture ne dohajajo potrebe po razˇsirljivosti in hitrih razvojnih ciklusih.

Mikro-storitve so bolje organizirane, saj ima vsaka storitev svoj specifiˇcni namen oziroma nalogo in se ji ni treba obremenjevati z nalogami ostalih delov aplikacije. Ker vsaka mikro-storitev predstavlja samostojno celoto, je lahko zgrajena z uporabo razliˇcnih tehnologij in arhitektur ter se lahko izvaja na drugi platformi kot ostali deli aplikacij [11].

Glavna slabost mikro-storitvene arhitekture je poveˇcana kompleksnost razvoja, saj mormo poskrbeti, da lahko aplikacije oz. storitve komunicirajo druga z drugo, tudi ˇce se izvajajo na razliˇcnih streˇznikih, virtualnih strojih ali pa Docker vsebnikih.

Poleg tega pa sistem za delovanje potrebuje veˇcjo koliˇcino sistemskih virov, saj je vsaka aplikacija izolirana.

Ker zaledni sistem aplikacije Odisej ne zajema velikega ˇstevila modulov in ker veˇcje razˇsiritve niso predvidene, sem se odloˇcil za uporabo monolitne

(25)

Diplomska naloga 13 arhitekture. Kljub temu pa bom skozi razvoj poskusil minimizirati neˇzelene posledice izbrane arhitekture tako, da bo vsak modul sistema deloval kar se da neodvisno od drugih. Poslediˇcno bo morebitna delitev aplikacije na mikro-storitve kar se da enostavna.

3.2 Izbira podatkovne baze

Pri izbiranju podatkovne baze se moramo najprej odloˇciti, ali je za naˇso aplikacijo bolj primerna relacijska ali nerelacijska baza. V nadaljevanju bom opisal obe vrsti ter utemeljil svojo izbiro.

Relacijske podatkovne baze temeljijo na relacijskem podatkovnem modelu in so predstavljene kot mnoˇzica relacij, vsako relacijo pa si lahko predstavljamo kot tabelo, ki je sestavljena iz vrstic in stolpcev.

Vsaka tabela hrani podatke o enem entitetnem tipu, kjer stolpci predstavljajo posamezne atribute entitete, vrstice pa posamezne zapise. Vsaka tabela mora vsebovati primarni kljuˇc; ta je najveˇckrat predstavljen z enim atributom oz. stolpcem, ki mora biti unikaten, saj se uporablja kot identifikator posameznega zapisa v tabeli.

Za laˇzjo predstavo je na spodnji sliki prikazan primer entiteteDrˇzava ter entitete Mesto.

Slika 3.2: Entiteti drˇzava in mesto

Primarni kljuˇc v tabeli Drˇzava predstavlja stolpec id drˇzave, v tabeli Mesto pa stolpec id mesta. Ker lahko vsaka drˇzava vsebuje veˇc mest, je v tabeli Mesto prisoten tudi stolpecid drˇzave, ki predstavlja tuji kljuˇc, preko katerega sta povezani entiteti.

Ena zelo pomembnih znaˇcilnosti relacijskih podatkovnih baz je njihova sposobnost, da za transakcije zagotavljajo lastnosti ACID, ki predstavljajo

(26)

kazalnike, ki jih lahko uporabimo za oceno, ali je bila transakcija pravilno in uspeˇsno izvedena [9]. Kratica ACID pomeni atomarnost (ang.: Atomi- city), konsistentnost (ang.: Consistency), izolacijo (ang.: Isolation) in traj- nost (ang.: Durability) [7]

Poleg tega pa lahko skupaj z relacijsko bazo uporabljamo poizvedovalni jezik SQL (Structured Query Language), ki uporabniku omogoˇca definiranje podatkovnih tipov, manipulacijo s podatki in poizvedovanje nad eno ali veˇc tabelami [9].

Nerelacijske podatkovne baze (pogosto imenovane NoSQL podatkovne baze) se razlikujejo od tradicionalnih relacijskih podatkovnih baz po tem, da shranjujejo svoje podatke v nestandardni obliki [14].

Za razliko od relacijskih baz, nerelacijske baze ne zagotavljajo lastnosti ACID, temveˇc temeljijo na principu BASE. BASE je kratica za osnovno razpoloˇzljivost (ang.: Basic Availability), mehko stanje (ang.: Soft state) in zakasnjeno konsistentnost (ang.: Eventual Consistency). Ta model podpira prilagodljivost in druge pristope, ki se uporabljajo za delo z nestrukturiranimi podatki, ki jih ponujajo NoSQL podatkovne baze [10].

Poznamo veˇc razliˇcnih tipov nerelacijskih podatkovnih baz izmed katerih, je za primer aplikacije Odisej bi najbolj primerena dokumentno usmerjena podatkovna baza. Podatki se v tako bazo shranjujejo v obliki dokumentov, ki so sestavljeni iz nabora parov kljuˇc-vrednost, kar nam omogoˇca, da podatke, ki spadajo skupaj, shranimo v en dokument.

V zgornjem primeru (slika 3.2) smo mesti Ljubljana in Maribor povezali z drˇzavo Slovenija tako, da smo v tablo Mesto dodali tuji kljuˇc z imenom id drˇzave, v katerega smo zabeleˇzili ˇstevilko 1. Na spodnji sliki, je z uporabo dokumenta v obliki JSON prikazana ekvivalentna reˇsitev.

V primeru, da uporabljamo relacijsko podatkovno bazo in ˇzelimo izvedeti, katera mesta so v Sloveniji, bi morali najprej v tabeliDrˇzava poiskati, kakˇsna je vrednost atributaid drˇzave za Slovenijo ter nato v tabeliMesto z uporabo tujega kljuˇca poiskati vse pripadajoˇce zapise.

Z uporabo nerelacijske baze si postopek poenostavimo, saj lahko poiˇsˇcemo

(27)

Diplomska naloga 15

Slika 3.3: Primer JSON dokumenta

dokument, kjer je vrednost kljuˇca ime drˇzave enaka nizu Slovenija, nato pa iz vrednosti kljuˇca mesta preberemo vsa pripadajoˇca mesta.

Glede na zgornje prednosti in slabosti sem se odloˇcil, da bom uporabil dokumentno usmerjeno nerelacijsko podatkovno bazo MongoDB, saj se bo struktura podatkovnih shem med razvojem in morebitnimi nadgradnjami veliko spreminjala.

3.3 Uporabljena orodja in knjiˇ znice

Zaledni sistem aplikacije Odisej bo skrbel za registracijo, avtentikacijo, shranjevanje, branje in brisanje podatkov, poleg tega pa mora omogoˇcati tudi nalaganje slik. V tem poglavju bom opisal tehnologije, ki sem jih uporabil za razvoj vseh naˇstetih funkcionalnosti ter najbolj kljuˇcne tehnologije na podlagi katerih je zgrajen ˇcelni del.

Node.js

Zaledni del aplikacije predstavlja streˇznik, ki temelji na streˇzniˇskem izva- jalnem okolju Node.js [18]. Le-ta je dogodkovno usmerjen, kar pomeni, da se aplikacija izvaja samo, kadar procesira prejete zahtevke. Ena izmed glavnih prednosti pred alternativami, kot naprimer PHP, je delovanje v asinhronem

(28)

naˇcinu. To pomeni, da lahko Node.js sproˇzi poizvedbo po podatkovni bazi ter takoj zaˇcne s procesiranjem druge zahteve. ˇSele ko prejme rezultate iz podatkovne baze, pa nadaljuje s procesiranjem prve zahteve [26].

Express

Express [5] je ogrodje za Node.js, izdan kot brezplaˇcna in odprtokodna programska oprema pod licenco MIT. Zasnovan je za izdelavo spletnih aplikacij in API-jev ter temelji na principu ’konfiguracija nad konvencijo’ [6].

Poslediˇcno so sistemi Express.js visoki nastavljivi, kar razvijalcem omogoˇca prosto izbiro knjiˇznic, ki jih potrebujejo za posamezen projekt. [12].

MongoDB

MongoDB [13] je nerelacijska podatkovna baza, v katero se podatki shranjujejo v obliki dokumentov. Ker za uporabo ne zahteva vnaprej definirane podatkovne sheme, je prehod med strukturami podatkov zelo enostaven.

Mongoose

Mongoose ponuja preprosto reˇsitev za modeliranje, tipiziranje in prever- janje veljavnosti aplikacijskih podatkov. [15].

Docker

Docker je platforma, zasnovana za laˇzje ustvarjanje, nameˇsˇcanje in po- ganjanje virtualiziranih vsebnikov, ki vsebujejo aplikacijo, operacijski sistem ter vse knjiˇznice in orodja, ki jih aplikacija potrebuje. Razvijalcem omogoˇca, da z uporabo vsebnikov ustvarijo izolirana okolja, ki so loˇcena od drugih aplikacij. Ne glede na to, kje je aplikacija nameˇsˇcena, je okolje, v katerem teˇce aplikacija, vedno enako.

Docker vsebnike lahko razumemo kot lahke navidezne stroje, ki omogoˇcajo nastavitev raˇcunalniˇskega okolja, vkljuˇcno z vsemi potrebnimi odvisnostmi (na primer. knjiˇznicami), konfiguracijo, izvorno kodo in potrebnimi podatki v eni sami enoti, ki se imenuje slika [3].

(29)

Diplomska naloga 17 Postopek za kreacijo takˇsne slike napiˇsemo v datoteko imenovano Docker- file. Le-ta vsebuje vse potrebne informacije o arhitekturi sistema in ukazih, ki naj se izvedejo ob kreaciji vsebnika.

Slika 3.4: Postopek kreacije Docker vsebnika. Vir: [24]

Docker Compose

Docker Compose je orodje za izvajanje aplikacij z veˇc Docker vsebniki.

Konfiguracijska datotekadockercompose.yaml se uporablja za doloˇcitev naˇci- na konfiguriranja vsebnikov, ki sestavljajo aplikacijo. Ko je konfiguracijska datoteka pripravljena, lahko vse vsebnike zaˇzenemo hkrati z enim ukazom [4].

Multer

Ko uporabnik preko spletnega odjemalca naloˇzi datoteko na streˇznik, se ta obiˇcajno poˇslje kot veˇcdelni sklop podatkov (ang. multipart form-data).

Multer je vmesna programska oprema za Express in Node.js, ki olajˇsa roko- vanje s takimi podatki [16].

Nodemailer

Nodemailer je modul za Node.js aplikacije , ki olajˇsa poˇsiljanje e-poˇste [19]. V aplikaciji Odisej, ga bom uporabil kot orodje za poˇsiljanje e-poˇstnih sporoˇcil, preko katerih uporabniki po registraciji potrdijo svoj uporabniˇski

(30)

raˇcun.

Nginx

Nginx je brezplaˇcen odprtokodni visoko zmogljiv streˇznik HTTP in po- vratni proxy ter streˇznik proxy IMAP/POP3. NGINX je znan po visokih zmogljivostih, stabilnosti, bogatem naboru funkcij, enostavni konfiguraciji in nizki porabi sistemskih virov [17].

React

React je deklarativna, uˇcinkovita in prilagodljiva knjiˇznica JavaScript za gradnjo uporabniˇskih vmesnikov. Omogoˇca sestavljanje zapletenih upo- rabniˇskih vmesnikov iz majhnih in izoliranih kosov kode, imenovanih ”kom- ponente”[23].

Blockly

Blockly [1] je odjemalska knjiˇznica za programski jezik JavaScript, ki omogoˇca vizualno programiranje s povezovanjem blokov, kakrˇsni so prikazani v poglavju 2.1.

(31)

Poglavje 4

Zaledni sistem

V sledeˇcem poglavju so opisane kljuˇcne funkcionalnosti aplikacije. Predsta- vljeno je tako delovanje ˇcelnega dela aplikacije, s katerim komunicira uporabnik, kot tudi delovanje na zalednem delu, ki skrbi za kreiranje, posodabljanje in shranjevanje podatkov.

4.1 Komunikacija med deli aplikacije

Kot omenjeno, je aplikacija sestavljena iz ˇcelnega in zalednega dela, ki morata med seboj komunicirati. Komunikacija poteka preko REST API-ja, ki ponuja dostopne toˇcke, preko katerih ˇcelnemu delu omogoˇca manipulacijo in branje podatkov.

Sama komunikacija poteka preko HTTP protokoloa (ang.: HyperText Transfer Protocol), ki deluje po principu zahtevek-odgovor. V primeru aplikacije Odisej zahtevke ustvari ˇcelni del aplikacije, nato jih poˇslje na REST API, preko katerega zahteva branje ali pa kakˇsno spremembo podatkov.

Vsi HTTP zahtevki sledijo spodnji strukturi

Preko HTTP metode navedemo namen poslanega zahtevka. Izbiramo lahko med metodami GET, POST, PUT, DELETE ter PATCH. Sam tip me-

19

(32)

tode sicer ne vpliva na funkcionalnost, ki se bo izvedla na streˇzniku, ki prejme zahtevek. Vseeno pa je najbolje, da zahtevke tipa GET interpretiramo kot zahtevke po branju podatkov o doloˇcenem resursu, zahtevke tipa POST pa kot zahtevke po kreaciji novih podatkov. Z metodo PUT dostopamo do do- stopnih toˇck, katerih namen je manipulacija obstojeˇcih podatkov, z metodo DELETE pa do tistih, katerih namen je izbris podatkov.

Naslov streˇznikapredstavlja url, na katerem streˇznik posluˇsa zahtevke.

Ime virapredstavlja unikatno pot do dostopne toˇcke, ki jo ponuja streˇznik.

Z upoˇstevanjem konvencij o uporabi http metod lahko specifikacijo REST vmesnika razumemo ˇze na prvi pogled. Na primer, zahtevek GET na naslov /uporabniki, bo najverjetneje pridobil seznam uporabnikov, medtem ko bo zahtevek POST na /uporabniki ustvaril novega uporabnika.

Prav tako kot HTTP zahtevki so tudi vsi odgovori na te strukturirani enako. Sestavljeni so iz statusne kode, statusa in telesa.

Statusna koda je ˇstevilo med 100 in 599. Z uporabo le-teh lahko uporabniku API-ja omogoˇcimo hitro razumevanje odgovorov. Statusne ˇstevilke med 200 in 299 sporoˇcajo, da je bil zahtevek uspeˇsno sprejet in obdelan, statusi med 400 in 499 sporoˇcajo, da je poˇsiljatelj poslal neveljaven zahtevek, medtem ko statusi nad 500 sporoˇcajo, da je kljub veljavnemu zahtevku priˇslo do napake na streˇzniku.

Statuspredstavlja tekstovno razlago statusne kode, na primer, ˇce je status odgovora enak 401, bo v polju status pisalo ’Unauthorized’, kar pomni, da poˇsiljatelj zahtevka nima pravic za dostop do zahtevanega vira.

Telo odgovora vsebuje podatke, ki so bili zahtevani s strani odjemalca.

Telesa odgovorov, ki jih vraˇca aplikacija Odisej, so predstavljena v JSON obliki in vedno vsebujejo polje message, v katerem je zapisano sporoˇcilo o uspeˇsno obravnavanem zahtevku ali pa razlaga razloga za napako. Opcijsko pa vsebujejo tudi poljedata, v katerem so zapisani zahtevani podatki. Primer vsebine telesa odgovora na zahtevek GET /games je prikazan na sliki 4.1.

(33)

Diplomska naloga 21

Slika 4.1: Primer vsebine odgovora

4.2 Prijava in registracija

Uporabnikovi podatki so shranjeni na oddaljeni podatkovni bazi, zato je treba poskrbeti, da lahko vsak uporabnik dostopa le do svojih podatkov. V ta namen bo vsak uporabnik za vstop v aplikacijo potreboval uporabniˇski raˇcun, ki je sestavljen iz e-poˇstnega naslova in gesla. Po uspeˇsnem vpisu brskalnik prejme JWT ˇzeton, s katerim potrjuje svojo identiteto v nadaljnjih zahtevkih.

4.2.1 Kreiranje uporabniˇ skega raˇ cuna

Preden se uporabnik lahko prijavi v aplikacijo, si mora ustvariti uporabniˇski raˇcun. To stori tako, da na zaˇcetni strani aplikacije izbere opcijo ’Ustvari nov raˇcun’ ter v naslednjem koraku izpolni zahtevane podatke, torej svoj e-poˇstni naslov in geslo. Na vpisani e-poˇstni naslov dobi potrditveno e-poˇsto, kjer s klikom na povezavo potrdi registracijo raˇcuna.

4.2.2 Poˇ siljanje potrditvene e-poˇ ste

Kot omenjeno v poglavju 3.3, sem za poˇsiljanje e-poˇste uporabil knjiˇznico Nodemailer. Preden lahko poˇsljemo e-poˇsto, je treba definirati, s katerega e-poˇstnega raˇcuna se bo poslala, kar naredimo s spodnjim ukazom.

(34)

let transporter = nodemailer.createTransport({

host: "smtp.amis.net", port: 587,

auth: {

user: username, pass: password }

});

Nato pa lahko s spodnjim ukazom poˇsljemo sporoˇcilo, v katerem je zapisana povezava, na katero mora uporabnik klikniti, da lahko potrdi svoj nov uporabniˇski raˇcun.

transporter.sendMail({

from: ’"Odisej " <noreply@odisej.com>’, to: "uporabnik@gmail.com",

subject: "Registration ",

html: "<h2>Verify your email to finish signing up</h2>

Please confirm that your email address by clicking on the link below

<br>

<a target="_blank"

href="https://odisej.com/conirm/asdrockaslrs">

https://odisej.com/confirm-email

</a>

", });

(35)

Diplomska naloga 23

4.2.3 JWT ˇ zeton

JSON Web Token (JWT) je odprt standard, ki opredeljuje kompakten in samostojen naˇcin za varen prenos informacij med udeleˇzenci v komunikaciji.

Te podatke je mogoˇce preveriti in jim zaupati, ker so digitalno podpisani.

JWT se lahko podpiˇsejo s tajnim kljiˇcem (z algoritmom HMAC) ali parom javnih/zasebnih kljuˇcev z uporabo RSA ali ECDSA [25].

Za generiranje ˇzetonov sem uporabil knjiˇznico jsonwebtoken [8], ki omogoˇca podpisovanje in dekodiranje JWT ˇzetonvov z zasebnim kljuˇcem.

4.2.4 Generiranje JWT ˇ zetona

Ko se uporabnik poskusi vpisati v aplikacijo, se na naslov /users/login poˇslje Http POST zahtevek, v katerem sta zabeleˇzena e-poˇstni naslov in geslo, s katerimi se uporabnik poskuˇsa prijaviti.

V naslednjem koraku se izvede poizvedba na podatkovno bazo, s katero preverimo, ˇce so podatki, ki jih je vpisal uporabnik, pravilni.

Ce prijava ni veljavna, se postopek avtentikacije zaustavi, na ˇˇ celni del aplikacije pa se poˇslje odgovor s statusom 401 Unauthorized.

const jwtToken = jwt.sign({ userId: <userId> }, jwtSecret);

Ce je prijava veljavna, pa se z zgornjim ukazom ustvari in podpiˇse JWTˇ ˇzeton, v katerem je zabeleˇzen unikaten identifikator uporabnika. Le-ta se poˇslje na ˇcelni del aplikacije.

Postopek je grafiˇcno prikazan na sekvenˇcnem diagramu 4.2

4.2.5 Avtorizacija zahtevkov

Ko ˇcelni del prejme JWT ˇzeton, ga s spodnjim ukazom shrani v lokalno shrambo brskalnika, saj ga bo potreboval za potrjevanje identitete uporabnika.

(36)

Slika 4.2: Sekvenˇcni diagram avtentikacije

localStorage.setItem(’token’, vsebinaZetona);

Vsi nadaljnji zahtevki morajo v glavi vsebovati polje ”authorization”, v katerem je zapisana vrednost ˇzetona. Ko zaledni sistem prejme kateri koli zahtevek, katerega namen ni registracija ali prijava uporabnika, se najprej izvede spodnje zaporedje ukazov.

try {

let token = req.headers.authorization

if(!token)

throw("token missing")

req.userData = jwt.verify(token, process.env.JWT_SECRET);

next();

(37)

Diplomska naloga 25

} catch (error) {

console.log("error while verifying jwt", error)

return Response.unauthorizedResponse(res, "Unauthorized") }

Zgornja funkcija najprej prebere polje ”authorization” iz glave zahtevka, nato pa njegovo vsebino skupaj s skrivnostjo, ki je bila uporabljena pri pod- pisu ˇzetona, poda kot parametra funkciji ”jwt.verify”, ki preveri, ˇce je ˇzeton veljaven. V primeru, da avtorizacijski ˇzeton ni veljaven, se na ˇcelni del aplikacije poˇslje odgovor s statusom 401 Unauthorized.

4.3 Pregled lastnih iger

Po uspeˇsni prijavi se uporabniku prikaˇze pogled, ki vsebuje seznam lastnih iger. Ta pogled mu omogoˇca ustvarjanje nove igre, prav tako pa lahko za vsako izmed iger uporabnik izbere eno izmed naslednjih opcij:

• Uredi igro, ki uporabnika popelje na pogled za urejanje obstojeˇcih iger, od koder lahko spreminja vsebino ˇze obstojeˇce igre.

• Igraj igro, ki odpre pogled za igranje iger. Tukaj lahko uporabnik preveri delovanje svoje igre.

• Izbriˇsi igro, ki po uporabnikovi potrditvi izbriˇse igro, iz podatkovne baze.

• Objavi igro, ki uporabniku omogoˇca, da svojo igro deli z drugimi.

4.4 Kreiranje nove igre

Ob kliku na gumb ’Ustvari novo igro’ se uporabniku prikaˇze modalno okno, v katerem mora izpolniti naslov in opis nove igre, s katerim bo pritegnil

(38)

pozornost morebitnih igralcev, prav tako pa lahko igri doda sliko, ki bo sluˇzila kot logotip. Po potrditvi vpisanih podatkov se na zaledni sistem poˇslje POST zahtevek na naslov /games.

Slika 4.3: Sekvenˇcni diagram kreiranja igre

Diagram na sliki 4.3 predstavlja celoten postopek kreiranja nove igre.

Ko zaledni sistem prejme zahtevek za kreacijo igre, najprej preveri, ˇce so vsi potrebni podatki izpolnjeni. V primeru, da kakˇsen podatek manjka, se na ˇcelni del poˇslje sporoˇcilo o napaki, ˇcelni del pa zahteva ponoven vnos

(39)

Diplomska naloga 27 podatkov.

V primeru, da so vsi prejeti podatki veljavni, v naslednjem koraku preverimo, ˇce igra z enakim naslovom ˇze obstaja. V primeru, da je naslov ˇze zaseden, se na ˇcelni del poˇslje ustrezno sporoˇcilo.

Ce je naslov igre ˇse zmeraj prost, se v podatkovno bazo zapiˇse nova igra,ˇ kateri se doda podatke o ˇcasu kreacije in avtorju. Ko je igra ustvarjena se na ˇcelni del aplikacije poˇslje odgovor, uporabniku pa se prikaˇze pogled za urejanje iger.

4.5 Urejanje igre

Ko uporabnik vstopi na pogled za urejanje iger, ˇcelni del iz zalednega pridobi trenutno verzijo igre. Uporabniku se prikaˇze urejevalnik 4.4, preko katerega lahko doda novo lokacijo in jo poveˇze z ˇze obstojeˇcimi. S povezovanjem lokacij uporabnik sestavi pot, kateri bo sledil igralec.

Slika 4.4: Urejevalnik zemljevida

(40)

Z dvoklikom na lokacijo lahko uporabnik odpre urejevalnik Blockly blokov, kjer lahko s povezovanjem le-teh posamezni lokaciji doda funkcionalnost.

Na sliki 4.5 je prikazan primer zaporedja ukazov, ki se izvrˇsijo, ko igralec vstopi na ’Prvo lokacijo’.

Slika 4.5: Urejevalnik funkcionalnosti lokacije

Ko uporabnik na urejevalniku lokacij naredi spremembo, ali pa ko zapre urejevalnik blokov, se spremembe zapiˇsejo v podatkovno bazo, kar pomeni, da uporabniku ni treba roˇcno shranjevati sprememb.

Postopek shranjevanja sprememb, ki je prikazan na sliki 4.6, se zaˇcne s PUT zahtevkom na naslov /games/id igre, v katerem je zabeleˇzeno trenutno stanje igre. Zaledni sistem najprej preveri, ˇce igra, za katero smo prejeli spremembe, res obstaja. V primeru, da igra ne obstaja, se na ˇcelni del

(41)

Diplomska naloga 29 aplikacije poˇslje sporoˇcilo o napaki.

V primeru, da igra obstaja, zaledni del prejete podatke spremeni v obliko, ki se ujema s podatkovno shemo, jih zapiˇse v podatkovno bazo ter na ˇcelni del poˇslje odgovor o uspeˇsnem posodabljanju igre.

Slika 4.6: Sekvenˇcni diagram shranjevanja igre

Seveda je za uspeˇsen razvoj igre potrebno redno testiranje sprememb in dodanih funkcionalnosti, zato lahko uporabnik svojo igro igra ˇze med razvijanjem. To stori tako, da pritisne na gumb ’Testiraj’, ki se nahaja na vrhu urejevalnika. Po kliku aplikacija uporabniku prikaˇze predogled pogleda za igranje iger.

(42)

4.6 Igranje igre

Na pogled za igranje iger lahko uporabnik pride bodisi preko urejevalnika iger ali pa preko izbora opcije ’Igraj’ na pregledu lastnih iger. Takoj ko uporabnik vstopi na pogled, ˇcelni del poˇslje GET zahtevek na naslov /games/id ter tako dobi trenutno verzijo igre.

Uporabniku se prikaˇze vmesnik za igranje iger (slika 4.7), ki je sestavljen iz treh delov. Na levi strani je prikazana slika lokacije, ki jo je avtor shranil na streˇznik preko urejevalnika lokacije. Sredinski del je sestavljen iz imena in opisa lokacije, pod katerima se nahaja kompas, ki uporabniku omogoˇca premikanje med lokacijami. Na desni strani je prikazan seznam akcij in predmetov, ki so na tej lokaciji na voljo uporabniku. Njegov cilj je, da se z zaˇcetne lokacije prebije na konˇcno in tako zakljuˇci igro, na poti pa mora reˇsiti uganke, ki jih je zastavil avtor.

Slika 4.7: Vmesnik za igranje iger

4.7 Podatkovne sheme

Zaledni sistem poskrbeti za trajno shranjevanje treh vrst entitet (uporabnik, igra in slika). V nadaljevanju tega poglavja so prikazane in opisane sheme le-teh.

(43)

Diplomska naloga 31

4.7.1 Uporabnik

Entiteta uporabnik predstavlja podatke, ki jih aplikacija hrani o vsakemu uporabniku. Seveda so za vsakega uporabnika najbolj kljuˇcni podatki tisti, ki jih uporablja za prijavo v aplikacijo. V naˇsem primeru sta to uporabnikov e-poˇstni naslov, ki se shrani v polje email, in geslo, ki je zabeleˇzeno v poljepassword. Poleg podatkov za prijavo pa se v polje name ob registraciji zabeleˇzi tudi uporabnikovo ime. Za morebitne nadgradnje v prihodnosti je vnaprej pripravljeno tudi polje role, ki je namenjeno razlikovanju razliˇcnih vrst uporabnikov, recimo navadnih in tistih z administracijskimi pravicami.

const User = new Schema({

name: {

type: String, },

email: {

type: String, unique: true, sparse: true, },

password: { type: String, },

role: {

type: String, },

});

4.7.2 Igra

Kot omenjeno je namen aplikacije kreacija pustolovskih iger. Podatki, ki se beleˇzijo o vsaki igri, so prikazani na spodnji shemi.

(44)

const GameModel = mongoose.Schema({

title: {

type: String, unique: true },

description: { type: String, default: ""

},

published: {

type: Boolean, default: false },

locations: { type: [], default: []

},

icon: { type: Schema.Types.ObjectId, ref: ’Image’ }, items: Object,

flags: Object, variables: Object gameSettings: {

type: {}, default: {}

},

ownerId: {

type: ObjectId }

});

Ob kreaciji igre mora avtor podati njeno ime (title) ter kratek opis, ki se

(45)

Diplomska naloga 33 hrani v polju description.

Poljelocations je namenjeno pomnenju vseh lokacij, ki jih igralec v sklopu igre lahko obiˇsˇce.

Med igro lahko igralec naleti na doloˇcene predmete, s katerimi lahko reˇsuje uganke in tako odkriva nove poti do ˇse neobiskanih lokacij. Podatki o pred- metih, ki so na voljo igralcu, so zabeleˇzeni v polj items.

V poljuflags je zapisan seznam zastavic, ki so namenjen hranjenju signa- lov kot naprimer ’Ali je uporabnik ˇze obiskal doloˇceno lokacijo?’.

Lastnik igre lahko za posamezno igro nastavi specifiˇcne omejitve, kot naprimer maksimalno ˇstevilo predmetov, ki jih igralec lahko prenaˇsa med lokacijami. Taki pogoji se zapiˇsejo v polje gameSettings.

Ker lahko vsak uporabnik ureja le lastne igre, je pomembno, da si za vsako igro v polje ownerId zabeleˇzimo unikaten identifikator uporabnika, ki je igro ustvaril.

Ko je avtor z igro zadovoljen, jo lahko deli z drugimi, v tem primeru se v polje published zapiˇse vrednost true.

4.7.3 Slika

Aplikacija uporabniku omogoˇca nalaganje slik, s katerimi lahko popestri iz- gled posamezne lokacije ali pa celotni igri doda logotip. Za vsako sliko se v polju ownerId hrani podatek o uporabniku, ki je sliko naloˇzil, v poljuname pa zgoˇsˇceno ime datoteke. Podatek o igri, kateri pripada slika, je shranjen v polje gameId. V primeru, da se uporabnik odliˇci za izbris igre, se pobriˇsejo tudi vse njene slike. Dejanska vsebina datoteke - torej slika - se shranjuje neposredno v pomnilnik streˇznika in ne v podatkovno bazo.

const Image = new Schema({

name: {

type: String, },

ownerId: {

(46)

type: ObjectId },

gameId: {

type: ObjectId }

});

(47)

Poglavje 5 Docker

Ker ˇzelimo, da aplikacija Odisej deluje predvidljivo, ne glede na to, kje se izvaja, bomo v nadaljevanju vse dele aplikacije zapakiral v docker vsebnike.

V sledeˇcem poglavju je prikazan celoten postopek ustvarjanja vsebnikov.

5.1 Konfiguracija vsebnikov

Glavni razlog za uporabo Dockerja je izolacija aplikacije, kar pomeni, da moramo za vsak del aplikacije (zaledni del, ˇcelni del in podatkovna baza) ustvariti Docker vsebnik ter jim omogoˇciti medsebojno komunikacijo preko skupnega omreˇzja. V poglavju 3.3 sem omenil, da za kreacijo vsebnikov po- trebujemo datoteke Dockerfile, navodila za povezovanje vsebnikov v omreˇzje pa skupaj z nekaterimi drugimi konfiguracijami zapiˇsemo v datoteko Docker- compose.

5.1.1 Dockerfile za zaledni del aplikacije

V spodnji konfiguraciji so napisana navodila za kreiranje slike zalednega sistema.

FROM node:8

35

(48)

WORKDIR /

COPY package.json ./

RUN npm install

COPY . /app WORKDIR /app

EXPOSE 8888

CMD [ "npm", "start" ]

Z ukazom

FROM node:8

v prvi vrstici datoteke povemo, da bi za osnovo slike zalednega sistema uporabili ˇze obstojeˇco sliko z imenom node:8, ki se avtomatsko prenese, ko je slika zalednega sistema ustvarjena.

Nato z ukazom

WORKDIR /

spremenimo delovni direktorij na /, iz katerega, se bodo izvajali vsi sledeˇci ukazi. Vanj z ukazom

COPY package.json ./

kopiramo seznam knjiˇznic, ki jih za delovanje potrebuje zaledni sistem ter jih namestimo z ukazom

RUN npm install

Z ukazoma

(49)

Diplomska naloga 37

COPY . /app WORKDIR /app

prenesemo izvorno kodo zalednega dela v direktorij/app ter povemo, naj se vsi sledeˇci ukazi izvajajo iz njega.

Na koncu pa z ukazoma

EXPOSE 8888

CMD [ "npm", "start" ]

povemo, naj vsebnik sprejema povezave na vratih 8888 ter zaˇzenemo aplikacijo.

Ko je konfiguracijska datoteka pripravljena, ustvarimo Docker sliko tako, da v terminal vpiˇsemo naslednji ukaz:

docker build -t odisej-front-end .

5.1.2 Dockerfile za ˇ celni del aplikacije

V spodnji konfiguraciji so napisana navodila za kreiranje slike ˇcelnega dela aplikacije.

FROM nginx:alpine

COPY nginx.conf /etc/nginx/conf.d/default.conf

WORKDIR /usr/share/nginx/html COPY build .

EXPOSE 80

CMD ["/bin/sh", "-c", "exec nginx -g ’daemon off;’"]

(50)

Prav tako kot konfiguracija zalednega sistema, se tudi ta zaˇcne z ukazom

FROM nginx:alpine

ki Docker-ju sporoˇci, da bi za osnovo naˇse slike uporabili obstojeˇco sliko nginx:alpine. Le-ta ima vnaprej nameˇsˇcen spletni streˇznik nginx, s katerim uporabnikom omogoˇcimo dostop do spletnega vmesnika. Za pravilno delovanje nginx potrebuje konfiguracijsko datoteko, ki jo v Docker vsebnik prenesemo z naslednjim ukazom:

COPY nginx.conf /etc/nginx/conf.d/default.conf

V konfiguracijski datotekinginx.conf je zapisano, da naj spletni streˇznik sprejema povezave na vratih 80 ter da naj na zahtevke odgovori z datoteko index.html, ki se nahaja na /usr/share/nginx/html. Vsebina datoteke nginx.conf je prikazana na sliki 5.1.

Slika 5.1: Konfiguracijska datoteka nginx.conf

Kot omenjeno, spletni streˇznik nginx na zahtevke odgovarja z datotekoin- dex.html, zato z naslednjima ukazoma na lokacijo/usr/share/nginx/html prenesemo distribucijske datoteke ˇcelnega dela, med katerimi je tudi index.html.

WORKDIR /usr/share/nginx/html COPY build .

(51)

Diplomska naloga 39 V zadnjem koraku povemo, naj Docker vsebnik sprejema povezave na vratih 80 ter zaˇzenemo spletni streˇznik nginx.

EXPOSE 80

CMD ["/bin/sh", "-c", "exec nginx -g ’daemon off;’"]

Ko je konfiguracijska datoteka pripravljena, ustvarimo Docker sliko tako, da v terminal vpiˇsemo naslednji ukaz:

docker build -t odisej-front-end .

5.2 Docker Compose

Kot omenjeno, je aplikacija sestavljena iz treh Docker slik. Konfiguracija slik za ˇcelni in zaledni del je sedaj ˇze pripravljena, za podatkovno bazo pa lahko uporabimo kar uradno slikomongo, zato posebna konfiguracija ni potrebna.

V konfiguracijski datoteki dockercompos.yaml najprej definiramo, katere storitve vsebuje aplikacija. V primeru aplikacije Odisej so to storitvemongo, front-end in back-end, nato pa vsaki izmed storitev dodelimo Docker sliko.

version: ’3.1’

services:

mongo:

image: mongo:latest restart: always ports:

- 27018:27017 front-end:

image: odisej-front-end restart: always

(52)

ports:

- 80:80 back-end:

image: odisej-back-end restart: always

ports:

- 9999:8888

Z ukazomdocker-compose up -d zaˇzenemo vse vsebnike, nato pa z ukazom docker ps -a preverimo, ˇce so se vsi uspeˇsno zagnali.

Slika 5.2: Uspeˇsno zagnani vsebniki

Kljub temu, da so vsi vsebniki zagnani, pa aplikacija ˇse zmeraj ne deluje, saj vsebniki ne morejo komunicirati med seboj, zato v naslednjem koraku v konfiguracijski datoteki definiramo skupno omreˇzje.

networks:

odisej-network:

Na koncu pa vse storitve vkljuˇcimo v omreˇzje odisej-network.

V naslednjem delu je prikazana konˇcna verzija konfiguracijske datoteke dockercompose.yaml

version: ’3.1’

services:

mongo:

image: mongo:latest

(53)

Diplomska naloga 41 restart: always

ports:

- 27018:27017 networks:

- odisej-network volumes:

- odisej-db:/data/db

front-end:

image: odisej-front-end restart: always

ports:

- 80:80 networks:

- odisej-network

back-end:

image: odisej-back-end restart: always

ports:

- 9999:8888 networks:

- odisej-network environment:

MONGO_URI: mongodb://mongo:27017/odisej

networks:

odisej-network:

volumes:

odisej-db:

(54)

(55)

Poglavje 6 Zakljuˇ cek

V sklopu diplomske naloge smo najprej predstavili aplikacijo Odisej, katere namen je sooˇcanje s temeljnimi koncepti programiranja skozi ustvarjanje pustolovskih igric. Skozi konkreten primer uporabe smo si ogledali njeno delovanje ter funkcionalnosti, ki jih omogoˇca uporabnikom. Navedli pa smo tudi nekaj kljuˇcnih pomanjkljivosti, ki so nastale kot posledica manjkajoˇcega zalednega sistema.

V nadaljevanju smo primerjali prednosti in slabosti monolitne in mikro- storitvene arhitekture ter se na podlagi le-teh odloˇcili, da bomo za zaledni sistem uporabili monolitno arhitekturo. Prav tako smo primerjali prednosti in slabosti relacijskih in nerelacijskih podatkovnih baz ter si razliko konkretno ogledali na preprostem primeru. Na podlagi primerjave smo se odloˇcili, da je za aplikacijo Odisej najbolj primerna dokumentno usmerjena nerelacijska podatkovna baza. Skozi primerjavo sem poglobil svoje znanje o razliˇcnih arhitekturah in tipih podatkovnih baz, kar mi bo omogoˇcalo boljˇse naˇcrtovanje aplikacij.

Sledilo je poglavje, v katerem je najprej opisan naˇcin komunikacije med ˇcelnim in zalednim delom aplikacije, prav tako pa smo definirali nekaj osnov- nih pojmov, na katere se sklicujemo v nadaljevanju. Za tem smo s pomoˇcjo sekvenˇcnih diagramov in izsekov kode podrobneje predstavili kljuˇcne funkcionalnosti novega zalednega sistema. Kljub temu da mi implementacija

43

(56)

zalednega sistema ni povzroˇcala prevelikih teˇzav, sem pridobil veliko novih znanj kot na primer, kako implementirati shranjevanje slik na streˇzniku ter kako narediti sistem za potrjevanje registracij preko e-poˇstnih sporoˇcil.

Za zakljuˇcek smo predstavili postopek kreacije Docker vsebnikov, ki omo- goˇcajo preprosto namestitev aplikacije na gostujoˇci streˇznik. Ker se z Doc- kerjem ˇse nisem veliko ukvarjal, mi je ta del diplomske naloge predstavljal najveˇcji izziv. Nauˇcil sem se kreirati Docker slike, prav tako pa sem pridobil globlje razumevanje o njegovem delovanju.

Upam, da nov zaledni sistem aplikaciji Odisej predstavlja nadgradnjo in poslediˇcno boljˇso podlago za nadaljnjo uˇcenje programiranja konˇcnih uporabnikov.

(57)

Clanki v revijah ˇ

[2] Antonio Bucchiarone in sod. “From Monolithic to Microservices: An Experience Report from the Banking Domain”. V:IEEE Software 35.3 (2018), str. 50–55.doi: 10.1109/MS.2018.2141026.

[11] ARMIN MAKOVEC. “Razvoj sodobne aplikacije v oblaku”. V: (2020).

url: https://repozitorij.uni- lj.si/IzpisGradiva.php?lang=

slv&id=114418.

45

(58)

(59)

Clanki v zbornikih ˇ

[3] J¨urgen Cito, Vincenzo Ferme in Harald C. Gall. “Using Docker Con- tainers to Improve Reproducibility in Software and Web Engineering Research”. V:Web Engineering. Ur. Alessandro Bozzon, Philippe Cudre- Maroux in Cesare Pautasso. Cham: Springer International Publishing, 2016, str. 609–612.isbn: 978-3-319-38791-8.

[20] Francisco Ponce, Gastón Márquez in Hernán Astudillo. “Migrating from monolithic architecture to microservices: A Rapid Review”. V:

2019 38th International Conference of the Chilean Computer Science Society (SCCC). 2019, str. 1–7. doi: 10 . 1109 / SCCC49216 . 2019 . 8966423.

47

(60)

(61)

Celotna literatura

[1] Blockly.js. url: https://developers.google.com/blockly (pridobljeno 5. 9. 2021).

[2] Antonio Bucchiarone in sod. “From Monolithic to Microservices: An Experience Report from the Banking Domain”. V:IEEE Software 35.3 (2018), str. 50–55.doi: 10.1109/MS.2018.2141026.

[3] J¨urgen Cito, Vincenzo Ferme in Harald C. Gall. “Using Docker Con- tainers to Improve Reproducibility in Software and Web Engineering Research”. V:Web Engineering. Ur. Alessandro Bozzon, Philippe Cudre- Maroux in Cesare Pautasso. Cham: Springer International Publishing, 2016, str. 609–612.isbn: 978-3-319-38791-8.

[4] Docker Compose. url: https://github.com/docker/compose (pridobljeno 5. 9. 2021).

[5] Express. url: https://expressjs.com/ (pridobljeno 5. 9. 2021).

[6] Express Wikipedija.url:https://en.wikipedia.org/wiki/Express.

js (pridobljeno 5. 9. 2021).

[7] Nedim Husakoviˇc. Primerjava in analiza uˇcinkovitosti podatkovnih baz DB2 in MySQL: diplomsko delo: visokoˇsolski ˇstudijski program prve stopnje Raˇcunalniˇstvo in informatika. Bibliografija: str. 51-53 Povzetek;

Abstract: Comparison and performance analysis of DB2 and MySQL databases. [N. Husakovi´c], 2017. url: http : / / eprints . fri . uni - lj.si/4024/.

49

(62)

[8] jsonwebtoken.url:https://www.npmjs.com/package/jsonwebtoken (pridobljeno 5. 9. 2021).

[9] Nataˇsa Knez.Primerjava relacijske in NoSQL podatkovne baze in opre- delitev kriterijev za pomoˇc pri izbiri najprimernejˇse podatkovne baze:

diplomsko delo. Vzporedni stv. nasl. na spremnem listu: Comparison of relational and NoSQL DBMS and the determination of criteria for the selection of most appropriate DBMS Bibliografija: str. 89-92 Pov- zetek; Abstract. [N. Knez], 2012. url: http : / / eprints . fri . uni - lj.si/1630/.

[10] Alja Kunovar. Pregled in primerjava nerelacijskih podatkovnih baz kot storitev: diplomsko delo. Vzporedni nasl. na spremnem listu: Review of NoSQL databases as a service Bibliografija: str. 53-58 Povzetek;

Abstract. [A. Kunovar], 2013. url: http://eprints.fri.uni- lj.

si/2190/.

[11] ARMIN MAKOVEC. “Razvoj sodobne aplikacije v oblaku”. V: (2020).

url: https://repozitorij.uni- lj.si/IzpisGradiva.php?lang=

slv&id=114418.

[12] Azat Mardan, Mardan in Corrigan. Practical Node. js. Springer, 2018.

[13] MongoDB. url:https://www.mongodb.com/ (pridobljeno 5. 9. 2021).

[14] MongoDB. Kaj so nerelacijske baze? url: https : / / www . mongodb . com/non-relational-database(pridobljeno 5. 9. 2021).

[15] Mongoose.Mongoose - elegantno mongodb modeliranje objektov za node.js.

url: https://mongoosejs.com/ (pridobljeno 5. 9. 2021).

[16] Nalaganje datotek z uporabo Multer, Node.js in Express. url: https:

//code.tutsplus.com/tutorials/file-upload-with-multer-in- node--cms-32088(pridobljeno 5. 9. 2021).

[17] Nginx. url: https://www.nginx.com/resources/wiki/ (pridobljeno 5. 9. 2021).

[18] Node.js. url:https://nodejs.org/en/ (pridobljeno 5. 9. 2021).

(63)

Diplomska naloga 51 [19] Nodemailer. url: https : / / nodemailer . com / about/ (pridobljeno

5. 9. 2021).

[22] Razlike med tradicionalnimi monolitnimi in mikro-storitvenimi aplikacijami.url:https://rancher.com/img/blog/2019/microservices- vs-monolithic- architectures/microservices- and-monolithic- architectures.jpg(pridobljeno 5. 9. 2021).

[23] React.url: https://reactjs.org/(pridobljeno 5. 9. 2021).

[24] Uvod v docker. url: https://itnext.io/intro- to- docker- part- 1-5b1162c81735(pridobljeno 5. 9. 2021).

[25] Uvod v JWT ˇzetone. url: https : / / jwt . io / introduction (pridobljeno 5. 9. 2021).

[26] W3Schools.Node.js vodiˇc.url:https://www.w3schools.com/nodejs/

(pridobljeno 5. 9. 2021).

[27] ˇSpela Zavrl. “Projekt izdelave pustolovskih iger: uˇcenje programiranja z medpredmetnim povezovanjem”. Doktorska disertacija. Univerza v Ljubljani, Pedagoˇska fakulteta, 2021. url: http://pefprints.pef.

uni-lj.si/6610/.