Modulaarisen matkapäiväkirjaverkkosovelluksen suunnittelu ja toteutus

Verkkosovellusten historia ulottuu lähes yhtä pitkälle kuin maailmanlaajuisen World Wide Web -verkonkin. Verkon alkuaikoina verkkosivujen ja niihin liittyvien avainteknologioiden kyvyt olivat vielä rajalliset, joten verkkosovellukset toteutettiin käytännössä kokonaan verkkopalvelimilla ajettavina sovelluksina tai niiden ymmärtämillä ohjelmointikielillä kirjoitettuina komentosarjoina, jotka sitten tuottivat käyttäjän syötteen pohjalta sitä vastaavia verkkosivuja. Vuosien saatossa verkkoselainten rooli sovellusalustana on kuitenkin kasvanut eritoten JavaScript-kielen kehittyessä entistä ilmaisuvoimaisemmaksi ja ominaisuuksiltaan monipuolisemmaksi. Ennen pitkää syntynsä saivatkin yhden sivun sovellukset eli selaimessa ajettavat, koko käyttöliittymän toteuttavat JavaScript-sovellukset, jotka hyödyntävät jotakin palvelimella ajettavaa rajapintaa pääasiallisesti vain tietojen hakemiseen ja tallentamiseen. Tällaista mallia noudattavassa sovelluksessa vastuut käyttöliittymän ja rajapinnan välillä ovat aidosti jakautuneet kahteen eri osaan. Tässä työssä pyrittiin selvittämään, millä tavoin ja kuinka hyvin perinteisen verkkosovelluksen vastuut voitaisiin jakaa edellä mainitulla tavalla erillisille rajapinta- ja käyttöliittymäsovelluksille, suunnittelemalla ja toteuttamalla siten jaettu matkapäiväkirjasovellus. Aluksi sovellusta lähdettiin toteuttamaan rajapinnan osalta PHP-pohjaisella Lumenilla ja käyttöliittymän osalta JavaScriptin JSX-murteeseen perustuvalla Reactilla. Kehitystyön edetessä kävi kuitenkin selväksi, että rajapinnan kehittäminen saattaisi olla nopeampaa teknologiaa vaihtamalla ja että vaihdos voisi tuoda mielenkiintoisen näkökulman sovellusjaon hyötyihin, joten Lumen-sovellus korvattiin kokonaisuudessaan uudella Django-pohjaisella Python-sovelluksella. Vaihdoksen jälkeen jatkuneen työn tuloksena syntyneet sovelluksen osat vietiin lopulta onnistuneesti tuotantoympäristöön niiden tultua riittävän kattaviksi. Työn tuloksena syntyneeseen sovellukseen oltiin kaiken kaikkiaan tyytyväisiä. Molemmat osat toimivat mainiosti erillään tarkasteltuna ja osien välinen viestintäkin toimi moitteettomasti ja suorituskykyisesti. Rajapinnan vaihtaminenkin vahvisti käsitystä osajaon hyödyllisyydestä, sillä vanhaa rajapintaa vasten kehitetty käyttöliittymä voitiin liittää heti miltei sellaisenaan uuteen rajapintaan. Jaossa havaittiin myös joitakin vähäisiä varjopuolia, jotka saattaisivat olla oleellisia lähinnä muiden kehittäjien liittyessä projektiin, mutta hyödyt jäivät silti haittoja paljon suuremmiksi.As a concept, web applications are almost as old as the World Wide Web itself. In the early days of the web, the capabilities of web pages and the associated key technologies were still rather limited, which led to web applications being largely implemented as executables running on web servers or as scripts understood and interpreted by such executables, producing static web pages based on the user's input. However, as years have passed, web browsers have taken an increasingly important role as a platform for web applications due to the growing expressive power and improving feature set of the JavaScript programming language. This has eventually led to the birth of single page applications, or browser-based JavaScript applications that implement the entirety of the application's interface and depend on a backend server only for data exchange and storage purposes. In such a programming pattern, the responsibilities of the user interface and the application programming interface have truly been split into two separate applications. In this work, a travel log application was designed and implemented in order to find out how well such a separation of responsibilities between separate backend and frontend modules would perform. The development commenced with a backend application powered by the PHP based Lumen framework and a frontend application built on the React framework, using JSX, its own dialect of JavaScript. Eventually it became apparent that abandoning the Lumen application in favour of an alternate implementation could expedite the backend development and provide an interesting viewpoint in how such a drastic change affects the decoupled application, so it was wholly replaced by a new Python application powered by the Django framework. The two prevailing applications after this change of direction were ultimately deployed successfully into a production environment once they became mature enough. The resulting application was deemed a success. Both of its constituent parts performed well when evaluated on their own, and when put together, their interaction was satisfactory and performant. The switch from Lumen to Django was also proven to work well with the separated approach, as the so far implemented user interface could be used with the new backend with few required alterations. The separation was found to not be without its minor drawbacks, which were mostly related to the ease of participating in the hypothetical scenario that a new developer would step in; however, their significance was in the end overshadowed by the advantages of this approach