HTKA0150 Backend-sovelluskehitys2

1 Perustietoa opintojaksosta

2 Backend-sovelluskehitys pilvialustalla

3 AWS serverless -peruskäsitteitä

4 Serverless-frameworkin asennus ja käyttö

5 REST-APIn kehittäminen

6 GraphQL-APIn kehittäminen

7 Websocket-sovelluksen kehittäminen

8 AWS Amplify

9 Serverless-mikropalvelut

10 Lopputyö

1 Perustietoa opintojaksosta

Backend-sovelluskehitys2 kuuluu JAMK:in Tietojenkäsittelyn tutkinto-ohjelman (Tiko) vapaavalintaisiin ammattiopintoihin. Opintojakson laajuus on 4 opintopistettä. Opettaja on Tommi Tuikka, tuito(at)jamk.fi. Kurssin muut perustiedot ovat kurssin Moodle-työtilassa.

2 Backend-sovelluskehitys pilvialustalla

Pilvialustat tarjoavat sovelluskehittäjille valmiita backend-palveluita, joita käyttämällä backend-sovelluskehitys ja backendin julkaisu nopeutuvat ja helpottuvat. Esim. AWS, Azure ja Google Cloud tarjoavat hostauspalvelun lisäksi mm. erilaisia tietovarastoja, API-kehityspalveluita, serverless-funktioiden kehitysalustan, autentikaatiopalveluita, tekoäly- ja koneoppimispalveluita, sekä koneoppimissovellusten kehitysalustan. Tällä kurssilla keskitytään lähinnä tavallisimpiin fullstack-sovellusten backend-palveluihin, kuten tietovarastoihin, API-kehitykseen ja serverless-funktioihin.

Serverless-sovelluskehityksestä puhutaan kun backend toteutetaan joko kokonaan tai osittain pilvipalvelualustan tarjoamina palveluina. Serverless ei tarkoita serveritöntä, sillä serveri on olemassa, mutta serverin ylläpito ja sen tarjoamat palvelut on ulkoistettu palveluntarjoajan hoidettaviksi. Serverless-ratkaisu voi olla Backend as a Service (BaaS), Database as a Service (DBaaS) tai Function as a Service (FaaS) tai niiden yhdistelmä.

Baas-palvelu on kokonaisvaltainen backend-palvelu, jossa koko backend tai suuri osa siitä saadaan valmiina palveluna. Tyypillisiä esimerkkejä ovat sovelluksen tietovaraston ja autentikaation, sekä niihin liittyvien backend-ohjelmistojen käyttö suoraan pilvipalvelusta valmiina palveluna. Esim. Firebasen palvelut ovat tyypillisiä BaaS-palveluita, sillä esim. Firestore-tietokannan käyttö ei vaadi lainkaan oman backend-koodin kehittämistä. AWS Amplify on Firebasea vastaava AWS:n BaaS-palvelu. AWS Cognito tarjoaa autentikaation BaaS-palveluna. BaaS-palveluille on tyypillistä, että sovelluksen backendin toiminta on niistä täysin riippuvainen, ja niiden käytön lopettaminen tai vaihtaminen muihin palveluihin vaatii vähintäänkin melko suurten muutosten tekemistä sovellukseen.

DBaaS-palvelusta voidaan puhua silloin, kun käytetään pelkästään pilvitietokantaa, mutta sovelluksen backend-koodi ei ole sidottu pilvialustaan. Tällöin backend-koodi on helposti siirrettävissä toiselle hostausalustalle, ja muutoksia tarvitsee tehdä vain lyhyeen koodinpätkään, joka yhdistää sovelluksen tietokantaan. MongoDBAtlas on hyvä esimerkki DBaaS-palvelusta.

FaaS-palvelut ovat mikropalveluita, jotka toteutetaan serverless-funktioilla. FaaS-palvelut ovat täysin sidottuja pilvialustaan. AWS Lambda on FaaS-palveluista vanhin ja tunnetuin, mutta nykyään lähes kaikilla serverless-palveluntarjoajilla on omat FaaS-palvelunsa. Nimestään huolimatta FaaS-palveluilla voidaan kehittää myös laajempia sovelluksia, jotka voivat muodostua jopa kymmenistä tiedostoista. Arkkitehtuurin kannalta on toki parempi, että mikropalvelut pysyvät suhteellisen pieninä ja ne on hajautettu. Huomattava osa AWS:n palveluista voidaan yhdistää lambda-funktioihin ja/tai niitä voidaan käyttää lambda-funktioiden avulla. Lambda-funktioita voidaan toteuttaa monilla eri ohjelmointikielillä, ja Javascript (Nodejs) on yksi yleisimmistä.

