Käytän seuraavassa niin paljon sanoja frontend ja backend, että avaan niitä hieman. Frontend tarkoittaa web-applikaation selaimessa näkyvää sivuston ulkoasua, eli onko käytössä mikä fontti, missä kohtaa selainta teksti näytetään tai mitä tietoa selaimessa esimerkiksi näytettäväksi backendiltä tilataan. Backend vastaa sitä osaa applikaatiosta, joka pyörii serverillä ja joka vastaa käyttäjän tekemisten tallentamisesta sekä frontendin tilaamien tallennettujen tietojen palauttamisesta frontendille.
Mikäli applikaatiot voidaan toteuttaa ilman JavaScript-pohjaisia frontend-kirjastoja kuten Reacteja ne tietysti on hyvä varmasti niin toteuttaa, mutta esimerkiksi React- tai Vue-kirjastot ovat web-kehityksessä sen verran arkipäivää meidänkin firmassa, että omien jQuery-kirjaston ympärille rakentamieni frontend "kirjastojen" käyttöä ei ole syytä suosia, vaikka niiden hyödyntäminen omaa työskentelyäni merkittävästi nopeuttaisikin. Meillä on yksi vanha järjestelmä elinkaarensa aivan äärimmäisessä loppuvaiheessaan, jossa niitä käytän, kun meillä on jo korvaava tuote käytössä, jossa käytössä uusimmat web-teknologiat.
Luin kuitenkin hiljattain uutisen koskien modernia React-kehitystä, että siinä oltaisiin ainakin joissain tapauksissa siirrytty suosimaan React ja Next -kirjastojen käyttöä tai kaiketi pelkkää Next-kirjaston käyttöä. Ymmärsin artikkelista, että siinä missä React on frontend-kirjasto, Next olisi React-pohjainen backend/frontend-kirjasto tarkoittaen, että selkeän frontend ja backend jaon sijaan olisi web-kehityksessä ainakin lähitulevaisuudessa luvallista sulauttaa molemmat applikaation osa-alueet on toisiinsa. Tämä sopisi minulle loistavasti ja tätähän fullstack-kehitys on ennen Reackteja ja muita frontend-kirjastoja ollutkin. Ei ole ollut tavallaan selkeästi kahta eri applikaatiota vaan yksi applikaatio, joka sisältää sekä backendin ja frontendin.
Jos taas frontend ja backend on erotettu omiksi kokonaisuuksikseen, edellyttää se helposti esimerkiksi MVC-hierarkian tai muun vastaavan proseduurin rakentamista erikseen niin fronendiin ja backendiin siinä missä perinteisissä järjestelmissä riittää vain yksi sellainen. Tosin vaikka erillinen frontend ja backend edellyttävät enempi koodaamista, Niin jos applikaation jossain elinkaarensa vaiheessa olosuhteet sitä vaativat, on siinä toteutuksessa näppärää päivittää kerralla esimerkiksi koko frontend, joitain sen osia tai rakentaa saman aikaisesti toimivia useampia erilaisia frontendejä samalle backendille ilman, että tarvitsee koskea backendiin.
Mutta lukemassani toisessa artikkelissa, jossa puitiin sitä, kannattaako tietokantaspesifikoodi abstrahoida niin, että tietokantaimplementaatio on helppo vaihtaa muuttamatta muuta koodia, niin on kuulemma hyvin harvinaista, että koskaan muutettaisiin tietokantaa kesken applikaation elinkaarta ja silloinkin kun sitä silloin muutetaan, muutetaan sitä helposti niin paljon, että edes pelkän abstrahoinninkaan uudelleen kirjoittamisella ei hommasta selvitä tarkoittaen, että ylimääräiset abstrahoinnit voivat olla täysin turhia.
Toisin sanoen voinen varmaan aika luottavaisesti edistää ohjelmointitaitojani pitäen sitä mielessäni, että ellei applikaatio ole sellainen, että sen frontendin, backendin tai ominaisuuksiensa kehitystä ei ole tarkoitus ulkoistaa eri eri tiimeille puhumattakaan eri firmoille, voin keskittyä tavallaan perinteiseen fullstack-kehitykseen ja pohtia frontendin ja backendin erottamista omiksi kokonaisuuksiksi joskus myöhemmin.
Tämä tarkoittaa, että pitää yrittää ripeästi tutustua Laravel + Intertia + React kokoonpanoon. Kokoonpano mahdollistaa sen, että voisin rakentaa applikaation sekä Laravelilla että Reactilla ilman, että Laravel-implemetaatio ja React-implementaatio pitäisivät olla kaksi erillistä järjestelmää. Inertia toteuttaa nimittäin tarvittavan proseduurin Laravelin ja Reactin väliselle kommunikaatiolle.
Mikäli tulevaisuudessa backend ja fronend pitää kuitenkin voida erottaa omiksi kokonaisuuksiksi inertian korvaaminen backendissä tarkoitukseen soveltuvalla api-koodilla ja fronendissä React Router -kirjastolla ja MVC-tyyppisellä koodilla on varmasti tehtävissä hyvin vähäisellä vaivalla sillä frontend-kirjasto React ja backend-kirjasto Laravel ovat jo paikallaan.
Tietysti myös serveriasetukset paljolti määräävät voiko backend vastata myös frontendin renderöinnistä vai olisiko hyvä, että frontendin renderöinnistä vastaa käyttäjän selain. AWS:n sereveless-ympäristö edellyttää, että frontendin renderöinnistä vastaa käyttäjän selain. Tai siis ei edellytä, mutta serverin tietyillä käyttöasteilla AWS:n hintaa saadaan merkittävästi huokeammaksi, mitä vähemmän sitä serveriä, jolla backend on, käytetään. Ideaalitilanne olisi AWS:n serverless-serverin hyödyntämisessä oman applikaation api ja AWS:n tarjoama valikoima valmiita apeja, joita selain käyttää. Jotta selain osaisi niitä käyttää, edellyttää se JavaScriptiä. Jotta muutkin ohjelmoijat ymmärtäisivät kirjoittamaani JavaScriptiä tai minä ymmärtäisin nyt kirjoittamaani koodia puolen vuoden kuluttuakin on ihan perusteltua käyttää yleisessä käytössä olevia valmiita JavaScript-kirjastoja kuten Reactia tai Vueta sen sijaan, että innovoisin omia ratkaisujani jQueryllä.
Olisiko muilla ajatuksia pohdintoihini?
