Analysis and web solutions` development based on the MEAN.JS framework

Full text

(1)UNIVERZA V MARIBORU FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO. Lovro Hudrap. ANALIZA IN RAZVOJ SPLETNIH REŠITEV NA OSNOVI OGRODJA MEAN.JS Diplomsko delo. Maribor, avgust 2017.

(2)

(3) ANALIZA IN RAZVOJ SPLETNIH REŠITEV NA OSNOVI OGRODJA MEAN.JS Diplomsko delo. Študent(ka):. Lovro Hudrap. Študijski program:. Univerzitetni študijski program informatika in tehnologije komuniciranja. Smer:. Informacijski sistemi. Mentor(ica):. doc. dr. Boštjan Šumak, univ. dipl. inž. rač. in inf.. Lektor(ica):. Miroslav Osojnik, upok. muzejski strokovni sodelavec. i.

(4) ii.

(5) Zahvala Zahvaljujem se mentorju, doc. dr. Boštjanu Šumaku, za strokovno pomoč in vodenje pri opravljanju diplomskega dela. Posebna zahvala gre staršem, starim staršem in punci, ki so mi ves čas stali ob strani in me spodbujali ob študiju.. iii.

(6) Analiza in razvoj spletnih rešitev na osnovi ogrodja MEAN.JS Ključne besede: Node, Express, Angular, MongoDB, razvoj, analiza. UDK: 004.383.2:004.738.5(043.2). Povzetek V tem diplomskem delu smo se spoznali s skupkom ogrodij MEAN, ki zagotavlja razvoj celovitih spletnih rešitev. Za lažje razumevanje principov razvoja z uporabo omenjenega skupka ogrodij smo razvili spletno rešitev imenik, ki uporabnikom omogoča urejanje seznama oseb s pripisanimi telefonskimi številkami. Skozi razvoj spletne rešitve smo spoznali več storitev, knjižnic in ogrodij, ki jih lahko vključimo v sam razvoj. Spoznali smo se tudi z orodji za izvedbo testov zmogljivosti spletnih rešitev, izvedli serijo testov in grafično prikazali pridobljene metrike.. iv.

(7) Analysis and web solutions development based on the MEAN.JS framework Key words: Node, Express, Angular, MongoDB, development, analysis. UDK: 004.383.2:004.738.5(043.2). Abstract In this diploma thesis we were introduced to the fullstack framework MEAN, that provides the development of comprehensive web solutions. In order to better understand the principles of development using the fullstack framework we mentioned above, we developed an online contact list solution that allows users to edit the list of people with assigned phone numbers. Through the development of the web solution we were introduced to several services, libraries and frameworks that can be integrated into the development itself. We also got acquainted with the tools for carrying out tests of the web solutions performance, performed a series of tests and presented the obtained metrics graphically.. v.

(8) KAZALO 1. UVOD .................................................................................................................................... 0. 2. PROGRAMSKO OGRODJE MEAN.JS ZA RAZVOJ SODOBNIH SPLETNIH REŠITEV .................. 3. 3. 4. 2.1. MONGODB .................................................................................................................... 6. 2.2. NODE.JS ....................................................................................................................... 10. 2.3. EXPRESS....................................................................................................................... 15. 2.4. ANGULARJS ................................................................................................................. 18. NAČRTOVANJE IN RAZVOJ SPLETNE REŠITVE NA OSNOVI OGRODJA MEAN.JS ................. 22 3.1. NAČRT ......................................................................................................................... 22. 3.2. IZGRADNJA SPLETNE REŠITVE ..................................................................................... 23. TESTIRANJE IN ANALIZA ..................................................................................................... 36 4.1. ORODJA ZA IZVEDBO TESTIRANJA .............................................................................. 36. 4.2. POSTOPEK IZVEDBE TESTIRANJA IN ANALIZA PRIDOBLJENIH METRIK ....................... 38. 4.3. ANALIZA PRIDOBLJENIH METRIK ................................................................................ 43. 5. SKLEP .................................................................................................................................. 49. 6. VIRI IN LITERATURA ............................................................................................................ 50. vi.

(9) KAZALO SLIK. Slika 1.1: Priljubljenost programskih jezikov glede na platformi Github in Stack Overflow [18] 1 Slika 2.1: Rast iskalcev dela na platformi Indeed, ki so vešči v razvoju pogleda in funkcionalnosti [8] ................................................................................................................................................. 4 Slika 2.2: Arhitektura spletne rešitve zgrajene s skupkom ogrodij MEAN [1] ............................. 5 Slika 2.3: Primer tabele v relacijskem podatkovnem modelu in dokumenta v dokumentno orientiranem podatkovnem modelu [6]...................................................................................... 8 Slika 2.4: Primer normalizacije za pivovarne v relacijskem podatkovnem modelu [6] ............... 9 Slika 2.5: Primer reference enega dokumenta na drugega v dokumentno orientirani podatkovni bazi [6] ......................................................................................................................................... 9 Slika 2.6: Princip delovanja strežnika implementiranega z ogrodjem Node.js [17] .................. 11 Slika 2.7: Primer večnitnega delovanja strežnika [11]............................................................... 13 Slika 2.8: Primer enonitnega delovanja strežnika [1] ................................................................ 15 Slika 2.9: Tok prejete zahteve skozi spletno rešitev zgrajeno z ogrodjem Node.js [9] ............. 17 Slika 2.10: Tok prejete zahteve skozi spletno rešitev zgrajeno z ogrodjem Express [9] ........... 18 Slika 2.11: Primer enosmerne vezave podatkov [1] .................................................................. 20 Slika 2.12: Primer dvosmerne vezave podatkov [1] .................................................................. 21 Slika 3.1: Diagram primera uporabe spletne rešitve Imenik ..................................................... 22 Slika 3.2: Kreiranje nove mape v ukazni vrstici ......................................................................... 24 Slika 3.3: Odvisnosti, ki smo jih dodali v dokumentu package.json .......................................... 24 Slika 3.4: Podatkovna shema implementirana v datoteki kontakti.js ....................................... 25 Slika 3.5: Implementiran strežnik .............................................................................................. 26 Slika 3.6: Implementirana obravnava HTTP zahteve GET na poti /kontakti ............................. 27 Slika 3.7: Implementirana obravnava HTTP zahteve POST na poti /kontakt ............................ 27 Slika 3.8: Implementirana obravnava HTTP zahteve DELETE na poti /kontakt/:id ................... 28. vii.

(10) Slika 3.9: Primer uporabe storitve Postman za preverjanje delovanja kreiranja novega kontakta ................................................................................................................................................... 28 Slika 3.10: Namestitev vmesnika za ukazno vrstico .................................................................. 29 Slika 3.11: Implementirane metode, ki skrbijo za interakcijo med pogledom in razvito logiko spletne rešitve na strežniški strani ............................................................................................ 30 Slika 3.12: Razred Kontakt ......................................................................................................... 30 Slika 3.13: Injekcija storitve KontaktService v konstruktorju .................................................... 31 Slika 3.14: Implementacija metode za dodajanje novih kontaktov .......................................... 32 Slika 3.15: Implementacija metode za izbris kontakta .............................................................. 32 Slika 3.16: Implementacija metode, ki izvede ob zagonu komponente v brskalniku ............... 33 Slika 3.17: Obrazec za dodajanje novih kontaktov .................................................................... 34 Slika 3.18: Implementacija prikaza seznama kontaktov............................................................ 34 Slika 3.19: Končni izgled spletne rešitve Imenik ........................................................................ 35 Slika 4.1: V brskalnik Google Chrome vgrajeno orodje za analiziranje zmogljivosti spletnih rešitev ........................................................................................................................................ 38 Slika 4.2: Dopolnjena metoda za dodajanje novih kontaktov ................................................... 39 Slika 4.3: Ukaz za namestitev orodja Loadtest .......................................................................... 40 Slika 4.4: Ukaz za izvedbo testiranja .......................................................................................... 40. KAZALO TABEL. Tabela 4.1: Sistemske lastnosti računalnika .............................................................................. 36 Tabela 4.2: Zmožnost paralelnega izvajanja povezav [15] ........................................................ 37 Tabela 4.3: Metrike pridobljene z merjenjem časa potrebnega za prikaz elementov .............. 39 Tabela 4.4: Metrike pridobljene z merjenjem časa potrebnega za izvedbo 1000 zahtev ........ 41 Tabela 4.5: Metrike pridobljene z merjenjem časa potrebnega za izvedbo 1000 zahtev ........ 42. viii.

(11) KAZALO GRAFOV. Graf 4.1: Povprečen čas potreben za prikaz različnih količin elementov.................................. 44 Graf 4.2: Čas potreben za izvedbo 1000 zahtev glede na število sočasno izvedenih zahtev .... 45 Graf 4.3: Čas potreben za izvedbo 1000 zahtev glede na število sočasno izvedenih zahtev .... 46 Graf 4.4: Odstotek od 1000 obdelav zahtev, ki se izvedejo v določenem času glede na število sočasno izvedenih zahtev .......................................................................................................... 47 Graf 4.5: Odstotek od 10000 obdelav zahtev, ki se izvedejo v določenem času glede na število sočasno izvedenih zahtev .......................................................................................................... 48. ix.

(12) UPORABLJENE KRATICE. HTML – označevalni jezik za oblikovanje večpredstavnostnih dokumentov (Hyper Text Markup Language) CSS – stilna predloga spletne strani (Cascading Style Sheets) MVC – arhitektura model-pogled-nadzornik (Model View Controller) MVVM – arhitektura model-pogled-pogled-model (Model View View Model) MEAN – ogrodja MongoDB, Express, Angular, Node (frameworks MongoDB, Express, Angular, Node) JSON – format za izmenjavo v zapisu Javascript (JavaScript Object Notation) HTTP – glavna metoda za prenos informacij na spletu (HyperText Transfer Protocol) JPEG – rastrski slikovni format (Joint Photographic Experts Group) CORS – deljenje virov med različnimi izvori (Cross-origin resource sharing) REST – arhitektura za izmenjavo podatkov med spletnimi storitvami (Representational State Transfer). x.

(13) 1 UVOD. Spletne strani, ki so se pojavile leta 1990 vzporedno z nastankom svetovnega spleta, so bile zgrajene statično. Uporabnik je lahko dostopal do spletne strani, ki je bila zgrajena le iz besedila in povezav. Njegova interakcija na vsebine objavljene na spletni strani ni imela vpliva. Zaradi potrebe po interakciji spletne rešitve glede na akcije uporabnikov je bil leta 1995 kot način za vgradnjo programov v spletne strani na spletnem brskalniku Netscape predstavljen programski jezik Javascript. Od izida jezika pa do danes je bil sprejet tudi v vseh drugih večjih grafičnih brskalnikih (npr. Google, Yahoo, Bing). Lahko trdimo, da je programski jezik Javascript izoblikoval splet, kot ga poznamo danes. Omogočil je izgradnjo spletnih rešitev, kjer lahko uporabnikova interakcija direktno vpliva na prikaz vsebin brez potrebe po osvežitvi strani za vsako izvedeno akcijo. Po sprejetju programskegajezika tudi v drugih spletnih brskalnikih je bil v namen zagotavljanja avtentičnosti spisan standardni dokument, ki je opisoval delovanje programskega jezika. Dokument se je imenoval ECMAScript po internacionalni organizaciji Ecma, ki je jezik standardizirala. V praksi se za programski jezik uporabljata obe imeni ECMAScript in JavaScript [10].. Na priljubljenost (Slika 1.1) programskega jezika JavaScript je v veliki meri vplival tudi pojav ogrodij, ki so jeziku omogočila razvoj aplikacij na strani strežnika.. 0.

(14) Slika 1.1: Priljubljenost programskih jezikov glede na platformi Github in Stack Overflow [18]. Prednosti programskega jezika JavaScript [1]: -. Omogoča hiter in fleksibilen razvoj. -. Velika izbira knjižnic, ogrodij in tehnologij. -. Uporaba istega jezika na strani strežnika in odjemalca. 1.

(15) V tej diplomski nalogi smo raziskali funkcionalnosti in zmogljivosti skupka ogrodij MEAN (frameworks MongoDB, Express, Angular, Node), ki zajema ogrodja Node, Express, AngularJS in MongoDB. V ta namen smo razvili spletno rešitev imenik. Z ogrodji Node in Express smo implementirali spletni strežnik, z ogrodjem MongoDB vzpostavili podatkovno bazo in z ogrodjem Angular 2 implementirali pogled spletne rešitve. Nad razvito spletno rešitvijo smo z uporabo v brskalnik Google Chrome vgrajenih orodij in orodja Loadtest izvedli serijo testov in merili zmogljivost spletne rešitve ter pridobljene metrike prikazali v obliki tabel in grafov.. V prvem delu diplomskega dela smo bralcu ponudili vpogled v nastanek ogrodij in mu podrobneje predstavili ogrodja zajeta v omenjenem skupku. Nato smo v drugem delu pričeli z razvojem in predstavitvijo razvoja spletne rešitve, ki smo jo v tretjem delu, kjer predstavimo orodja in metode za izvedbo testiranja, uporabili za izvedbo testov in predstavitev zmogljivosti.. 2.

(16) 2 PROGRAMSKO OGRODJE MEAN.JS ZA RAZVOJ SODOBNIH SPLETNIH REŠITEV. V zgodnjem razvoju spleta razvijalci od spletnih strani niso pričakovali veliko. Glavni del pozornosti je bil usmerjen v razvoj logike delovanja spletnih strani [1]. Z vedno več uporabniki interneta se je večala tudi potreba po boljši grafični prisotnosti spletnih rešitev. To potrebo je zapolnil programski jezik JavaScript, ki je v prej toge spletne rešitve, razvite le z uporabo označevalnega jezika HTML (Hyper Text Markup Language), vpeljal interaktivnost. Leta 1998 je ta napredek dopolnil izid programskega jezika CSS (Cascading Style Sheets), ki je omogočil strukturirano oblikovanje. Temeljni koncept jezika je bil ločiti vsebino od predstavitve [20]. Tako pri razvoju spletnih strani ni bil več v ospredju le razvoj strani z uporabo označevalnega jezika HTML, ampak so za razvoj kakovostnih spletnih strani bili razvijalci primorani vložiti čas v razvoj z uporabo jezikov JavaScript in CSS, ter s tem posledično vplivati na dober videz in nemoteno delovanje. S tem se je začelo razlikovanje med razvijalci, ki so se odločili za razvoj pogleda, in tistimi, ki so razvijali funkcionalnosti delovanja spletnih rešitev. Medtem ko so se razvijalci funkcionalnosti osredotočili na razvoj logike, so se razvijalci pogleda osredotočili na zagotavljanje dobre uporabniške izkušnje. Med razvijalci pogleda in razvijalci logike delovanja so rastla pričakovanja, ki so spodbujala ločen trend razvijanja. Tako so se zaradi trenda razvijalci bili primorani odločiti le za eno plat razvijanja spletnih rešitev [1].. Leta 2000 so se pojavili razvijalci, ki so bili sposobni razviti in dostaviti celotno spletno rešitev [28]. Na ta način razvoja je vplival pojav ogrodij in knjižnic, ki so po priljubljenosti uporabe začela premagovati prej vodilne programske jezike. Pojavili so se Dojo in jQuery za JavaScript, CodeIgniter za PHP in Ruby on Rails za Ruby [1]. Knjižnice in ogrodja so se pojavili zaradi potrebe po izboljšanju infrastrukture programske kode. Zasnovani so bili, da bi omogočili lažji in hitrejši razvoj, kjer lahko z manj vrsticami kode dosežemo isti rezultat kot z uporabo prej 3.

(17) poznanih tehnologij [13]. Trend poenostavljanja razvoja spletnih rešitev z uporabo ogrodij in knjižnic je povzročil porast med razvijalci, ki so bili vešči v razvoju funkcionalnosti in pogleda spletnih rešitev (Slika 2.1) [1].. Slika 2.1: Rast iskalcev dela na platformi Indeed, ki so vešči v razvoju pogleda in funkcionalnosti [8]. Pokazati želimo, da zaradi obstoja ogrodij za zagotavljanje kakovostnega razvoja spletnih rešitev med razvijalci ni potrebe po odločanju le za eno plat razvoja [1]. Razvijalci, ki so vešči razvoja z uporabo ogrodij in sposobni razvijati tako funkcionalnost kot pogled spletnih rešitev, lahko lažje preklopijo iz enega dela razvoja na drugega, saj dobro razumejo hierarhijo spletnih rešitev, kar predstavlja veliko prednost pri snovanju novih funkcionalnosti [16].. 4.

(18) S sledenjem trendom razvoja z uporabo ogrodij se je v zadnjih nekaj letih povečala tudi potreba po prestavitvi implementacije logike v zakulisju na razvoj pogleda. Glavni razlog za uporabo tega pristopa je zmanjšanje obremenitve strežnika in posledično zmanjšanje stroškov delovanja. Med nekaj najpopularnejšimi ogrodji, ki omogočajo ta pristop, so AngularJS, Backbone in Ember. Tesno povezovanje programske kode pogleda in funkcionalnosti, kot ga podpirajo omenjena ogrodja, zamegli tradicionalni pristop razvoja spletnih rešitev [1].. Skupek ogrodij MEAN (MongoDB, Express, Angular, Node) (Slika 2.2) je razvil Valeri Karpov, takratni razvijalec MongoDB podatkovne baze. Prvič je izraz MEAN omenil v objavi na blogu leta 2013 [12]. Akronim MEAN predstavlja skupek tehnologij za katere je znano, da tvorijo dobro celoto. Glavna prednost skupka ogrodij je preprosto oblikovanje prototipa. Ogrodje Node.js omogoča, da lahko celotno spletno rešitev razvijete le s poznavanjem programskega jezika JavaScript. Poleg tega podatkovna baza MongoDB omogoča hitro spreminjanje podatkov brez oziranja na migracije, kar je izrednega pomena, ko poskušate zgraditi rešitev brez jasnih specifikacij. Tehnologije zajete v skupku ogrodij imajo tudi veliko podporo skupnosti, tako da je iskanje odgovorov pri pomanjkljivemu poznavanju preprosto [25].. Slika 2.2: Arhitektura spletne rešitve zgrajene s skupkom ogrodij MEAN [1]. 5.

(19) Skupek ogrodij MEAN je odprtokodni skupek JavaScript ogrodij, ki omogoča dinamično grajenje robustnih spletnih strani in spletnih rešitev. Ogrodje sestavljajo štiri glavne komponente, ki omogočajo razvoj aplikacij na strani strežnika in odjemalca. Komponente, ki sestavljajo MEAN ogrodje so [1]: -. MongoDB – podatkovna baza. -. Express – ogrodje za razvoj spletnih rešitev. -. AngularJS –ogrodje za razvoj pogleda. -. Node.js – spletni strežnik. 2.1 MONGODB. Sposobnost shranjevanja in uporabe podatkov je bistvenega pomena za večino kompleksnejših aplikacij. Izbrana podatkovna baza v skladu ogrodij MEAN je podatkovna baza MongoDB [1]. Podatkovna baza MongoDB je robustna, prilagodljiva in razširljiva splošno namenska baza podatkov. Podpira funkcionalne možnosti, kot so [4]: -. Sekundarni indeksi. -. Poizvedbe po obsegu. -. Razvrščanje. -. Agregacije. -. Geoprostorski indeksi. 6.

(20) V dokumentno orientiranih podatkovnih bazah so entitete shranjene kot JSON (JavaScript Object Notation) dokumenti. Ta pristop razvoja podatkovne baze se razlikuje od shranjevanja podatkov v vrstice v tabeli kot smo ga vajeni pri relacijskem podatkovnem modelu. V relacijskem podatkovnem modelu je potrebno za vsako tabelo definirati shemo [14]. V shemi se določi struktura podatkovne baze, ki predstavlja načrt za tabele in relacije med tabelami. Za vsako tabelo je potrebno definirati omejitve za posamezne vrstice in jim določiti podatkovne tipe [6]. V nasprotju z relacijskim podatkovnim modelom za dokumentno orientirano podatkovno bazo ni potrebno definirati sheme in je lahko vsak dokument strukturiran drugače [14]. Dokumentno orientirana podatkovna baza vsebuje dokumente, v katerih so zapisane definicije podatkov in podatki sami. Kompleksnost posameznih dokumentov je odvisna od implementacije dokumentov. Razvijalci lahko uporabijo tudi možnost vgnezdenih podatkov za predstavitev podkategorij objekta [6]. Dokumentno orientiran podatkovni model podpira lažje prilagajanje in spreminjanje strukture baze podatkov. Prednost relacijske podatkovne baze MongoDB je njena zmogljivost. Podatkovna baza MongoDB na dokumentih ob kreiranju rezervira dinamičen prostor, jim pred-dodeli prostor na pomnilniku in čim več dokumentov ohranja na predpomnilniku. Samodejno poskuša izbrati najbolj optimalen indeks za izvedbo povpraševanj. Čeprav podatkovna baza MongoDB ohranja večino funkcij relacijske podatkovne baze, v vseh primerih tega ni zmožna. V primerih, ko je mogoče, podatkovni strežnik prenese procesiranje in logiko delovanja na stran odjemalca, ohranjanje te racionalne oblike delovanja pa je eden glavnih razlogov za doseganje visokih zmogljivosti [4].. Princip delovanja dokumentno orientirane podatkovne baze lahko najlažje prikažemo na primeru (Slika 2.3). Relacijska podatkovna baza vsebuje tabelo, ki zajema piva in njihove atribute: id, naziv, pivovarna in zaloga. Za tabelo zapišemo shemo, v kateri definiramo namen in tip podatkov. V enakovrednem dokumentno orientiranem podatkovnem modelu za vsako pivo ustvarimo nov dokument. Vsak za izbrano pivo ustvarjen dokument vsebuje iste vrste informacije [6]. 7.

(21) Slika 2.3: Primer tabele v relacijskem podatkovnem modelu in dokumenta v dokumentno orientiranem podatkovnem modelu [6]. V primeru dodajanja novih atributov pivu je v relacijskem podatkovnem modelu potrebno spremeniti shemo, tako da vključuje dodatne stolpce in podatke o njihovem tipu. Pri dokumentno orientiranem podatkovnem modelu v tem primeru zgolj posodobimo vsebino dokumenta [6].. Ena izmed razlik med omenjenima podatkovnima modeloma je povezana z normalizacijo. V relacijskem podatkovnem modelu si prizadevamo podatke čim bolj normalizirati. To pomeni, da se izogibamo podvajanju podatkov in vzdržujemo ločene tabele za vsako entiteto, kjer lahko z združitvijo tabel zagotovimo popoln pregled podatkov (Slika 2.4) [14]. V primeru, da ne bi ločili tabel pivo in pivovarji, bi pri vsakem pivu ponavljali podatke o pivovarjih. Slabost, ki jo prinaša normalizacija, je potreba po zaklenitvi tabel v primeru spreminjanja vnosov zaradi zagotavljanja doslednega spreminjanja [6].. 8.

(22) Slika 2.4: Primer normalizacije za pivovarne v relacijskem podatkovnem modelu [6]. V dokumentno orientirani podatkovni bazi lahko podatke porazdelimo v dva dokumenta z različnima strukturama (Slika 2.5). En dokument je s strukturo primerno za entiteto piva in drugi za pivovarne. V tem primeru imamo dve pivi iz pivovarne Amstel. Vsako izmed dveh piv predstavimo v ločenem dokumentu in podamo referenco na pivovarno v polju pivovarna [6].. Slika 2.5: Primer reference enega dokumenta na drugega v dokumentno orientirani podatkovni bazi [6] 9.

(23) 2.2 NODE.JS. Leta 2009 je na evropski JS konferenci razvijalec programske opreme Ryan Dahl predstavil platformo, ki združuje Googlov V8 JavaScript programski pogon z namenom kreiranja strežniške platforme postavljene s programskim jezikom JavaScript. Projekt je bil poimenovan Node.js ali samo Node. Razvoj se je usmeril vstran od prej poznanih strežniških JavaScript platform [27].Ogrodje samo po sebi ne predstavlja spletnega strežnika, vsebuje pa vgrajene HTTP (HyperText Transfer Protocol) strežniške knjižnice. Vgrajene HTTP knjižnice omogočijo samostojen razvoj strežnika, kar nudi boljšo kontrolo [1]. Vsi vhodno/izhodni elementi ogrodja so dogodkovno usmerjeni. Vpliv moči in preprostosti programskega jezika JavaScript je spreobrnil zahteven razvoj asinhronih aplikacij v preprostega [27].. Ogrodje Node.js zagotavlja nemoten vhodno/izhodni sistem (Slika 2.6), ki razvijalcem omogoča simultano obdelavo številnih zahtev. Vhodne zahteve so razporedijo v čakalno vrsto in se izvršujejo zaporedoma [10]. Poleg hitrosti programskega jezika predstavlja srce ogrodja Node.js zanka dogodkov [3]. Zaradi zanke dogodkov je omogočeno nemoteno delovanje strežnika le na eni niti. Vedno, ko se na strežniku implementiranim z ogrodjem Node.js izvede sistemski klic, se bo ta prenesel v zanko dogodkov skupaj s funkcijo povratnega klica. Glavna nit bo medtem stregla drugim zahtevam. Takoj, ko se prejšnji sistemski klic izvrši, bo zanka dogodkov izvedla vrnjeno povratno funkcijo. Vrnjena povratna funkcija bo obravnavala vrnjen rezultat in nadaljevala delovanje v programskem toku. Tako glavna operacijska logika ni blokirana z vhodno/izhodnimi dogodki [17].. 10.

(24) Slika 2.6: Princip delovanja strežnika implementiranega z ogrodjem Node.js [17]. Kot smo že omenili ob pravilni implementaciji ogrodja Node.js, omogoča izredno hitro in učinkovito rabo sistemskih virov. To pomeni, da lahko spletna rešitev zgrajena z omenjenim ogrodjem streže več odjemalcem z manjšo porabo strežniških virov v primerjavi z uporabo drugih strežniških tehnologij. To je eden izmed glavnih razlogov za rast priljubljenosti ogrodja, saj lahko uporaba ogrodja znatno zniža stroške delovanja. Poraba sistemskih virov je nizka v primerjavi z uporabo drugih tehnologij, saj deluje le na eni niti, medtem ko tradicionalni spletni strežniki delujejo na več nitih [1].. Večina vodilnih spletnih strežnikov je večnitnih, vključno s strežnikom Apache in IIS. To pomeni, da dobi vsak nov odjemalec ali seja ločeno nit in možnost uporabe določene količine predpomnilnika. Ta princip delovanja lahko najlažje predstavimo na primeru (Slika 2.7). Predstavljajte si dve osebi Jureta in Mojco, ki gresta na pošto z različnim namenom. V večnitnem modelu bi vsaka oseba pristopila do svojega poštnega delavca zaposlenega na okencu, ki bi obdelal njune zahteve. Opazimo lahko, da gre Jure do poštnega delavca št. 1 in 11.

(25) Mojca do poštnega delavca št. 2. Poštna delavca med seboj nista odvisna. Poštni delavec št. 1 skrbi skozi celoten proces za Jureta, medtem ko skrbi poštni delavec št. 2 skozi celoten proces za Mojco. Tak princip delovanja deluje dobro, dokler je na pošti največ toliko strank, kot je zaposlenih poštnih delavcev za delo na okencu. Ko število strank preseže število zaposlenih, se začne proces upočasnjevati in stranke so primorane čakati, da pridejo na vrsto. Medtem ko vodilni pri pošti niso zaskrbljeni glede čakalnih vrst v njihovih poslovalnicah, ne moremo trditi, da velja isto za spletne rešitve. V večini primerov počasnega delovanja spletnih rešitev bo to uporabnika odvrnilo od ponovnega obiska. To je eden glavnih razlogov, da vsebujejo strežniki veliko več predpomnilnika, kot ga dejansko potrebujejo. Strojna oprema je v primerih strežnikov pripravljena na izredne primere velikih količin prometa. Na pošti bi to reševali tako, da bi dali delo 50 novo zaposlenim in najeli večje poslovne prostore samo zato, ker imajo v času kosila povečan obisk. Ta pristop delovanja je izredno potraten, porabo virov pa je mogoče zmanjšati z enonitnim pristopom [1].. 12.

(26) Slika 2.7: Primer večnitnega delovanja strežnika [1]. Strežnik postavljen z uporabo ogrodja Node.js deluje le na eni niti. Namesto da bi vsakemu uporabniku dodelil svojo nit in določil ločeno porabo virov, se vsak obiskovalec poveže na isto nit. Uporabnik in nit sta v interakciji le, ko uporabnik pošilja zahtevo ali ko mu nit vrača odgovor. Vrnimo se na primer (Slika 2.8) interakcije stranke z zaposlenimi na pošti. Tokrat si predstavljajte, da je na pošti za delo s strankami zaposlena le ena oseba, ki skrbi za vse stranke. Vendar le sprejema zahteve, jih delegira drugim zaposlenim, ki zahteve obdelajo in kar se da hitro prejme novo zahtevo. V tem enonitnem pristopu Mojca in Jure oddata zahtevo istemu 13.

(27) poštnemu delavcu. Poštni delavec prejme prvo zahtevo od Mojce, jo posreduje poštnemu delavcu, ki je zadolžen za obdelavo te vrste zahtev in enako stori pri Juretu. Po končani obdelavi zahteve zadolženi poštni delavci o zaključku obvestijo delavca na okencu in vrnejo zahtevane stvari stranki. Kljub temu, da je na okencu zaposlen le en poštni delavec, med Juretom in Mojco ne prihaja do interakcije in njuni zahtevi ne vplivata ena na drugo. Uporaba tega pristopa dela na pošti omogoča zmanjšanje zaposlenih na okencu. Ta model dela je bolj učinkovit, saj lahko z manj zaposlenimi dosežemo manjše čakalne vrste, vendar to ne pomeni, da nikoli ne bo potrebno dodati več zaposlenih. Ta pristop dela je v ogrodju Node.js možen zaradi asinhrone podpore v programskem jeziku JavaScript [1].. 14.

(28) Slika 2.8: Primer enonitnega delovanja strežnika [1]. 2.3 EXPRESS. Ogrodje Express je relativno malo ogrodje zgrajeno na funkcionalnostih strežniškega ogrodja Node.js z namenom poenostavljanja API-jev in dodajanja koristnih funkcionalnosti [9]. Platforma razvijalcem omogoča kreativen razvoj strežnikov in podpira funkcionalnosti, ki pri drugih strežnikih niso izvedljive. Zaradi velike fleksibilnosti, ki jo podpira ogrodje, je velika tudi zahtevnost razvoja strežnika. Zaradi omenjenih razlogov je nastalo ogrodje Express, ki poenostavlja zahteven postopek vzpostavitve strežnika [1]. Express je ogrodje, kar pomeni, da 15.

(29) je pri razvoju spletnih rešitev potrebno slediti določenim principom razvoja. Vendar principi razvoja pri ogrodju Express nimajo toge strukture, kar pomeni, da imajo razvijalci veliko različnih načinov implementacije istega primera funkcionalnosti poslovne logike. Zelo redko prihaja do razvoja celotne spletne rešitve zgolj z uporabo ogrodja Express, saj ogrodje samo ne podpira razvoja vseh funkcionalnosti, ki bi si jih želeli ali pa je razvoj preveč kompleksen. Zato lahko razvijalci posežejo po najrazličnejših drugih knjižnicah ali ogrodjih, ki jih integrirajo v svoje Express spletne rešitve. Minimalističen pristop razvoja, ki ga zasledimo pri ogrodju Express, kot že prej omenjeno, omogoča fleksibilen razvoj. A v primerjavi z drugimi ogrodji za razvijalca stori izredno malo saj ga zaradi fleksibilnosti, ki jo omogoča skozi razvoj, ne vodi dovolj. Iz tega sledi, da lahko pri razvijanju Express spletni rešitev razvijalec hitro stori napako, saj mora sprejeti veliko več odločitev za postavitev arhitekture [9].. Pri poglavju Node.js smo pokazali, da ogrodje podpira le eno funkcijo upravitelja zahtev. Zahteva prispe v funkcijo in nato se iz funkcije vrne odgovor [9]. V ogrodju Express je podprta vmesna programska oprema in možnost implementacije vmesnih funkcij, ki podpirajo obravnavo zahtev. Zahteva prispe v vmesno funkcijo skupaj z odgovorom strežnika in povratno funkcijo za prehod. Ideja je precej preprosta, namesto ene monolitne funkcije lahko kličemo več funkcij upravljalca zahtev, ki vsaka obravnava manjši del področja. Te manjše funkcije upravljalca zahtev se imenujejo vmesne funkcije [26]. Ogrodje podpira tudi implementacijo usmerjanja uporabnikov. Tako kot vmesna programska oprema tudi usmerjanje uporabnikov razbije monolitno funkcijo upravljalca zahtev na več delov [9]. Funkcije za usmerjanje uporabnikov se prožijo, ko poskuša uporabnik z izbrano HTTP metodo dostopati do specifičnega URL naslova, ki je definirana v funkciji upravljalca zahtev za usmerjanje [21].. Ogrodje objektom HTTP iz ogrodja Node.js doda koristne funkcionalnosti in olajša prikazovanje dinamičnih HTML pogledov. To najlažje prikažemo na primeru (Slika 2.9). Pri razvoju spletnerešitvez uporabo ogrodja Node.js se klientova zahteva posreduje Node.js HTTP 16.

(30) strežniku, ki nato od upravitelja zahtev, ki smo ga razvijalec implementira za izvedbo določene funkcionalnostipridobi podatke, ki se kot odgovor vrnejo strežniku, ki jih nato prikaže klientu [9].. Slika 2.9: Tok prejete zahteve skozi spletno rešitev zgrajeno z ogrodjem Node.js [9]. Opazimo lahko, da ogrodje Express strežniku Node.js dodaja številne uporabne HTTP funkcionalnosti in odvzema za implementacijo časovno potratne komponente. Na primer za implementacijo pošiljanja fotografije v JPEG (Joint Photographic Experts Group) formatu bi z uporabo ogrodja Node.js potrebovali nekaj deset vrstic programske kode. Z uporabo ogrodja Express lahko ti implementiramo v zgolj eni vrstici. Namesto uporabe zgolj enega glavnega upravitelja zahtev je ogrodje Express usmerjeno v razbitje glavnega upravitelja na več manjših. Naštete prednosti lahko najlažje pokažemo na primeru (Slika 2.10). Klientova zahteva se posreduje HTTP strežniku ogrodja Node.js, ki jo nato posreduje naprej do implementacije poslovne logike ogrodja Express. Ogrodje Express obogati zahtevo in odgovor ter preko funkcij, ki omogočajo povezovanje in jih razvijalec implementira sam, posreduje odgovor HTTP strežniku ogrodja Node.js in strežnik vrne odgovor klientu [9].. 17.

(31) Slika 2.10: Tok prejete zahteve skozi spletno rešitev zgrajeno z ogrodjem Express [9]. 2.4 ANGULARJS. Črka A v skupku ogrodij MEAN predstavlja MVC (Model View Controller) ogrodje AngularJS, ki je razvito na osnovi programskega jezika JavaScript. Za razvoj ogrodja je odgovorno podjetje Google. Za izgradnjo funkcionalne podatkovno vodene spletne rešitve zadostuje zgolj uporaba ogrodij Node.js, Express in MongoDB. Ogrodje AngularJS pa razvijalcem omogoča prestavitev razvoja logike iz strežniške strani na stran odjemalca, kar izboljša uporabniško izkušnjo in pospeši razvoj pogleda spletnih rešitev [1]. Z drugimi besedami, pri tradicionalnem razvoju spletnih rešitev se procesiranje podatkov in aplikacijska logika izvajajo na strežniku. Pri razvoju spletnih rešitev z uporabo ogrodja AngularJS pa se ti procesi prenesejo na stran klienta in strežnik skrbi le še za prenos podatkov iz podatkovne baze. Razvoj spletnih rešitev z ogrodjem podpira elemente programskega jezika HTML, ki jih lahko oblikujemo z uporabo programskega jezika CSS, kar pomeni, da je logika ločena in lahko spremenimo celotno postavitev in oblikovanje spletne rešitve brez spreminjanja programske kode spisane v ogrodju AngularJS [22]. Osnovni koncept ogrodja AngularJS je predstavljen z MVC ali MVVM (Model View View Model) arhitekturnim modelom. Nepotrebna kompleksnost razvoja vodi do spletnih rešitev, ki vsebujejo napake in so drage za vzdrževanje. Do nepotrebnega zapletanja prihaja pri implementaciji odvisnosti v vseh delih rešitve. V nasprotju s tem načinom razvoja pa odstranjevanje nepotrebnih odvisnosti vodi do dobro spisane programske kode, ki vsebuje manj napak in jo je lažje vzdrževati zaradi ponovne uporabnosti komponent brez spreminjanja 18.

(32) celotne rešitve. Ta princip razvoja lahko zasledimo v MVC arhitekturnem modelu [7]. Ta arhitekturni model je bil kreiran kot način za ločitev različnih enot pri razvoju spletnih rešitev. Razvijalcem daje izhodišče pri odločanju, kako razdeliti razvoj posameznih elementov. MVC arhitekturni model razdeli vsako spletno rešitev na tri ločene modularne dele [22]: -. Model predstavlja gonilno silo spletnih rešitev ali z drugimi besedami podatke shranjene v podatkovni bazi na spletnem strežniku [22]. Model je neodvisen od kontrolerja in pogleda [7]. Pri večini grafičnih vmesnikov, ki uporabnikom prikazujejo podatke, so ti podatki pridobljeni iz modela ali podskupine modela.. -. Pogled predstavlja uporabniški vmesnik, ki se generira glede na model. Omogoča interakcijo med uporabniki in spletno rešitvijo [22].. -. Kontroler je odvisen od pogleda in modela [7]. Predstavlja poslovno logiko in predstavitveno plast spletnih rešitev. Skrbi za izvedbo akcij in sprejema odločitve, kako in katere dele modela naj prikaže. Odgovoren je za osnovno odločanje prikazovanja pravilnih delov modela v pogledu [22]. Njegov namen je iz modela odstraniti nepotrebne odvisnosti, kar omogoči boljši pregled in lažje vzdrževanje modela [7].. V vsakem od naštetih elementov arhitekturnega modela MVC se razvija ločen del spletne rešitve, kar ponuja naslednje prednosti [22]: -. Vsaka enota skrbi zgolj za določeno področje razvoja. Model predstavljajo podatki, pogled predstavlja uporabniški vmesnik in kontroler predstavlja poslovno logiko. Zaradi dobro določenih mej razvoja posameznih enot je pri razvoju rešitev v ekipah ali pri dopolnjevanju preprosto ugotoviti, kam umestiti nove funkcionalnosti [22].. -. Za vsako enoto se podpira neodvisnost od drugih enot. Medsebojna neodvisnost prinaša možnost modularnega razvoja, večkratno uporabo in preprosto vzdrževanje funkcionalnosti [22].. 19.

(33) Za čim boljše razumevanje dvosmerne vezave podatkov si bomo najprej ogledali delovanje enosmerne vezave (Slika 2.11), ki predstavlja bolj tradicionalen način vezave podatkov. Enosmerno vezavo lahko zasledimo pri ogrodjih Node.js, Express in MongoDB. Z ogrodjem Node.js poskrbimo za pridobivanje podatkov iz podatkovne baze MongoDB, ki jih nato s pomočjo ogrodja Express pretvorimo v programski jezik HTML in posredujemo strežniku (Slika 2.7). Enosmerni model vezave podatkov je osnova za podatkovno vodene spletne rešitve. V tem modelu se večina procesiranja izvede na strežniku, brskalnik skrbi le za prikazovanje HTML elementov in zagotavljanje interaktivnosti z uporabo programskega jezika JavaScript [1].. Slika 2.11: Primer enosmerne vezave podatkov [1]. Pri dvosmerni vezavi podatkov (Slika 2.12) se predloga spletne strani in podatki v brskalnik pošljejo neodvisno. Brskalnik iz predloge sam sestavi pogled in vstavi podatke iz modela. Prednost, ki jo prinaša dvosmerna vezava, je ta, da pogled zaživi. Zaradi dvosmerne povezave med modelom in pogledom se pri spremembi modela spremeni tudi pogled in obratno (Slika 2.8) [1]. 20.

(34) Slika 2.12: Primer dvosmerne vezave podatkov [1]. 21.

(35) 3 NAČRTOVANJE IN RAZVOJ SPLETNE REŠITVE NA OSNOVI OGRODJA MEAN.JS. 3.1 NAČRT. Za prikaz razvoja in delovanja spletnih rešitev z uporabo skupka ogrodij MEAN.JS bomo razvili spletno rešitev, ki ponazarja telefonski imenik (Slika 3.1). Uporabniki lahko na spletnem imeniku dodajajo in odstranjujejo osebe. Za vsako osebo lahko vnesejo ime, priimek in njegovo telefonsko številko.. Slika 3.1: Diagram primera uporabe spletne rešitve Imenik. Spletni imenik nudi poenostavljeno predstavitev posameznih elementov, ki so zgrajeni z uporabo ogrodij iz skupka MEAN.JS in omogoča vpogled v njihovo medsebojno odvisnost, ki 22.

(36) tvori celoto. Razvoj spletne rešitve si bomo olajšali z vključevanjem paketov, ki si jih bomo pred samim pričetkom razvoja tudi ogledali. Spletni strežnik bomo razvili z uporabo ogrodja Express, ki temelji na ogrodju Node. Pri snovanju relacijske podatkovne baze MongoDB si bomo delo olajšali s knjižnico za objektno-relacijsko mapiranje Mongoose. Knjižnica podpira izgradnjo podatkovnega modela na osnovi sheme in vključuje funkcionalnosti za pretvorbo podatkovnih tipov, validacijo, implementacijo povpraševanj in implementacijo poslovne logike. Namen knjižnice je doseči isti rezultat z manj vrstic programske kode kot pri snovanju podatkovne baze MongoDB z uporabo vgrajenega gonilnika. Z uporabo ogrodja Express bomo razvili več REST programskih vmesnikov, ki nam bodo omogočili interakcijo med podatkovno bazo in pogledom, ki ga bomo razvili z uporabo ogrodja Angular. Med samim razvojem si bomo za preverjanje razvitih vmesnikov naložili Google Chrome vtičnik Postman. Zaradi različnih domen pogleda in implementiranih vmesnikov bomo v razvoj spletne rešitve vključili varnostni mehanizem CORS (Cross-origin resource sharing). Mehanizem omogoča spletni rešitvi dostop do virov rešitev z drugačnimi domenami. V razvoj rešitve bomo vključili tudi vmesnik bodyparser, ki nam omogoča prenos informacij v telesu HTTP zahtev.. 3.2 IZGRADNJA SPLETNE REŠITVE. Z razvojem spletnega imenika bomo začeli z izborom primernega prostora na disku, kjer si želimo projekt kreirati. V našem primeru se ta prostor nahaja na C:\Users\lovro. Za izvedbo projekta potrebujemo prazno mapo, ki bo vsebovala vse datoteke, ki se navezujejo na spletno rešitev. Zato odprimo ukazno vrstico, se pomaknimo do željenega prostora in kreirajmo novo mapo z nazivom imenik.. 23.

(37) Slika 3.2: Kreiranje nove mape v ukazni vrstici. Z ukazom cd v ukazni vrstici se pomaknimo v mapo imenik in izvedimo ukaz npm init, ki bo od nas zahteval vnos osnovnih informacij o projektu. Po potrditvi vnesenih informacij se bo vzpostavil dokument package.json, v katerem bodo navedene vnesene infromacije skupaj z vsemi odvisnostmi projekta, ki jih bomo dodali v nadaljnjem razvoju. Z drugimi besedami vse odvisnosti, ki jih vključimo med samim razvojem, je potrebno navesti v dokumentu package.json. Za izvedbo projekta bomo vključili Node pakete Express, Mongoose, CORS in body-parser. Po namestitvi paketov lahko v datoteki package.json (Slika 3.3) preverimo, ali so bile nove odvisnosti uspešno dodane.. Slika 3.3: Odvisnosti, ki smo jih dodali v dokumentu package.json. Za primarno datoteko smo ob kreiranju datoteke package.json navedli naziv app. S tem smo določili datoteko, ki predstavlja glavni vhod v naš projekt. Torej bomo s samim razvojem strežnika začeli v datoteki app.js. Prvi korak razvoja strežnika predstavlja vključitev potrebnih modulov. V našem primeru bomo vključili module Express, Mongoose, body-parser, CORS in Path. Razvoj strežnika bomo nadaljevali s klicem funkcije express(), ki nam vrne instanco aplikacije Express in jo dodeli spremenljivki, ki nam bo služila kot osnova za izgradnjo naše 24.

(38) spletne rešitve. Aplikaciji Express, ki smo jo kreirali, pripnemo varnostni mehanizem CORS in vmesnik body-parser, ki ga bomo uporabili v nadaljnjem razvoju. Na koncu določimo še število vrat delovanja, preko katerih bomo do same rešitve dostopali. Preden pričnemo s samo implementacijo obdelave HTTP zahtev, si pripravimo podatkovno bazo. V ta namen bomo v projektu kreirali novo podmapo z nazivom models, ki bo vsebovala datoteko kontakti.js (Slika 3.4). V datoteki kontakti.js vključimo knjižnico Mongoose, ki nam bo olajšala pripravo sheme za željen dokument. V našem primeru v shemi definiramo tri spremenljivke; ime, priimek in telefonska, ter jim določimo tip in obveznost uporabe pri kreiranju novega vnosa. Implementirano shemo izvozimo za uporabo v drugih datotekah.. Slika 3.4: Podatkovna shema implementirana v datoteki kontakti.js. 25.

(39) Po uspešni implementaciji podatkovne sheme se vrnimo v datoteko app.js in izvedimo še samo povezavo na podatkovno bazo. Zaključili smo z razvojem strežnika (Slika 3.5) in podatkovne baze in s tem pripravili vse potrebno za implementacijo obdelave HTTP zahtev.. Slika 3.5: Implementiran strežnik. Zaradi boljše preglednosti obdelave HTTP zahtev implementiramo v ločenih datotekah in vključimo v datoteki app.js. V ta namen v projektu kreirajmo podmapo z nazivom routes in v tej mapi datoteko route.js, ki bo vsebovala implementacijo obdelave HTTP zahtev. Sam razvoj obdelave zahtev bomo začeli z vključitvijo ogrodja Express, podatkovnega modela, ki smo ga pripravili v datoteki kontakti.js in funkcije express.router(). Z uporabo funkcije express.router() implementirajmo vse zahteve, ki jih bomo obravnavali glede na izbrano pot in HTTP metodo REST (Representational State Transfer) storitev. Za prikaz kontaktov (Slika 3.6) določimo pot. 26.

(40) /kontakti, kjer se v primeru zahteve GET iz podatkovne baze vrnejo objekti iz dokumenta Kontakt v JSON formatu.. Slika 3.6: Implementirana obravnava HTTP zahteve GET na poti /kontakti. Ob klicu zahteve (Slika 3.7) POST na poti /kontakt si ustvarimo nov objekt Kontakt s pomočjo pridobljenih podatkov iz HTTP telesa, kar nam omogoči vmesnik body-parser. Novo kreiran objekt shranimo v podatkovno bazo.. Slika 3.7: Implementirana obravnava HTTP zahteve POST na poti /kontakt 27.

(41) Za izbris kontakta na poti /kontakt/:id se ob klicu zahteve (Slika 3.8) DELETE preveri id na poti, do katere uporabnik dostopa in nato na izbran id izbrišemo celotnega uporabnika.. Slika 3.8: Implementirana obravnava HTTP zahteve DELETE na poti /kontakt/:id. Delovanje posameznih obdelav zahtev lahko preverimo s storitvijo Postman (Slika 3.9), ki podpira izvedbo HTTP zahtev z možnostjo kreiranja telesa. Po končani implementaciji obravnave dostopa različnih poti glede na izbrane HTTP metode celoten dokument izvozimo za nadaljnjo uporabo in se vrnimo v dokument app.js, kjer jih bomo vključili v aplikacijo. Implementirane poti vključimo v aplikacijo za podano potjo /api, tako da bodo vse implementirane poti nastopile za potjo /api.. Slika 3.9: Primer uporabe storitve Postman za preverjanje delovanja kreiranja novega kontakta 28.

(42) Pripravili smo si vse potrebne funkcionalnosti na strežniški strani razvoja, tako da lahko preidemo na razvoj pogleda. Začeli bomo z namestitvijo vmesnika za ukazno vrstico ogrodja Angular 2 (Slika 3.10). Po zaključeni namestitvi bomo v projektu imenik kreirali nov Angular 2 projekt z ukazom new ng client.. Slika 3.10: Namestitev vmesnika za ukazno vrstico. S pomočjo vmesnika za ukazno vrstico namestimo datoteke, v katerih bomo implementirali storitev in komponento, spletne rešitve, imenik. Razvoj pogleda začnimo z implementacijo datoteke kontakt.service.ts, kjer bomo razvili metode za vključevanje v razvoj komponente. Razvoj storitve KontaktService bomo začeli z vključitvijo za razvoj potrebnih modulov. Za podporo injekcije odvisnosti vključimo modul Injectable, ki podpira uporabo označbe @Injectables nad implementiranim razredom, zaradi česar lahko izvedemo injekcijo razreda v drugih komponentah. Vključimo tudi modul Http, ki predstavlja razred, v katerem so na voljo metode za izvajanje HTTP zahtev in modul Headers, ki nudi možnost vključevanja dodatnih informacij ob klicu HTTP metod. Vključimo še modul Rxjs, katerega metode bomo uporabljali za pretvorbo podatkov v format JSON. Za uspešen razvoj je potrebno modula HttpModule in FormsModule vključiti tudi v dokumentu app.module.ts. Po končanih vključitvah modulov, ki so potrebni za razvoj, implementiramo metode (Slika 3.11), ki skrbijo za interakcijo med pogledom in razvito logiko spletne rešitve na strežniški strani. Z drugimi besedami, implementirali bomo metode, ki so v interakciji s programskimi vmesniki na strežniški strani razvoja, ki so v interakciji s podatkovno bazo.. 29.

(43) Slika 3.11: Implementirane metode, ki skrbijo za interakcijo med pogledom in razvito logiko spletne rešitve na strežniški strani. Po končani implementaciji storitev pričnimo z razvojem komponente v dokumentu kontakti.component.ts. Začeli bomo z vključitvijo modulov, ki jih potrebujemo za razvoj. Vključimo modul Component, ki podpira uporabo označbe @Component, s katero nakažemo, da implementiran razred predstavlja Angular 2 komponento in telesu označbe zapišemo dodatne metapodatke. Vključimo tudi modul OnInit, ki omogoči implementacijo vmesnika OnInit in posledično vključitev metode ngOnInit(), ki se izvede on prvem zagonu komponente v brskalniku. Vključimo tudi storitev KontaktService za uporabo implementiranih metod, ki so v interakciji s strežniško logiko in za delo s kontakti vključimo razred Kontakt (Slika 3.12).. Slika 3.12: Razred Kontakt. 30.

(44) Razvoj komponente pričnemo z označbo @Component in v njenem telesu opišemo glavne odvisnosti in značilnosti komponente. Pripravimo spremenljivke, ki jih bomo potrebovali za delo s kontakti v imeniku in v konstruktorju (Slika 3.13), dodamo injekcijo storitve KontaktService.. Slika 3.13: Injekcija storitve KontaktService v konstruktorju. Začnemo z razvojem metod, na katere bo vplivala uporabnikova interakcija. Kreiramo metodo (Slika 3.14), ki iz obrazca pridobi podatke o vnesenem kontaktu in kreira JSON objekt. JSON objekt s podatki kontakta z uporabo metode dodajKontakt(novKontakt) iz storitve KontaktService posreduje do programskega vmesnika implementiranega na strežniški strani razvoja spletne rešitve, ki ga shrani v podatkovno bazo. Za uspešno izvedenim vnosom v podatkovno bazo dodamo novo vnesen kontakt tudi v polje kontaktov, ki ga uporabimo za osvežitev seznama prikazanih kontaktov z uporabo metode pridobiKontakte() iz storitve KontaktService.. 31.

(45) Slika 3.14: Implementacija metode za dodajanje novih kontaktov. Implementiramo tudi metodo za izbris kontakta (Slika 3.15), ki prejme parameter id kontakta. Za začetek pridobimo celotno polje vnesenih kontaktov in z uporabo metode odstraniKontakt() implementirane v storitvi KontaktService glede na podan id odstranimo kontakt. Po uspešnem izbrisu kontakta kontakt odstranimo tudi iz pridobljenega polja z uporabo metode splice().. Slika 3.15: Implementacija metode za izbris kontakta 32.

(46) V telesu podane metode ngOnInit(), ki se izvede, ko se komponenta naloži v brskalnik, implementiramo metodo pridobiKontakte() iz storitve KontaktService, ki pridobi seznam podatkov iz podatkovne baze s pomočjo klica implementiranega programskega vmesnika na strežniški strani spletne rešitve.. Slika 3.16: Implementacija metode, ki izvede ob zagonu komponente v brskalniku. Potrebno je implementirati še videz spletne rešitve v dokumentu kontakti.component.html, ki bo skrbel za interakcijo z uporabnikom. Videz bo vseboval obrazec (Slika 3.17) za vnos potrebnih podatkov o kontaktu, seznam za prikaz kontaktov in gumb za izbris posameznega kontakta. Začnimo z razvojem obrazca za vnos novega kontakta. Kreirajmo tri vnosna polja za ime, priimek in telefonsko številko ter gumb za potrditev vnosa podatkov, ki mu dodamo referenco na metodo addKontakt() implementirano v komponenti Kontakti. Prenos podatkov podpremo z označbo ngModel, ki ji določimo ime spremenljivke pri prenosu.. 33.

(47) Slika 3.17: Obrazec za dodajanje novih kontaktov. Podatke prikažemo z uporabo zanke (Slika 3.18), ki za vsak kontakt prikaže ime, priimek in telefonsko številko. Ob prikazu posameznega kontakta prikažemo še gumb za izbris kontakta, ki mu dodamo referenco na metodo deleteKontakt(id) iz komponente Kontakti.. Slika 3.18: Implementacija prikaza seznama kontaktov. Za boljšo grafično podobo v dokumentu index.html vključimo odprto kodno ogrodje zasnovano na osnovi jezikov HTML, CSS in Javascript, ki podpira hiter in poenostavljen razvoj videza 34.

(48) spletnih. rešitev.. Nekatere. HTML. elemente. preuredimo. sami. v. dokumentu. kontakti.component.css in ga tudi vključimo v dokument index.html. Modul je potrebno le še vključiti za prikaz, kar storimo v dokumentu app.component.html in tako smo gotovi z razvojem spletnega imenika (Slika 3.19).. Slika 3.19: Končni izgled spletne rešitve Imenik. 35.

(49) 4 TESTIRANJE IN ANALIZA. V namen prikaza zmogljivosti spletnih rešitev zgrajenih s skupkom ogrodij MEAN.JS bomo izvedli dve vrsti testov. Spletno rešitev bomo obremenili z večjim številom in ustvarili več variacij testov, ki se bodo razlikovali po številu zahtev, ki jih je potrebno izvesti, in številu zahtev, ki se izvedejo sočasno. Ustvarili bomo tudi teste, kjer bomo merili čas, ki je potreben za prikaz uporabnikov na seznamu imenika. Testiranje bomo izvedli lokalno na osebnem računalniku (Tabela 4.1).. Tabela 4.1: Sistemske lastnosti računalnika Procesor. Predpomnilnik. Pomnilnik. Intel i3 1.80GHz. 4GB. SSD 100GB. 4.1 ORODJA ZA IZVEDBO TESTIRANJA. Za izvedbo testov bomo uporabili orodje za testiranje HTTP strežnikov Loadtest in v brskalnik Google Chrome vgrajenim orodjem za merjenje zmogljivosti elementov implementiranih s programskim jezikom JavaScript. Loadtest je odprto kodno orodje, ki nudi vpogled v delovanje strežnika. Uporabnik z njim upravlja v ukazni vrstici. Spoznali se bomo s tremi pojmi, ki so tesno povezani z uporabo orodja Loadtest [19]: -. HTTP zahteve: posamezne HTTP zahteve se izvedejo v milisekundah. Princip delovanja pa najlažje razložimo na primeru. Predstavljajte si posamezno stran spletne rešitve, ki je sestavljena iz petnajstih elementov (slik, HTML datotek, CSS datotek, JavaScript 36.

(50) datotek, itd.), potem spletni brskalnik za prikaz enemu odjemalcu izvede petnajst zahtev. Pomembno je razumeti tudi, da se vse zahteve ne izvedejo sočasno. V našem primeru se najprej izvede zahteva za HTML datoteko, za to zahtevo se v brskalniku paralelno izvede šest zahtev in za tem preostale zahteve, ki se izvajajo posamezno [19]. Število zahtev, ki se lahko izvede paralelno, se razlikuje med brskalniki (Tabela 4.2).. Tabela 4.2: Zmožnost paralelnega izvajanja povezav [15]. Število paralelno. Brskalnik. Brskalnik. Brskalnik Internet. Chrome 34. Firefox 27. Explorer 11. 6. 6. 13. 10. 17. 17. izvedenih povezav za enega gostitelja Maksimalno število paralelno izvedenih povezav. -. Odzivni čas je čas vrnjen v milisekundah, ki nam pove, koliko časa potrebuje spletni strežnik za odgovor.. -. Sočasne povezave predstavljajo število povezav, ki se lahko izvedejo v enem intervalu.. Za testiranje bomo uporabili tudi v brskalnik Google Chrome vgrajeno orodje za analiziranje zmogljivosti spletnih rešitev. Z uporabo orodja lahko posnamemo na spletni rešitvi izvedene akcije in po zaključenem snemanju analiziramo zmogljivost prikaza JavaScript elementov.. 37.

(51) 4.2 POSTOPEK IZVEDBE TESTIRANJA IN ANALIZA PRIDOBLJENIH METRIK. Testiranje spletne rešitve bomo začeli z v brskalnik Google Chrome vgrajenim orodjem za analiziranje zmogljivosti spletnih rešitev (Slika 4.1). Do orodja v brskalniku dostopamo tako, da na spletni rešitvi izvedemo desni klik in v menijski vrstici, ki se nam prikaže, izberemo Inspect. Odpre se nam novo okence, v katerem izberemo zavihek Performance in začnemo s snemanjem aktivnosti s pritiskom na črn krogec v zgornjem levem kotu. Za prekinitev snemanja in prikaz pridobljenih metrik ponovno pritisnemo na krogec, ki je v času snemanja obarvan rdeče.. Slika 4.1: V brskalnik Google Chrome vgrajeno orodje za analiziranje zmogljivosti spletnih rešitev. 38.

(52) S pomočjo orodja bomo na spletni rešitvi analizirali čas, ki je potreben za prikaz enega, desetih, stotih in tisočih elementov. To bomo storili z implementacijo zanke, ki bo v namen testiranja skrbela za dodajanje večjega števila novih oseb (Slika 4.2).. Slika 4.2: Dopolnjena metoda za dodajanje novih kontaktov. Za realnejši vpogled v zmogljivost delovanja spletne rešitve bomo za prikaz elementov vsak test izvedli petkrat in za analizo uporabili povprečen čas, ki je potreben za prikaz (Tabela 4.3).. Tabela 4.3: Metrike pridobljene z merjenjem časa potrebnega za prikaz elementov Število prikazanih. 1. 10. 100. 1000. 39.9. 432.7. 4443.4. 57839.0. 31.2. 468.8. 4723.3. 49204.5. 25.2. 360.6. 5879.5. 49204.5. elementov Čas v milisekundah. 39.

(53) Povprečen čas v. 33.4. 319.5. 4104.9. 47107.0. 31.8. 332.1. 4645.2. 34670.8. 32.3. 382.74. 4759.26. 47605.16. milisekundah. Drugi del testiranja bomo začeli z namestitvijo orodja Loadtest v ukazni vrstici (Slika 4.3).. Slika 4.3: Ukaz za namestitev orodja Loadtest. Za uspešni namestitvi lahko pričnemo s testiranjem. Testiranje izvedemo v ukazni vrstici (Slika 4.4) s klicem orodja in podajanjem parametrov. Parameter -n označuje število zahtev, ki jih želimo izvesti, parameter -c število zahtev, ki se lahko izvajajo sočasno in na koncu navedemo še povezavo do spletne rešitve, nad katero želimo izvesti test.. Slika 4.4: Ukaz za izvedbo testiranja. Teste izvedemo za tisoč in deset tisoč izvedenih zahtev, vendar se bo pri samih testih razlikovalo tudi število zahtev, ki se lahko izvede sočasno. Pri sami izvedbi testov bomo za različno podane parametre merili čas, ki je potreben za izvedbo, povprečen čas ene zahteve in odstotek zahtev, ki se izvedejo v določenem času. Začnimo z izvedbo testov za tisoč izvedenih zahtev, kjer bo število sočasno izvedenih zahtev deset, sto in tisoč (Tabela 4.4). 40.

(54) Tabela 4.4: Metrike pridobljene z merjenjem časa potrebnega za izvedbo 1000 zahtev Sočasno izvedene Čas zahteve. potreben. za Povprečen čas Odstotek. zahtev,. ki. se. izvedbo 1000 zahtev za izvedbo ene izvedejo v določenem času, podan v sekundah. zahteve podan podan v milisekundah v milisekundah. 10. 100. 1000. 0.978704383. 9.4. 1.3387952680000001 124.1. 2.857137644. 1707.2. 50%. 7. 90%. 14. 95%. 21. 99%. 96. 100%. 109. 50%. 94. 90%. 242. 95%. 279. 99%. 350. 100%. 362. 50%. 1701. 90%. 2100. 95%. 2168. 99%. 2254. 100%. 2325. 41.

(55) Izvedbo testov nadaljujemo za deset tisoč izvedenih zahtev, kjer bo število sočasno izvedenih zahtev sto, tisoč in deset tisoč (Tabela 4.5).. Tabela 4.5: Metrike pridobljene z merjenjem časa potrebnega za izvedbo 1000 zahtev Sočasno izvedene Čas zahteve. potreben za Povprečen čas Odstotek. zahtev,. ki. se. izvedbo 10000 zahtev za izvedbo ene izvedejo v določenem času, podan v sekundah. zahteve podan podan v milisekundah v milisekundah. 100. 1000. 10000. 11.409532824. 112.9. 13.533901422000001 894.8. 18.024880904. 9922.8. 50%. 103. 90%. 147. 95%. 204. 99%. 289. 100%. 398. 50%. 769. 90%. 1478. 95%. 1751. 99%. 2148. 100%. 2887. 50%. 10721. 90%. 13833. 95%. 13920. 42.

(56) 99%. 14997. 100%. 15011. 4.3 ANALIZA PRIDOBLJENIH METRIK. Iz standardov, ki jih je v svoji študiji predstavil Geoff Kenyon, je razvidno, med kolikšen odstotek spletnih rešitev objavljenih na spletu se uvrsti razvita spletna rešitev glede na čas, ki je potreben za prikaz. V primerih, ko potrebuje spletna rešitev za prikaz 5 sekund, se uvrsti med 75% najhitrejših, v primerih, ko potrebuje za prikaz 2.9 sekunde, se uvrsti med 50% najhitrejših, v primerih, ko potrebuje za prikaz 1.7 sekunde, se uvrsti v 25% najhitrejših in v primerih, ko potrebuje za prikaz 0.8 sekunde, se uvrsti med 6 % najhitreje delujočih spletnih rešitev [2]. V anketi, ki jo je objavila organizacija Akamai, so uporabniki svetovnega spleta glasovali, da je za njih normalen čas potreben za nalaganje spletne rešitve 2 sekundi. V kolikor se spletna rešitev ne naloži v 3 sekundah, se jih 79% odloči spletno rešitev zapustiti [24].. Iz grafa (Graf 4.1) je razvidno, da spletna rešitev zgrajena s skupkom ogrodij MEAN.JS pri prikazu enega in desetih elementov dosega hitrosti prikaza pod 2 sekundama. Ta hitrost je glede na postavljane standarde zadostna za zagotavljanje dobre uporabniške izkušnje. Pri prikazu 100 elementov bi bilo potrebno čas prikaza elementov zmanjšati za 58%, kar lahko dosežemo z optimizacijo. Pri prikazu 1000 elementov bi bilo potrebno čas prikaza za zagotavljanje dobre uporabniške izkušnje zmanjšati za 96%. Tako znatno zmanjšanje bi z optimizacijo težko dosegli. A gledano iz drugega vidika, na svetovnem spletu težko najdemo spletno rešitev, ki zajemo stran, pri kateri je potrebno za istočasno prikazati 1000 elementov.. 43.

(57) 47605,16. Povprečen čas za prikaz enega elementa Povprečen čas za prikaz deset elementov. Povprečen čas za prikaz sto elementov. 382,74. 32,3. 4759,26. Povprečen čas za prikaz tisoč elementov. POVPREČEN ČAS POTREBEN ZA PRIKAZ ELEMENTOV PODAN V MILISEKUNDAH. Graf 4.1: Povprečen čas potreben za prikaz različnih količin elementov. Ne glede na to, kako dobro poskrbimo za hiter prikaz pogleda spletne rešitve, bo njen prikaz odvisen od hitrosti spletnega strežnika. Podjetje Google v svoji dokumentaciji navaja, da je za zagotavljanje dobre uporabniške izkušnje potrebno odgovor na zahtevo prejeti v manj kot 200 milisekundah. To hitrost lahko dosežemo z optimizacijo spletnega strežnika ali z nadgradnjo strojne opreme [23]. Hitrost obdelave zahtev na spletnem strežniku je odvisna tudi od števila odjemalcev, ki do spletne rešitve dostopajo. Poglejmo si, kako se je odrezal spletni strežnik, ki smo ga implementirali. Iz grafa (Graf 4.2) lahko razberemo, da je spletni strežnik za obdelavo 1000 zahtev potreboval znatno več časa, kot je priporočilo podjetje Google. To lahko pripišemo neoptimizirani implementaciji spletnega strežnika in slabi strojni opremi, saj smo teste izvedli. 44.

(58) lokalno na prenosnem računalniku. Iz grafa lahko razberemo tudi to, da se z večjim številom. 2,857137644. zahtev, ki se izvedejo v istem intervalu, veča tudi čas potreben za obdelavo.. 10 sočasno izvedenih zahtev 100 sočasno izvedenih zahtev. 1,338795268. 0,978704383. 1000 sočasno izvedenih zahtev. ČAS POTREBEN ZA IZVEDBO 1000 ZAHTEV PODAN V SEKUNDAH. Graf 4.2: Čas potreben za izvedbo 1000 zahtev glede na število sočasno izvedenih zahtev. Tudi pri izvedbi 10000 zahtev lahko na grafu (Graf 4.3) opazimo, da se čas obdelave zahtev veča glede na število zahtev, ki se izvedejo na istem intervalu. Opazimo lahko tudi, da je kot pri izvedbi testa za 1000 zahtev čas obdelave nezadosten ne glede na število zahtev, ki se izvedejo na istem intervalu.. 45.

(59) 11,40953282. 10000 sočasno izvedenih zahtev. 13,53390142. 1000 sočasno izvedenih zahtev. 18,0248809. 100 sočasno izvedenih zahtev. ČAS POTREBEN ZA IZVEDBO 10000 ZAHTEV PODAN V SEKUNDAH. Graf 4.3: Čas potreben za izvedbo 1000 zahtev glede na število sočasno izvedenih zahtev. Pri izvedbi testov smo pridobili tudi podatke o času izvedbe posameznih obdelav zahtev in jih uvrstili v razrede. Iz grafa (Graf 4.4) lahko razberemo, da se pri 1000 obdelanih zahtevah čas obdelave stopnjuje skupaj s številom obdelanih zahtev na istem intervalu. V primeru desetih zahtev, ki se obdelajo na istem intervalu, je povprečen čas obdelave ene zahteve 9.4 milisekunde, v primeru obdelave stotih zahtev na istem intervalu znaša povprečen čas 124.1 milisekunde in v primeru, da se vse zahteve obdelajo naenkrat, znaša povprečen čas obdelave zahteve 1707.2 milisekunde. Opazimo lahko, da je pri intervalih, kjer se obdela 10 in 100, čas obdelave zadostuje smernicam podanim s strani podjetja Google. Vendar moramo biti pozorni na to, da se pri razvoju spletnih rešitev stremi k čim večjemu obisku in bo posledično strežnik v veliki meri obremenjen z več kot le eno obdelavo zahteve.. 46.

(60) Povprečna vrednost. 100%. 1701. 1707.2. 362. 350. 279. 242 94. 109. 96. 21. 14. 7. 10 SOČASNO IZVEDENIH ZAHTEV. 9.4. 2325. 99%. 2254. 95%. 2168. 90%. 2100. 50%. 124.1. 100 SOČASNO IZVEDENIH ZAHTEV. 1000 SOČASNO IZVEDENIH ZAHTEV. Graf 4.4: Odstotek od 1000 obdelav zahtev, ki se izvedejo v določenem času glede na število sočasno izvedenih zahtev. Izvedba testov z obdelavo 10000 zahtev (Graf 4.5) le potrdi naše trditve, da se čas potreben za obdelavo zahtev veča s številom zahtev, ki se obdelajo na istem intervalu. Iz grafa lahko razberemo, da je povprečen čas obdelave posamezne zahteve pri 100 izvedenih zahtevah na istem intervalu 112.9 milisekund, pri 1000 izvedenih zahtevah na istem intervalu 894.8 milisekund in pri vseh zahtevah izvedenih sočasno 9922.8 milisekund.. 47.

(61) 100%. Povprečna vrednost. 10721. 15011. 99%. 14997. 95%. 13920. 90%. 13833. 50%. 2887. 894.8. 112.9 100. 2148. 1751. 1478. 769. 398. 289. 204. 147. 103. 9922.8. 1000. 10000. Graf 4.5: Odstotek od 10000 obdelav zahtev, ki se izvedejo v določenem času glede na število sočasno izvedenih zahtev. 48.

(62) 5 SKLEP Diplomsko delo nudi vpogled v razvoj, delovanje in zmogljivost spletnih rešitev zgrajenih z uporabo odprtokodnega skupka ogrodij MEAN.JS. V namen prikaza razvoja spletnih rešitev z omenjenim skupkom ogrodij smo razvili spletni imenik, ki omogoča dodajanje oseb s pripisanimi telefonskimi številkami in po potrebi tudi njihov izbris. Za prikaz zmogljivosti smo izvedli več testov in prišli do spoznanja, da lahko spletne rešitve, zgrajene z omenjenim skupkom ogrodij, zagotavljajo dobro uporabniško izkušnjo. Vendar je zmogljivost delovanja spletnega strežnika v veliki meri odvisna od strojne opreme in ne le od implementacije.. Po pregledu razvite spletne rešitve in izvedenih testih zmogljivosti smo ugotovili, da bi lahko implementirali več funkcionalnosti, kar bi bralcem diplomskega dela nudilo boljši vpogled v razvoj in delovanje spletnih rešitev razvitih z uporabo omenjenega skupka ogrodij. Nam pa bi nudilo boljše pogoje za izvedbo testov. Ugotovili smo tudi, da bi bilo dobro spletno rešitev testirati tudi na dejanskem spletnem strežniku in ne le na prenosnem računalniku, saj je zmogljivost delovanja spletnega strežnika v veliki meri odvisna od strojne opreme. Pa vendar zgrajena spletna rešitev in izvedeni testi bralcu diplomskega dela nudijo dober vpogled v spletne rešitve zgrajene z ogrodjem MEAN.JS.. 49.

(63) 6 VIRI IN LITERATURA. [1] Ali, N. MEAN Stack Beginner Tutorial. Dubaj. Dostopno na: https://www.codeproject.com/Articles/1052703/MEAN-Stack-Beginner-Tutorial [16.8.2017] [2] Bird, C. How Fast is Fast Enough? Page Load Time & Your Bottom Line. Semrush. Dostopno na: https://www.semrush.com/blog/how-fast-is-fast-enough-page-load-time-andyour-bottom-line [23.8.2017] [3] Capan, T. Hrvaška: Toptal. Why the Hell Would You Use Node.js. Dostopno na: https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js [27.7.2017] [4] Chodorow, K. MongoDB: The Definitive Guide, O'Reilly Media, 2013. [5] Chrzanowska, N. Why to Use Node.js: Pros and Cons of Choosing Node.js for Back-end Development. Poznań: Netguru. Dostopno na: https://www.netguru.co/blog/pros-cons-usenode.js-backend [27.7.2017] [6] Comparing document-oriented and relational data. Kalifornija: Couchbase. Dostopno na: https://developer.couchbase.com/documentation/server/3.x/developer/dev-guide3.0/compare-docs-vs-relational.html [23.7.2017] [7] Dalling, T. Model View Controller Explained. Melbourne. Dostopno na: http://www.tomdalling.com/blog/software-design/model-view-controller-explained [6.8.2017] [8] Full stack web developer Job Trends. Dostopno na: https://www.indeed.com/jobtrends/q-full-stack-web-developer.html [14.8.2017] [9] Hahn, M., E. Express in Action: Writing, building, and testing Node.js applications New York: Manning publications, 2016. 50.

(64) [10] Haverbeke, M. Eloquent Javascript: A Modern Introduction to Programming. No Starch Press, 2014. [11] Holmes, S. Getting MEAN with Mongo, Express, Angular, and Node. Manning publications, 2013. [12] Karpov, V. The MEAN Stack: MongoDB, ExpressJS, AngularJS and Node.js. Kalifornija. Dostopno na: https://www.mongodb.com/blog/post/the-mean-stack-mongodb-expressjsangularjs-and [8.8.2017] [13] Knupp, J. What is a Web Framework?. New York. Dostopno na: https://jeffknupp.com/blog/2014/03/03/what-is-a-web-framework [12.8.2017] [14] Lobel, L. Relational Databases vs. NoSQL Document Databases. New York. Dostopno na: https://lennilobel.wordpress.com/2015/06/01/relational-databases-vs-nosql-documentdatabases [25.7.2016] [15] Max parallel http connections in a browser?. Dostopno na: http://blog.olamisan.com/max-parallel-http-connections-in-a-browser [23.8.2017] [16] Moldovan, A. Full-stack development is alive and well. And for good reasons. Dostopno na: https://medium.freecodecamp.org/full-stack-between-reality-and-wishful-thinking43110005f2a2 [14.8.2017] [17] Olakara, R., A. Understanding the Node.js event loop. United Arab Emirates. Dostopno na: http://abdelraoof.com/blog/2015/10/28/understanding-nodejs-event-loop [25.7.2017] [18] O'grady, S. The RedMonk Programming Language Rankings. Dostopno na: http://redmonk.com/sogrady/2017/03/17/language-rankings-1-17 [14.8.2017] [19] Rovang, J. AB – APACHE BENCH, UNDERSTANDING AND GETTING TANGIBLE RESULTS. Dostopno na: http://tales.itnobody.com/2011/12/ab-apache-bench-understanding-andgetting-tangible-results.html [18.8.2017]. 51.

(65) [20] Ruluks, S. A brief history of web design for designers. San Francisco. Dostopno na: http://blog.froont.com/brief-history-of-web-design-for-designers [13.8.2017] [21] Sawyer, X. Why routes - route-based programming introduction. Dostopno na: http://advent.perldancer.org/2010/2 [1.8.2017] [22] Seshadri, S., Green, B. AngularJS: Up and Running. O'Reilly Media, 2014. [23] Sexton, P. What is server response time?. Varvy. Dostopno na: https://varvy.com/pagespeed/improve-server-response.html [21.8.2017] [24] Sherice, J. Speed Is A Killer – Why Decreasing Page Load Time Can Drastically Increase Conversions. Kissmestrics. Dostopno na: https://blog.kissmetrics.com/speed-is-a-killer [22.8.2017] [25] Simons, E. Learn to Build Modern Web Apps with MEAN. Kalifornija: Thinkster. Dostopno na: https://thinkster.io/tutorials/mean-stack [6.8.2017] [26] Sugden, S. A short guide to Connect Middleware. Dostopno na: https://stephensugden.com/middleware_guide [28.7.2017] [27] Teixeira, P. Hands-on Node.js, Leanpub, 2013. [28] Yared, P. The Rise And Fall Of The Full Stack Developer. San Francisco: Techcrunch. Dostopno na: https://techcrunch.com/2014/11/08/the-rise-and-fall-of-the-full-stackdeveloper [11.8.2017]. 52.

(66) Koroška cesta 46 2000 Maribor, Slovenija. IZJAVA O USTREZNOSTI ZAKLJUČNEGA DELA Podpisani mentor/-ica : ____________________________________________________________ (ime in priimek mentor-ja/-ice) in somentor/-ica (eden ali več, če obstajajo): ___________________________________________ (ime in priimek somentor-ja/-ice) Izjavlja-m/-va/-mo, da je študent/-ka Ime in priimek:___________________________________, ID številka: ______________________, vpisna številka:____________________________, na študijskem programu: ________________________________________________________________________________ izdelal/-a zaključno delo z naslovom: ________________________________________________________________________________ ________________________________________________________________________________ (naslov zaključnega dela v slovenskem jeziku) v skladu z odobreno temo zaključnega dela, navodili o pripravi zaključnih del in mojimi (najinimi/našimi) navodili.. Preveril/-a/-i in pregledal/-a/-i sem/sva/smo poročilo o preverjanju podobnosti vsebin z drugimi deli (priloga) in potrjujem/potrjujeva/potrjujemo, da je zaključno delo ustrezno. Datum in kraj:. Podpis mentor-ja/-ice:. Datum in kraj:. Podpis somentor-ja/-ice (če obstaja):. Priloga: - Poročilo o preverjanju podobnosti vsebin z drugimi deli. 53.

(67) IZJAVA O AVTORSTVU IN ISTOVETNOSTI TISKANE IN ELEKTRONSKE OBLIKE ZAKLJUČNEGA DELA. Ime in priimek študent‐a/‐ke: Študijski program: Naslov zaključnega dela:. Mentor: Somentor:. Podpisan‐i/‐a študent/‐ka • • •. • •. izjavljam, da je zaključno delo rezultat mojega samostojnega dela, ki sem ga izdelal/‐a ob pomoči mentor‐ja/‐ice oz. somentor‐ja/‐ice; izjavljam, da sem pridobil/‐a vsa potrebna soglasja za uporabo podatkov in avtorskih del v zaključnem delu in jih v zaključnem delu jasno in ustrezno označil/‐a; na Univerzo v Mariboru neodplačno, neizključno, prostorsko in časovno neomejeno prenašam pravico shranitve avtorskega dela v elektronski obliki, pravico reproduciranja ter pravico ponuditi zaključno delo javnosti na svetovnem spletu preko DKUM; sem seznanjen/‐a, da bodo dela deponirana/objavljena v DKUM dostopna široki javnosti pod pogoji licence Creative Commons BY‐NC‐ND, kar vključuje tudi avtomatizirano indeksiranje preko spleta in obdelavo besedil za potrebe tekstovnega in podatkovnega rudarjenja in ekstrakcije znanja iz vsebin; uporabnikom se dovoli reproduciranje brez predelave avtorskega dela, distribuiranje, dajanje v najem in priobčitev javnosti samega izvirnega avtorskega dela, in sicer pod pogojem, da navedejo avtorja in da ne gre za komercialno uporabo; dovoljujem objavo svojih osebnih podatkov, ki so navedeni v zaključnem delu in tej izjavi, skupaj z objavo zaključnega dela; izjavljam, da je tiskana oblika zaključnega dela istovetna elektronski obliki zaključnega dela, ki sem jo oddal/‐a za objavo v DKUM.. Uveljavljam permisivnejšo obliko licence Creative Commons: ________________ (navedite obliko). 54.

(68) Začasna nedostopnost: Zaključno delo zaradi zagotavljanja konkurenčne prednosti, zaščite poslovnih skrivnosti, varnosti ljudi in narave, varstva industrijske lastnine ali tajnosti podatkov naročnika: (naziv in naslov naročnika/institucije) ne sme biti javno dostopno do (datum odloga javne objave ne sme biti daljši kot 3 leta od zagovora dela). To se nanaša na tiskano in elektronsko obliko zaključnega dela.. Temporary unavailability: To ensure competition priority, protection of trade secrets, safety of people and nature, protection of industrial property or secrecy of customer's information, the thesis _________________________ (institution/company name and address) must not be accessible to the public till (delay date of thesis availability to the public must not exceed the period of 3 years after thesis defense). This applies to printed and electronic thesis forms.. Datum in kraj:. Podpis študent‐a/‐ke:. Podpis mentor‐ja/‐ice: (samo v primeru, če delo ne me biti javno dostopno). Ime in priimek ter podpis odgovorne osebe naročnika in žig:. (samo v primeru, če delo ne sme biti javno dostopno). 55.

(69) Koroška cesta 46 2000 Maribor, Slovenija. IZJAVA O OBJAVI OSEBNIH PODATKOV Ime in priimek diplomant‐a/ magistrant-/-ke: ___________________________________________ ID številka: ______________________________________________________________________ Študijski program: ________________________________________________________________ Naslov zaključnega dela: ___________________________________________________________ ________________________________________________________________________________ Mentor/‐ica: __________________________________________________ Somentor/‐ica: ________________________________________________. Podpisan-i/-a izjavljam, da dovoljujem objavo osebnih podatkov, vezanih na zaključek študija (ime, priimek, leto zaključka študija, naslov zaključnega dela) na spletnih straneh Univerze v Mariboru in v publikacijah Univerze v Mariboru.. Datum in kraj:. Podpis diploman‐ta/magistran‐ta/‐ke: ____________________________ 56.

(70)

No results found