Serverless-funktiot soveltuvat erityisen hyvin tilanteisiin, joissa jokin tapahtuma sovelluksessa laukaisee funktion suorituksen. Esimerkiksi videon laittaminen Amazonin S3 Bucket -tietovarastoon on tapahtuma, joka voi laukaista lambda-funktion, joka tekee videosta kompressoidun version ja tallentaa sen eri paikkaan kuin alkuperäisen. Tapahtumapohjaisen mikropalvelun suorittaminen serverless-periaatteella ilman oman palvelimen ylläpitoa on edullista. Serverless-mikropalvelu on käynnissä vain sen ajan kun sitä käytetään, eli edellisessä esimerkissä niin kauan kuin kompressointi ja tallennus kesti.

Hyvin tyypillinen lambda-funktion laukaiseva tapahtuma on myös käyttäjän meneminen sovelluksen tiettyyn reittiin, eli API-endpointiin. Tällöin voidaan suorittaa esim. tietokantaan kohdistuva toimenpide, kuten tiedon haku, lisäys, poisto tai muokkaus. Eli REST-API voidaan toteuttaa lambda-funktioilla.

Serverless-funktioilla voidaan myös toteuttaa vain ne backendin toiminnot joihin funktiot soveltuvat hyvin. Sovelluksella voi olla edelleen myös perinteinen backend, jossa suoritetaan muita toimintoja.

Kuvassa on esitetty Serverless -funktioiden käytön perusperiaate:

1. Asiakas pyytää että Serverless-ajoympäristö suorittaisi funktion (joka on joko valmisfunktio tai kehittäjän itse luoma funktio)
2. Ajoympäristö tutkii onko funktio jo toiminnassa jollain serverillä vai pitääkö se hakea varastosta. Funktio on containerissa (esim. Docker) oleva mikropalvelu.
3. Jos funktio pitää hakea varastosta, se asennetaan serverille.
4. Ajoympäristö suorittaa funktion ja ottaa talteen suorituksen tuloksen.
5. Tulos palautetaan asiakkaalle.

Funktio ja sen container poistetaan serveriltä suorituksen jälkeen. Vain funktion suoritusajasta serverillä (jokainen 100ms) laskutetaan asiakasta.

3 AWS serverless -peruskäsitteitä

AWS on hyvin monipuolinen, mutta myös monimutkainen serverless-alusta. AWS:n palveluja ei yleensä käytetä root-tunnuksilla, vaan AWS IAM -palvelussa tehdään käyttäjiä joilla on rajoitetumpia oikeuksia. Sovelluskehittäjä tarvitsee ainakin IAM Admin-käyttäjän. Adminille ja muille käyttäjille sekä käyttäjäryhmille voi asettaa erilaisia käyttöoikeuksia.

AWS:n palveluita voi käyttää webbiselaimella AWS-konsolista, eli AWS:n graafisesta käyttöliittymästä, tai komentokehotteesta omalta työasemalta client-sovelluksilla. Client-sovellusten, kuten AWS CLI:n tai Serverless CLI:n käyttö edellyttää, että käyttäjälle on tehty access key ja secret key, joilla hän saa pääsyoikeudet AWS:ään omalta koneeltaan. Keyt tallennetaan oman koneen user/.aws/credentials -tiedostoon.

AWS CLI

AWS CLI on AWS:n oma client, jonka komennoilla voi omalta koneelta käsin säätää AWS:n palveluita, tarvitsematta käyttää AWS-konsolia. Esim. tällä kurssilla tutuksi tuleva DynamoDB-taulun luonti tapahtuu tällä komennolla.

-Asennusohje: Getting started with the AWS CLI

Kun olet asentanut AWS CLI:n ja ajat konsolissa komennon aws configure, niin kysytään seuraavanlaiset tiedot:

AWS Access Key ID [None]: Kirjoita tähän Access Key ID
AWS Secret Access Key [None]: Kirjoita tähän Secret Access Key
Default region name [None]: eu-north-1
Default output format [None]: json

Antamasi tedot tallennetaan tiedostoihin user/.aws/credentials ja user/.aws/config. Kun kirjaudut koneeltasi AWS-konsoliin, pääsyoikeus varmistetaan credentials-tiedoston access keyn ja secret keyn avulla

AWS OCRE -käyttäjätili

Jos käytössäsi on Jamkin AWS OCRE -käyttäjätili, siihen on valmiiksi tehty IAM Admin-käyttäjä. käyttäjälle on tehty valmiiksi access key ja secret key, ja lisäksi session token, joka on voimassa 12 tuntia kerrallaan. Nämä tiedot tallennetaan tiedostoon user/.aws/credentials. Lisäksi voit tallentaa region namen ja output formatin tiedostoon user/.aws/config. Sovelluskehitys tehdään tällä kurssilla omalla koneella, joten keyt sekä token tarvitaan, kun otetaan yhteys omalta koneelta AWS-ympäristöön.

-AWS OCRE -tilin käyttöohje

Tavallinen AWS -käyttäjätili

Jos käytössäsi on tavallinen käyttäjätili, joudut luomaan itse IAM Admin-käyttäjän, sekä access keyn ja secret keyn, jotka tallennetaan credentials- ja config-tiedostoihin, kuten edellä on esitetty.

-Creating your first IAM Admin user and group

-Create an access key for an IAM user

Serverless-kehitysympäristöt

AWS Lambda -funktioita tehdään yleisimmin Javascriptillä(Nodejs) tai Pythonilla. Lambda-funktiot voivat olla myos suurempia, useita funktioita ja moduulikirjastoja sisältäviä kokonaisuuksia. Lambda-funktioita voidaan kehittää AWS-konsolin, eli AWS:n graafisen käyttöliittymän kehitysympäristössä, tai omalla koneella sijaitsevassa kehitysympäristössä.

Omalla koneella sijaitsevan kehitysympäristön käyttö on sovelluskehittäjien keskuudessa selvästi suositumpaa. Omalla koneella tapahtuvaa AWS-sovelluskehitystä tukemaan on kehitetty sovelluskehyksiä. Niiden avulla voidaan luoda AWS:n pilveen sovelluksen tarvitsema infrastruktuuri ja palvelut, kuten esim. tietokanta, API-Gateway ja autentikaatiopalvelu. Lisäksi niiden avulla voidaan mm. julkaista omalla koneella kehitetty sovellus riippuvuuksineen AWS:n pilvialustalle, sekä testata ja debugata sovellusta.

Vanhin ja tunnetuin AWS-sovelluskehys on Serverless-framework. Muita samantapaisia ovat AWS Sam, Pulumi ja Claudia.js. Lisäksi AWS CDK ja Terraform ovat paljon käytettyjä frameworkeja AWS-infrastruktuurin rakentamiseen, mutta ne eivät tarjoa paljonkaan tukea sovelluskehitykseen. Tällä kurssilla käytetään omalla koneella sijaitsevaa kehitysympäristöä, jonka muodostavat Nodejs, VSCode ja Serverless-framework.

-Yleisimmät Serverless-sovelluskehykset
-Serverless Frameworkin ja AWS CDK:n vertailu

4 Serverless-frameworkin asennus ja käyttö

Serverless-framework on omalla koneella suoritettavan AWS-sovelluskehityksen yleisimpiä apuvälineitä. Sen tarkoituksena on, että kehittäjä voi keskittyä enemmän sovelluskehitykseen ja vähemmän AWS:n palveluiden säätämiseen. Serverless-framework on ilmainen yksittäisille käyttäjille ja yrityksille, joiden liikevaihto on alle 2 miljoonaa dollaria. Käytämme sitä tällä kurssilla, koska se on helpoin vaihtoehto aloittelevalle kehittäjälle. Serverless-frameworkin toiminta perustuu Infrastructure as Code -periaatteeseen (IaC), eli AWS-infrastruktuuri rakennetaan määrittelydokumenttien perusteella. Serverless.yml -määrittelydokumentissa määritellään myös eventit, eli sovelluksen infrastruktuurissa tapahtuvat tapahtumat, jotka laukaisevat lambda-funktioita. Esim. asiakkaan selaimelta tekemä HTTP-pyyntö API-gatewyn tiettyyn urliin, on event, joka voi laukaista lambda-funktion, joka palauttaa tietoa tietokannasta.

