Mitä kuuluu verkkoräätälin työkalupakkiin? Sofokuksen CTO Tomi Niemi selvitti, mikä on sovelluskehys ja miten sen käyttäminen helpottaa verkkopalvelujen suunnittelua ja rakentamista.

Mikä on sovelluskehys?

Sovelluskehyksen tarkoitus on tehdä uusien verkkopalvelujen toteuttamisesta nopeampaa tarjoamalla valmiita sovelluskomponentteja ja käytäntöjä toteutuksen perustaksi. Sovelluskehys (tai ohjelmistokehys) ei tavallisesti ole valmis pakettiratkaisu, jota voi asennuksen jälkeen käyttää sellaisenaan vaan toimiva verkkopalvelu rakennetaan sovelluskehyksen päälle.

Kehittäjämme, Django-guru Calle Laakkonen kertoo Django Damesin sivuilla, mikä on Django-sovelluskehys:

“Django on suosittu sovelluskehys joka helpottaa Web -sovellusten luontia.  Sovelluskehys on yhtenäinen kokoelma tiettyyn aiheeseen liittyviä koodikirjastoja.  Djangon tapauksessa tämä tarkoittaa työkaluja HTML sivujen tuottamiseen, tietokannan käyttöön, ym. Djangosta löytyy kaikki mitä ohjelmoija tarvitsee jotta voi keskittyä oman koodin kirjoittamiseen ilman, että tarvitsisi rakentaa perusteita uudelleen joka sovellusta varten.” http://djangodames.fi/mika-ihmeen-django/

Miksi sovelluskehys?

Miksei uutta verkkopalvelua rakennettaisi aina esimerkiksi WordPressin, Drupalin, Liferayn tai vaikkapa Magenton päälle? Näin kannattaakin ehkä edetä, jos valmis alusta tarjoaa suuren osan tavoitelluista toiminnoista ja tunnistettavia räätälöintitarpeita on vähän.

Verkkopalveluiden vaatimuksia ja liiketoiminnan tavoitteita punnittaessa, huomataan usein, että tarpeet voivat poiketa merkittävästi olemassa olevien alustatuotteiden tarjoamista teknisistä ratkaisuista. Valmiissa julkaisujärjestelmissä ja alustatuotteissa saattaa tulla mukana monia ominaisuuksia ja toimintamalleja, jotka ovat rakennettavassa palvelussa turhia. Lisäksi ne saattavat tuoda mukanaan ylimääräisiä riippuvuuksia, jotka monimutkaistavat verkkopalvelun kehittämistä.

Start-upilla voi olla täysin uudenlainen bisnesidea tai ansaintalogiikkamalli, johon eivät valmistuotteet taivu joustavasti, eikä prosessia haluta muovata valmistuotteiden ehdoilla. Verkkopalvelulla voidaan haluta luoda kokonaan uudenlaista lisäarvoa käyttäjilleen tai vallata markkinoita ratkaisemalla jokin ongelma kokonaan eri tavoin kuin kilpailijat aiemmin. Tällöin fiksu teknologiapäätös on valita parhaiten projektiin sopiva sovelluskehys ja toteuttaa uusi verkkopalvelu sen päälle.

“Itse tehtiin ja hyvin pyörii”

Silloin tällöin eteemme tulee yrityksillä käytössä olevia verkkopalveluja, joiden kehityksen elinkaari on alkanut vuosituhannen alkupuolelta tai vielä kauempaa. Tyypillistä tällaisille ns. legacy-ratkaisuille on, että projektin alkumetreillä kehittäjillä ei vielä ole ollut vakiintuneita parhaita käytäntöjä ja sovelluskehykset eivät ole olleet tuttuja kehittäjille.

