Integraation näkymätön hintalappu

Jokainen kehittäjä tuntee sen tunteen. Olet valinnut server-frameworkin, ORM:n, validointikirjaston, frontendin ja build-työkalut. Kaikki näyttää paperilla täydelliseltä. Sitten alat rakentaa oikeita ominaisuuksia ja huomaat, että validointikirjasto ei ymmärräkään ORM:si palauttamaa datamuotoa. Frontend-frameworkin palvelinpuolen renderöinti ei toimikaan sujuvasti server-frameworkisi middleware:n kanssa. Sessionhallinta olettaa asioita, jotka rikkoutuvat kun yrität deployata reunapalvelimelle.

Jokainen yksittäinen työkalu on loistava. Saumat ovat painajainen.

Miten tähän päädyttiin

JavaScript-ekosysteemi on aina arvostanut koostettavuutta yhtenäisyyden sijaan. Se ei ole sinänsä väärin – UNIX-filosofia on palvellut meitä vuosikymmeniä. Ongelma on, että web-sovellukset eivät ole eristettyjen datamuunnosten putkistoja. Ne ovat sotkuisia verkkoja jaetuista oletuksista: requestien rakenteista, validointirajoista, autentikaatiovirroista, renderöintikonteksteista, deploytauskohteista.

Kun Django saapui vuonna 2005, se panosti: kehittäjät vaihtaisivat joustavuutta yhtenäiseen järjestelmään. Voit yhä ulottua pinon ulkopuolelle tarvittaessa, mutta sisällä kaikki oli suunniteltu toimimaan yhdessä. Tämä omistajuus tarkoitti harhempia yllätyksiä.

PHP-frameworkit ymmärsivät tämän myös. Laravel, Symfony, Yii – kaikki tarjosivat sen "yhtenäinen järjestelmä" -tunteen. Tiesit mikä oli virallista aluetta ja mikä vaati retkeä villiin luontoon.

Sitten JavaScript söi serverin, ja me suurimmaksi osaksi menetimme sen.

Meta-frameworkin ansa

Modernit meta-frameworkit paransivat asioita joiltakin osin. Next.js, Nuxt, SvelteKit – ne antoivat taas yhtenäisen stackin. Mutta ne tekivät sen kaventamalla valintojasi laajentamisen sijaan.

Tässä on pointti: Next.js on loistava React-stack. Mutta jos rakastat Solidin suorituskykyominaisuuksia tai Svetin yksinkertaisuutta, et vain vaihda view-kerrosta. Otat käyttöön eri meta-frameworkin eri konventioilla, erilaisilla reititysmalleilla, erilaisilla backend-olettamuksilla. Opettelet uudelleen samat ongelmat jotka jo ratkaisit, eri syntaksilla.

Tämä luo absurdin tilanteen. Frontend-ekosysteemi innovoi jatkuvasti, mutta lähestymistavan vaihtaminen vaatii melkein puhtaalta pöydältä aloittamista. React- ja Svelte-kehittäjät ratkaisevat samat backend-ongelmat itsenäisesti, hieman eri tavoin, ikuisesti.

Ajonaikaisen ympäristön arpajaiset

Sitten on vielä ajonaikaisen ympäristön pirstaloituminen. Node.js, Deno, Bun – kaikki ovat kyvykkäitä alustoja, mutta useimmat frameworkit ovat käytännössä ajonaikaisesti sidottuja. Kun framework väittää tukevansa Denoa, se usein tarkoittaa vain, että "Deno pystyy ajamaan meidän Node-koodia." Se ei ole sama asia kuin että framework olisi suunniteltu Denon natiivien APIen ja suoritumallin ympärille.

Tällä on enemmän merkitystä kuin voisi kuvitella. Valitsemasi ajonaikainen ympäristö vaikuttaa suorituskykyominaisuuksiin, deploytauskohteisiin ja turvallisuusmalleihin. Lukitseminen frameworkiin, joka toimii todella vain yhdellä ajonaikaisella ympäristöllä, rajoittaa vaihtoehtojasi ekosysteemin kehittyessä.

Mitä me todella tarvitsemme

Tässä pointti: web-sovelluksilla on luonnollisia kerroksia, jotka eivät tarvitse olla kytkettyjä toisiinsa.

Frontendit kuvaavat selaimen käyttöliittymää. Backendit käsittelevät requestejä, dataa ja sovelluslogiikkaa. Ajonaikaiset ympäristöt ovat suorituskohteita. Näiden huolien pitäisi pystyä vaihtelemaan itsenäisesti.

Kuvittele rakentavasi yhden reitin Reactilla koska tarvitset sen komponenttiekosysteemiä. Toisen reitin Sveltellä koska suorituskyky on siellä tärkeämpää. Ajaminen Node.js-reittejä tänään, mutta TypeScript-reittien deploytaus Bunille kun tarvitset nopeutta. Kaikki samassa sovelluksessa, samalla backend-mallilla, samalla validoinnilla, samoilla sessioilla.

Se ei ole maagista ajattelua. Se on huolten käsittelemistä erillisinä huolina, mikä on aina ollut hyvän ohjelmiston rakentamisen tapa.

Frameworkin pitäisi omistaa saumat

En väitä, että yksi framework hallitsisi kaikkea. Väitän, että frameworkin pitäisi ottaa vastuu siitä, että sen osat toimivat yhdessä. Sinun pitäisi yhä pystyä ulottumaan virallisen pinon ulkopuolelle tarvittaessa – kukaan ei toimita täydellisiä oletuksia jokaiseen käyttötapaukseen. Mutta kun pysyt frameworkin sisällä, saumat pitäisi olla frameworkin ongelma ratkaistavaksi, eikä sinun.

Framework, joka pakottaa sinut ajattelemaan reititystä, validointia, datahakua ja renderöintiä erillisinä ongelmina jotka sinun täytyy liimata yhteen, ei ole framework. Se on ehdotus.

Parhaat frameworkit antavat sinun omistaa liiketoimintalogiikkasi samalla kun ne ottavat omistajuuden kaikesta muusta.

NimeOceanilla olemme nähneet, miten hostingin monimutkaisuus voi kasvaa kun stackisi on pirstaloitunut. Frameworkin valitseminen joka kunnioittaa huolten erottelua – joka antaa sinun vaihtaa osia ilman että kaikki pitää kirjoittaa uudelleen – tekee deploytauksesta, skaalauksesta ja ylläpidosta huomattavasti yksinkertaisempaa.

Kysymys ei ole siitä, käyttääkö frameworkia. Kysymys on, toimiiko sinun frameworkisi puolestasi vai lisääkö se vain kerroksen päätöksiä joita et tarvinnut tehdä.

Mitä se tarkoittaisi rakentaa seuraava sovellus työkalulla joka omistaa saumat? Se on syytä miettiä ennen seuraavaa projektin alustamista.