Serverless.yml

AWS-infrastruktuuri ja eventit määritellään YAML-muotoisessa dokumentissa nimeltään serverless.yml. Sen perusteella luodaan AWS Cloudformation-dokumentit, joiden perusteella infrastruktuuri rakennetaan AWS:n pilveen. Kun infrastruktuuri on kunnossa, voimme keskittyä varsinaiseen serverless-sovelluskehitykseen, eli eventeillä laukaistavien lambda-funktioiden kehittämiseen.

Yleisimmät AWS-palvelut joita käytetään backend-sovelluksissa ovat: API-gateway, Lambda-funktiot, Cognito ja DynamoDB. Kun luomme Serverless-frameworkilla Http-Api -projektin, siinä ovat automaattisesti mukana API-Gateway ja Lambda-funktiot. Jos tarvitsemme tietovarastoksi esim. DynamoDB:n ja autentikaatiota varten Cogniton, ne pitää lisätä serverless.yml-tiedostoon, jotta niidenkin infrastruktuuri rakennetaan. Automaattisesti mukana olevien resurssien lisäksi tarvittavat resurssit lisätään serverless.yml-tiedostoon resources-avaimen alle. Näiden resurssien muoto on sama kuin Cloudformation-tiedostossa. Serverless.yml:ään pystyy siis lisäämään kaikki samat resurssit kuin käytettäessä pelkkiä Cloudformation-tiedostoja.

Serverless CLI

Serverless CLI on Serverless-frameworkin oma client-työkalu, jolla luodaan uusi projekti omalle koneelle, julkaistaan projekti AWS:ään, logataan ja debugataan sovelluksen toimintaa ja suoritetaan muita serverless-sovelluskehitykseen liittyviä toimenpiteitä.

Serverless-frameworkin toiminta vaatii, että olet luonut AWS-konsolissa IAM-käyttäjän ja olet kirjautunut sisään IAM-käyttäjänä. Lisäksi olet luonut IAM-käyttäjälle access keyn ja secret keyn, jotka sijaitsevat omalla koneellasi user/.aws/credentials -tiedostossa.

Serverless-frameworkin asennus ja lisäohjeita:

-Asennus: npm i -g serverless

-Lisäohjeita: Setting Up Serverless Framework With AWS

Rekisteröityminen ja kirjautuminen Serverless frameworkiin

Versiosta 4 alkaen Serverless-frameworkin käyttö vaatii, että käyttäjä rekisteröityy ja kirjautuu serverless-palveluun. Kirjautuminen suoritetaan aina kun käyttäjä luo uuden projektin serverless-frameworkilla. Kirjautuminen onnistuu myös serverless login -komennolla. Kirjautuessaan käyttäjä saa käyttöönsä selaimessa toimivan Serverless Dashboard -konsolin, joka tarjoaa mm. analytiikkaa palveluiden käytöstä. Dashboard ei ole sovelluskehityksen kannalta välttämätön, mutta jos haluat käyttää sitä, se täytyy yhdistää AWS-palveluihisi luomalla sitä varten erillinen Cloudformation-stack. Tähän on opastettu ohje Dashboardissa.

Perusesimerkkejä

Seuraavassa perusesimerkki Lambda-funktioiden laukaisemisesta tapahtumien eli eventtien avulla, ja parametrien lähettämisestä Lambda-funktioille. Event, joka on HTTP-pyyntö url-osoitteeseen, laukaisee Lambda-funktion. Lambdan event-parametrista otetaan vastaan event, joka sisältää numerodataa, joka otetaan sisään funktioon. Numerot funktiossa lasketaan yhteen ja tulos palautetaan JSON-muodossa. Pyyntö tehdään sekä get- että post-metodeilla:

-aws-http-parameters -esimerkki

Tutoriaali, jossa tehdään yksinkertainen REST-API:

-Your First Serverless Framework Project

Tärkeimpiä Serverless CLI -komentoja

sls deploy -komento julkaisee sovelluksen oletuksena us-east-1 -regioniin. Voit muuttaa regionia sovelluksen serverless.yml-tiedostossa, kirjoittamalla provider-otsakkeen alle esim. region: eu-north-1.