Verkkopalvelua on saatettu lähteä ohjelmoimaan täysin puhtaalta pöydältä. Huolellisesti toteutettuna tällaisissa projekteissa verkkopalvelun ympärille on saattanut kehittyä omia sovelluskehysmäisiä piirteitä valituista suunnittelumalleista riippuen. Joskus taas kasaamisessa on käytetty oikoteitä, purkkaa ja laastaria, jolloin ajan myötä lopputulos on saattanut virittelyjen jälkeen muotoutua kirjavaksi tilkkutäkiksi, jota on työlästä ylläpitää. Toteutuksessa on voinut eri aikoina olla mukana muutamia eri kehittäjiä ja lähdekoodiin on päässyt kertymään käytöstä poistunutta koodia, kun versionhallintaa ole harjoitettu riittävällä tasolla.

Ilman tällaisen ohjelmiston syvällistä yksityiskohtien tuntemista koodin ylläpito ja muutokset ovat riskialttiita – muutos yksittäiseen komponenttiin voi aiheuttaa ennustamattomia sivuvaikutuksia muualla ohjelmistossa. Jos yrityksen toiminta on keskittynyt näin rakennetun verkkopalvelun ympärille, tämä voi muodostaa suuren liiketoimintariskin – tietoturvariskeistä puhumattakaan. Entä jos palvelua kehittänyt henkilökunta sairastuu vakavasti tai vaihtaa työpaikkaa?

Sovelluskehys voi antaa turvaa tällaisissa tilanteissa. Sovelluskehyksen käytäntöjen ansiosta verkkopalvelun jatkokehitys ei ole enää tiukasti riippuvainen alkuperäisen kehittäjäporukan asiantuntemuksesta. Joskus onkin kannattavaa siirtää parasta ennen -päiväyksensä ohittaneiden verkkopalveluiden ydintoiminnallisuuksia sopivan sovelluskehyksen päälle tai jopa kirjoittaa toteutus kokonaan uusiksi.