Jos mikään tapahtuma ei laukaise funktiota, sen voi laukaista komennolla: sls invoke -f funktionnimi

Pelkän funktion voi päivittää komennolla: sls deploy function -f funktionnimi. Huomaa, että funktion nimi on se nimi, joka esiintyy serverless.yml-tiedostossa. Yksittäisiä funktioita kannattaa päivittää vain sovelluskehitysvaiheessa. Valmis sovellus pitää julkaista aina kokonaisuutena sls deploy -komennolla.

Funktion toimintaa voi logata komennolla: sls logs -f funktionnimi. Huomaa, että funktion nimi on se nimi, joka esiintyy serverless.yml -tiedostossa. Loggaminen on yksinkertaisin tapa debugata funktiota. Normaali debuggaus ei ole mahdollista, kun funktio suoritetaan pilvialustalla. Jos funktio suoritetaan lokaalisti Serverless offline -pluginin avulla, on normaali debuggaus esim. VSCodella mahdollista.

HUOM! Loggaaminen ei toimi, ellei käytössäsi ole AWS Cloudwatch -palvelua, sillä lokit tulevat sieltä. Näet lokit aina myös menemällä AWS-konsolissa lambda-funktion "sivulta" monitor-välilehdelle ja sen kautta funktion Cloudwatch-lokiin. Severless-framework vain nopeuttaa Cloudwatch-lokin lukemista tulostamalla sen suoraan komentokehotteeseen.

Jos olet unohtanut, mitkä olivat projektisi API-endpointit, joihin menemällä laukaistaan funktiot, saat ne selville antamalla projektin juuressa komennon sls info.

Serverless offline -plugin mahdollistaa projektin ajamisen ilman, että se on julkaistu AWS:ään. Komennolla sls plugin install -n serverless-offline voit asentaa projektiin offline-tuen. Huomaa, että offline-tila simuloi vain Lambda-funktioita ja API-gatewayta. Jos haluat käyttää vaikkapa DynamoDB-tietokantaa lokaalisti, pitää asentaa lisäksi serverless-dynamodb -plugin ja lokaali DynamoDB-kanta linkin takana esitetyn ohjeen mukaisesti. Lokaalia DDB:tä voit hallinnoida dynamodb-admin -client-sovelluksen avulla.

HUOM! jos teet harjoituksen vuoksi suojaamattoman REST-API:n tai muun sovelluksen jossa ei ole autentikaatiota, ja julkaiset sen AWS:ään, se kannattaa heti kokeilun jälkeen poistaa sls remove -komennolla. Huomaa, että remove-komento poistaa sovelluksen vain AWS:n pilvestä, ja sovellus jää omalle koneellesi. Voit siis milloin tahansa julkaista sen uudelleen sls deploy -komennolla.

5 REST-APIn kehittäminen

REST-API:n kehittämiseen käytämme API Gateway v2 HTTP-API -palvelua. Serverless-frameworkilla kehitetyn REST-API:n perusperiaatteet on esitetty tehtävässä 1. Kyseinen hyvin yksinkertainen REST-API on kuitenkin suojaamaton. Vähintään ne endpointit, joiden kautta pääsee muokkaamaan tietokantaa, pitää suojata autentikaatiolla.

-REST-API:n autentikaatio Cogniton avulla

DynamoDB

REST-APIn kehittäminen ja muutkin seuraavat tehtävät vaativat perustietoja DynamoDB:n toiminnasta, joten tutustumme siihen hieman tarkemmin. Vaikka DynamoDB on NoSQL-kanta, se ei ole aivan samanlainen kuin MongoDB.

-DynamoDB:n perusteet lyhyesti

Jos haluat käyttää AWS REST-API:ssa MongoDB:tä, se on mahdollista MongoDb Atlas -palvelun kautta: AWS Serverless REST-API, jossa käytetään MongoDb:tä.

AWS REST-API kaaviokuva piirretty Visual Paradigm -kaaviotyökalulla.

6 GraphQL-APIn kehittäminen

Tutustutaan ensin GraphQL:n perusteisiin yksinkertaisen esimerkin avulla. Tässä esimerkissä ei käytetä AWS:n palveluita vaan sitä ajetaan omalla koneella:

-Yksinkertainen GraphQL-esimerkki

GraphQL-palvelun voimme toteuttaa AWS:ään kahdella eri tavalla: 1) luomalla oman GraphQL-serverin ja käyttämällä API-gatewayta tai 2) AppSync-palvelun avulla. Seuraavassa esimerkissä käytetään tapaa 1) eli luodaan oma GraphQL-serveri Lambda-integraatiota tukevan Apollo-kirjaston avulla. Käytössä olevat AWS-palvelut ovat API-gateway, Lambda-funktiot ja DynamoDB.

-aws-apollo-graphql -esimerkki ilman autentikaatiota

AWS AppSync -palvelu on tarkoitettu GraphQL- ja Pub/Sub -API:en tarjoamiseen. Se on AWS:n suosittelema palvelu GraphQL-API:en kehitykseen. Palvelu sisältää GraphQL-serverin, joten sitä ei tarvitse luoda itse. Emme kuitenkaan käytä AppSyncia tehtävässä 3, sillä kaikilla kurssilaisilla ei ole välttämättä sen käyttöoikeuksia.

HUOM! JAMK:in AWS OCRE -käyttäjillä ei ole oikeuksia käyttää AWS Appsyncia, joten voit kokeilla seuraavaa esimerkkiä vain AWS:n normaalilla käyttäjätilillä.

-aws-appsync-graphql -esimerkki

7 Websocket-palveluiden kehittäminen

Websocket-palvelun voimme toteuttaa AWS:ään kahdella eri tavalla: API-gatewayn avulla tai AppSyncin avulla. Seuraavassa esimerkissä ovat käytössä API-gateway, Lambda-funktiot ja DynamoDB.

- aws-ws-apigw-simple - yksinkertainen websocket-serveri
- aws-ws-apigw-simple-sdkv3 - sama serveri sdkv3:lla tehtynä
- ang-awsws - ws-serverille tehty Angular-client
- drawclient - ws-serverille tehty JS-client, jossa piirretään canvasille

8 AWS Amplify

AWS Amplify on BaaS-palvelu, jonka avulla voidaan luoda fullstack-sovelluksia tarvitsematta itse kehittää backendiä juuri lainkaan. Se on alunperin kehitetty mobiilisovellusten tarpeisiin, mutta sen avulla voi luoda backend-palveluita myös tavallisille web-sovelluksille. Amplify muistuttaa siis varsin paljon Firebasea. Myös rajoitteet ovat samat kuin Firebasella, eli se soveltuu parhaiten pienehköjen ja yksinkertaisten sovellusten toteutukseen.

Amplify-kehityksessä ei tarvitse käyttää serverless-frameworkia tai vastaavaa välinettä, sillä Amplify rakentaa backendin tarvitseman infrastruktuurin Amplify-CLI:n komentojen perusteella. Esim. komento amplify add auth lisää sovellukseen cognito-autentikaation ja samalla rakentaa cognito-palvelun vaatiman infrastruktuurin pilveen.

Amplify tarjoaa tyypillisimmät backend-palvelut. Autentikaatio (Cognito), Data (DynamoDB REST-API), Storage (S3) ja Lambda-funktiot ovat tyypillisimpiä. Amplifyn backend-palvelut toimivat kaikkien yleisimpien frontend- ja mobiilikehityskirjastojen kanssa.

Tutustutaan Amplify-sovelluskehitykseen valmiin pienen Angular-sovelluksen avulla:

-Amplify-app - Angular-sovellus, jossa Amplify ja sen kirjautumispalvelu otettu käyttöön. Tehty vanhemmalla Amplify V1:llä.

-AWS:n Amplify-Angular -dokumentaatio

9 Serverless-mikropalvelut

AWS:n serverless-alusta ei ole varsinaisesti mikropalvelualusta, mutta sen avulla voidaan luoda sovelluksia, joiden arkkitehtuuri muistuttaa mikropalveluarkkitehtuuria. Tällöin voidaan puhua serverless-mikropalveluista, vaikka nämä mikropalvelut eivät täysin vastaa ns. "oikeita" mikropalveluita jotka tehdään yleensä docker/kubernetes-alustalle.

-Using AWS Lambda as a Microservice

10 Lopputyö

***