Mm. tällaisia tapauksia varten kehittyi Sofokus Katsastus -palvelumme, josta voit lukea lisää täältä (https://www.sofokus.com/fi/sofokus-katsastus/) ja täältä (https://www.sofokus.com/fi/katsastus/).

Millaiseen sovelluskehykseen verkkopalveluni istuisi parhaiten?

Sovelluskehyksen avulla saavutetaan monia etuja verkkopalvelujen kehittämiseen:

  • Kehittäminen on ripeää: valmiit “rakennustelineet” verkkopalvelulle ja pohja yleisimmin tarvittavia toimintoja varten
  • Testaustyökalut: laadunvarmistus helpottuu
  • Valmiit kirjastot, sovelluspaketit ja tuoterungot omaan projektiin liitettäväksi: pyörää ei tarvitse keksiä uudelleen
  • Lähdekoodista tulee automaattisesti helppolukuisempaa ja itsestään dokumentoituvaa: useampien kehittäjien kytkeminen projektiin kevyempää, matala oppimiskynnys
  • Tietoturva: mm. SQL-injektioiden, XSS-hyökkäysten ja muiden yleisten uhkien torjunta
  • Yhtenäiset ohjelmointikäytännöt, standardien noudattaminen ja komponenttien uudelleenkäytettävyys

Sovelluskehykseen valintaan vaikuttavia seikkoja on useita.

Seuraavassa muutamia yleisiä laatukriteerejä:

  • Aktiivisesti ylläpidetty ja laaja dokumentaatio
  • Elinkaari: riittävän kypsä ja yleisesti käytetty (tuttuja referenssejä toteutuksista)
  • Osaaminen levinnyttä, ei lukitse tilaajaa rajattuihin kehittäjäresursseihin
  • Uusia versiota julkaistaan säännöllisesti
  • Tuottelias kehittäjäyhteisö ja elinvoimainen ekosysteemi
  • Laajennusten määrä ja laatu
  • Verkkopalvelun yleiset rakennustarvikkeet sisäänrakennettuna tai liitettävissä, mm.:
    • käyttäjien ja kirjautumisen hallinta
    • kansainvälistys/lokalisointi
    • sivupohjat / template-moottori
    • MVC tai muut suunnittelumallit
    • välimuistit
    • ORM tai muu vastaava malli tietokantaoperaatioiden käsittelyyn
    • liitettävyys, REST-rajapinnat

Verkkopalvelukohtaisesti tehtäviä ratkaisuja:

  • Minkä tyyppistä verkkopalvelua ollaan rakentamassa, esim:
    • UX-painottunut reaaliaikainen yhden sivun ajax-sovellus
    • API-rajapinnat tarjoava data-orientoitunut tietovarasto
    • sisällönhallintajärjestelmä, jossa runsaasti liittymiä ulkoisiin järjestelmiin
    • vai nopeasti pystytettävä kampanjasivusto kuten kilpailu
  • Jos kehittäjäresurssit on jo valittu, mikä on tiimin preferenssi ohjelmointikielelle ja taustatekniikalle: kehittäjien osaamisen painottuminen PHP-ohjelmointikieleen tai onko julistauduttu käyttämään pelkästään esim. Microsoftin teknologioita.
  • Infrastruktuuriin liittyvät päätökset: verkkopalvelua on ajettava tuotannossa PaaS-pilvialustoilla tai sen on oltava tiivis osa jonkin järjestelmäkokonaisuuden ekosysteemiä palvelinympäristöä myöten
  • Soveltuuko lisenssimalli projektiin
  • Vaatimuksia tukevien valmiiden laajennusten saatavuus

Idean synnyttäminen konkreettiseksi verkkopalveluksi voi tapahtua lähes millä teknologialla tahansa. Kaikilla sovelluskehyksillä on omat plussat ja miinukset. Sofokuksessa toteutamme räätälöityjä verkkopalveluja pääasiassa Djangolla, joka on osoittautunut ilmaisuvoimaiseksi ympäristöksi ja soveltunut erinomaisesti ratkaisemaan yleisimmät määrittelyissä tunnistetut tarpeet sisällönhallintatyökaluja ja API-laajennuksia myöten.

Poimintoja web-sovelluskehyksistä

Alle on poimittu muutamia nykyään yleisesti käytössä olevia sovelluskehyksiä.

  • Django (Python)
  • Ruby on Rails (Ruby)
  • MEAN (Node.js, varsinainen sovelluskehys teknologiapinossa: Express)
  • PHP-sovelluskehyksiä: CodeIgniter, Symfony, CakePHP, Zend, Yii
  • Java-pohjaisia kehyksiä: Scala/Lift, Groovy/Grails, Spring, Tapestry, Wicket
  • Microsoft-teknologiat: .NET / ASP.NET

Sovelluskehykset käyttävät eri ohjelmointikieliä, painottuvat ohjelmistoarkkitehtuurin eri osa-alueisiin ja ovat kehittyneet omista lähtökodistaan. Paneudutaan myöhemmissä blogeissa tarkemmin vertailemaan sovelluskehysten välisiä eroja.

Projektin onnistuminen on teknologiavalintojen ohella kiinni tietysti mm. tuotevisiosta, toteutustavoista, projektimallista ja -johtamisesta sekä markkinasta, johon verkkopalvelu toteutetaan. Hyvä toimittaja osaa suositella sopivimpia teknisiä ratkaisuja.

Tästä lisää Teemun blogissa: https://www.sofokus.com/blogi/miten-valita-sopiva-jarjestelmatoimittaja/

“Teknisen tuotteen (alusta, IT-ratkaisu, tuote jne.) oikeaan osunut valinta on kiistämättä keskeistä onnistuneelle IT-projektille.  Yleensä onnistuneen hankinnan lopputulos on lopulta enemmän kiinni toimittajan pätevyydestä kuin teknisestä tuotteesta.”

Muuta aiheeseen liittyvää:

Lue myös Erkki Kallion blogi, jossa aihetta käsitellään vertailemalla Django-sovelluskehystä ja WordPress-julkaisujärjestelmää: https://www.sofokus.com/blogi/django-ei-ole-sisallonhallintajarjestelma/