Frontend 'Edgellä': Syväsukellus Cloudflare Workersiin ja AWS Lambda@Edgeen

Jatkuvassa pyrkimyksessä kohti nopeampia, turvallisempia ja yksilöllisempiä käyttäjäkokemuksia verkon arkkitehtuuri on kokemassa syvällistä muutosta. Vuosien ajan malli oli yksinkertainen: keskitetty palvelin, sisällönjakeluverkko (CDN) staattisten resurssien välimuistiin tallentamiseen ja asiakasohjelma. Mutta sovellusten monimutkaistuessa ja käyttäjien odotusten nopeutuessa tämä perinteinen malli on osoittamassa rajoituksensa. Tervetuloa reunalaskennan (edge computing) aikakauteen – paradigman muutokseen, joka siirtää laskennan ja logiikan kaukaisilta pilvipalvelimilta verkon reunalle, vain millisekuntien päähän loppukäyttäjästä.

Frontend-kehittäjille ja -arkkitehdeille tämä ei ole vain yksi uusi backend-trendi. Se edustaa perustavanlaatuista muutosta siinä, miten rakennamme, otamme käyttöön ja toimitamme verkkosovelluksia. Se antaa frontendille valmiuksia, jotka olivat aiemmin varattu vain palvelimelle, hämärtäen rajoja ja avaten ennennäkemättömiä mahdollisuuksia. Tällä globaalilla areenalla kaksi jättiläistä on noussut edelläkävijöiksi: Cloudflare Workers ja AWS Lambda@Edge. Tämä opas tarjoaa kattavan tutkimusmatkan molempiin alustoihin, auttaen sinua ymmärtämään niiden perusperiaatteet, vertailemaan niiden vahvuuksia ja heikkouksia sekä päättämään, kumpi sopii paremmin seuraavaan globaaliin projektiisi.

Mitä on frontend-reunalaskenta? CDN:stä ohjelmoitavaan reunaan

Ymmärtääkseen reunalaskennan merkityksen on olennaista ymmärtää sen evoluutio. Ytimessään "reuna" viittaa globaaliin palvelinverkostoon (läsnäolopisteisiin, PoP), jotka sijaitsevat sovelluksesi alkuperäpalvelimen ja käyttäjien välissä. Perinteisesti näitä palvelimia käyttivät CDN:t yhteen pääasialliseen tarkoitukseen: välimuistiin tallentamiseen.

Evoluutio: Välimuistituksen tuolla puolen

CDN:t mullistivat verkon suorituskyvyn tallentamalla kopioita staattisista resursseista, kuten kuvista, CSS- ja JavaScript-tiedostoista, PoP-pisteisiin ympäri maailmaa. Kun käyttäjä Tokiossa pyysi tiedostoa, se tarjoiltiin läheiseltä palvelimelta Japanista sen sijaan, että se olisi tehnyt pitkän ja korkean latenssin matkan alkuperäpalvelimelle Pohjois-Amerikkaan. Tämä vähensi latausaikoja dramaattisesti.

Tämä malli rajoittui kuitenkin staattiseen sisältöön. Kaikki dynaaminen logiikka – kuten sisällön personointi, käyttäjän autentikointi tai A/B-testin suorittaminen – vaati edelleen edestakaisen matkan alkuperäpalvelimelle. Tämä matka aiheutti latenssia, hyvän käyttäjäkokemuksen vannoutunutta vihollista.

Reunalaskenta murskaa tämän rajoituksen. Se tekee CDN:n reunaverkosta ohjelmoitavan. Sen sijaan, että kehittäjät vain tallentaisivat staattisia tiedostoja välimuistiin, he voivat nyt ottaa käyttöön ja suorittaa omaa koodia suoraan näillä reunapalvelimilla. Tämä tarkoittaa, että dynaaminen logiikka voi toimia käyttäjää lähimmässä PoP-pisteessä, siepata pyyntöjä ja muokata vastauksia lennossa, ilman että monissa tehtävissä tarvitsee koskaan ottaa yhteyttä alkuperäpalvelimeen.

Miksi sillä on merkitystä frontendille?

Logiikan tuominen reunalle vaikuttaa valtavasti frontend-kehitykseen ja sovelluksen suorituskykyyn. Hyödyt ovat merkittäviä:

• Merkittävästi pienempi latenssi: Suorittamalla koodia lähempänä käyttäjää poistat edestakaisen matkan ajan keskitettyyn palvelimeen. Tämä johtaa nopeampiin API-vastauksiin, nopeampiin sivujen latauksiin ja rivakampaan, reagoivampaan käyttöliittymään.
• Parannettu suorituskyky: Tehtäviä, kuten A/B-testausta, ominaisuuslippuja (feature flagging) ja reititystä, voidaan hoitaa reunalla. Tämä siirtää kuormaa pois sekä asiakkaan selaimelta että alkuperäpalvelimelta, parantaen suorituskykyä kautta linjan.
• Globaali skaalautuvuus oletuksena: Reunafunktiot otetaan käyttöön palveluntarjoajan koko globaalissa verkossa. Sovelluksesi skaalautuu automaattisesti ja on vikasietoinen, käsitellen liikennepiikkejä mistä päin maailmaa tahansa ilman manuaalisia toimenpiteitä.
• Parempi tietoturva: Voit hoitaa tietoturvaan liittyviä tehtäviä, kuten tokenien (esim. JWT) validointia, haitallisten pyyntöjen estämistä tai pääsynvalvonnan toteuttamista reunalla, ennen kuin pyyntö edes saavuttaa alkuperäinfrastruktuuriasi. Tämä luo tehokkaan, hajautetun tietoturvakehän.
• Kustannustehokkuus: Pyyntöjen siirtäminen pois alkuperäpalvelimilta voi vähentää niiden kuormaa merkittävästi, mikä johtaa alhaisempiin infrastruktuurikustannuksiin. Lisäksi reuna-alustojen serverless-hinnoittelumallit ovat usein erittäin kustannustehokkaita.
• Tehokas personointi: Voit muokata HTML:ää, personoida sisältöä maantieteellisen sijainnin tai käyttäjän evästeiden perusteella ja tarjota erilaisia kokemuksia eri käyttäjäsegmenteille – kaikki minimaalisella latenssilla.

Cloudflare Workers: V8-isolaattien vallankumous

Cloudflare, pitkäaikainen johtaja CDN- ja tietoturva-alalla, julkaisi Cloudflare Workersin uraauurtavana alustana serverless-reunalaskennan maailmassa. Sen ydinnovaatio ei piile vain siinä, missä koodi suoritetaan, vaan miten se suoritetaan.

Mitä ovat Cloudflare Workersit?

Cloudflare Workers mahdollistaa JavaScriptin ja WebAssemblyn (Wasm) ajamisen Cloudflaren massiivisessa globaalissa verkossa, joka kattaa satoja kaupunkeja yli 100 maassa. Worker on pohjimmiltaan koodinpätkä, joka sieppaa ja käsittelee HTTP-pyyntöjä. Se voi muokata pyyntöjä ennen kuin ne osuvat alkuperäpalvelimeesi, generoida vastauksia suoraan reunalta tai suoratoistaa sisältöä useista lähteistä.

Kehittäjäkokemus on suunniteltu tutunomaiseksi, käyttäen Service Workerin kaltaista API:a. Jos olet koskaan kirjoittanut service workerin verkkoselaimelle, ohjelmointimalli tuntuu intuitiiviselta.

V8-isolaattien taika

Todellinen nero Cloudflare Workersin suorituskyvyn takana on sen käyttämät V8-isolaatit perinteisten konttien tai virtuaalikoneiden (VM) sijaan. V8 on sama korkean suorituskyvyn JavaScript-moottori, joka pyörittää Google Chromea ja Node.js:ää.

Isolaatti on kevyt konteksti, joka ryhmittelee muuttujat niitä käsittelevän koodin kanssa. Useita isolaatteja voi toimia yhden käyttöjärjestelmäprosessin sisällä, mutta ne ovat täysin eristettyjä toisistaan. Tällä on syvällisiä vaikutuksia:

• Lähes olemattomat kylmäkäynnistykset: Uusi isolaatti voidaan käynnistää alle 5 millisekunnissa. Tämä on kertaluokkia nopeampaa kuin sekunnit, jotka voivat kulua uuden kontin käynnistämiseen perinteiselle serverless-funktiolle. Käyttäjille tämä tarkoittaa, että kylmäkäynnistyksiä ei käytännössä ole, ja jokainen pyyntö on nopea.
• Massiivinen skaalautuvuus ja tehokkuus: Isolaatit ovat uskomattoman kevyitä ja kuluttavat huomattavasti vähemmän muistia kuin kontit. Tämä antaa Cloudflarelle mahdollisuuden ajaa tuhansia Worker-skriptejä yhdellä fyysisellä koneella, mikä tekee alustasta erittäin tehokkaan ja kustannustehokkaan.
• Parannettu tietoturva: V8-isolaattien hiekkalaatikkoympäristö tarjoaa vahvat tietoturvarajat, estäen yhden Workerin vaikuttamasta toiseen.

Käytännön käyttötapauksia koodiesimerkein

Cloudflare Workersit ovat uskomattoman monipuolisia. Tutustutaan muutamiin yleisiin käyttötapauksiin.

A/B-testaus reunalla

Voit reitittää käyttäjiä sivustosi eri versioihin ilman asiakaspuolen JavaScriptin aiheuttamaa välkkymistä tai monimutkaista backend-logiikkaa. Worker tarkastaa saapuvan evästeen ja kirjoittaa URL-osoitteen uudelleen noutaakseen sisällön eri alkuperäpalvelimelta tai polusta.

            
// Example: A/B Testing Worker

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const AB_COOKIE = 'ab-test-variant'
  const cookie = request.headers.get('cookie')

  // Determine which variant to show
  let group = 'control'
  if (cookie && cookie.includes(`${AB_COOKIE}=treatment`)) {
    group = 'treatment'
  }

  let url = new URL(request.url)

  // If the user is in the treatment group, fetch the alternative page
  if (group === 'treatment') {
    url.pathname = '/treatment' + url.pathname
  }

  // Fetch the appropriate version
  return fetch(url, request)
}

            

              
                Copy
              
            
          

Dynaamiset URL-uudelleenkirjoitukset ja -ohjaukset

Ylläpidä siistejä URL-osoitteita käyttäjille samalla, kun ne yhdistetään erilaiseen backend-rakenteeseen, tai suorita SEO-ystävällisiä uudelleenohjauksia sivuston siirron jälkeen.

            
// Example: Dynamic Redirect Worker

const redirectMap = new Map([
  ['/old-about-us', '/about'],
  ['/products/old-product', '/products/new-product']
])

addEventListener('fetch', event => {
  const url = new URL(event.request.url)
  const { pathname } = url

  const destinationURL = redirectMap.get(pathname)

  if (destinationURL) {
    return Response.redirect(url.origin + destinationURL, 301)
  }

  // No redirect needed, proceed as normal
  return fetch(event.request)
})

            

              
                Copy
              
            
          

Autentikointi ja auktorisointi reunalla

Suojaa koko sovelluksesi tai tietyt reitit validoimalla JSON Web Token (JWT) reunalla. Virheelliset pyynnöt hylätään ennen kuin ne voivat koskaan kuluttaa alkuperäpalvelimen resursseja.

            
// Conceptual Example: JWT Validation Worker
// Note: This requires a JWT library compatible with Workers

import { verify } from 'jwt-library'; // Placeholder for a real library

const JWT_SECRET = 'your-super-secret-key';

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const authHeader = request.headers.get('Authorization')

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return new Response('Unauthorized', { status: 401 })
  }

  const token = authHeader.substring(7)

  try {
    // Verify the token at the edge
    await verify(token, JWT_SECRET)
    // If valid, proxy the request to the origin
    return fetch(request)
  } catch (error) {
    // If invalid, reject the request
    return new Response('Invalid token', { status: 403 })
  }
}

            

              
                Copy
              
            
          

AWS Lambda@Edge: CloudFrontin laajentaminen serverless-teholla

Amazon Web Services (AWS) tarjoaa oman tehokkaan ratkaisunsa reunalaskentaan: Lambda@Edge. Se ei ole itsenäinen tuote, vaan pikemminkin Amazon CloudFrontin, sen globaalin CDN:n, ominaisuus. Lambda@Edge mahdollistaa AWS Lambda -funktioiden ajamisen vastauksena CloudFront-tapahtumiin, tuoden AWS-ekosysteemin tehon ja tuttuuden reunalle.

Mitä on Lambda@Edge?

Lambda@Edge antaa sinun ajaa Node.js- ja Python-koodia AWS:n reunapisteissä maailmanlaajuisesti. Sen sijaan, että API Gateway tai S3-tapahtuma laukaisisi ne, nämä funktiot laukaisee pyynnön elinkaari sen kulkiessa CloudFrontin läpi. Tämä tiivis integraatio on sekä sen suurin vahvuus että keskeinen erottava tekijä Cloudflare Workersista.

Toisin kuin Cloudflare Workers, joka toimii jokaisessa PoP-pisteessä, Lambda@Edge-funktiot otetaan käyttöön AWS:n alueellisissa reunavälimuisteissa, jotka ovat pienempi ja keskitetympi joukko sijainteja kuin koko CloudFrontin PoP-pisteiden verkosto. Tämä on ratkaiseva arkkitehtoninen ero, jolla on suorituskykyvaikutuksia.

Neljän tapahtumakäynnistimen ymmärtäminen

Lambda@Edgen toiminnallisuus määritellään neljällä erillisellä tapahtumakäynnistimellä, joihin voit liittää funktion. Näiden ymmärtäminen on avain palvelun tehokkaaseen käyttöön.

• Viewer Request: Tämä käynnistin aktivoituu, kun CloudFront on vastaanottanut pyynnön katsojalta (käyttäjältä), mutta ennen kuin se tarkistaa välimuistinsa. Se on ihanteellinen tehtäviin, jotka on suoritettava jokaisella pyynnöllä, kuten uudelleenohjauksiin, otsikkotietojen manipulointiin tai evästepohjaiseen personointiin.
• Origin Request: Tämä käynnistin aktivoituu vain, kun pyydetty sisältö ei ole CloudFrontin välimuistissa (välimuistihuti). Funktio suoritetaan juuri ennen kuin CloudFront välittää pyynnön alkuperäpalvelimellesi (esim. S3-bucket tai EC2-instanssi). Se sopii täydellisesti monimutkaisiin URL-uudelleenkirjoituksiin, dynaamiseen alkuperäpalvelimen valintaan tai autentikointiotsikoiden lisäämiseen, jotka vain alkuperäpalvelimen tarvitsee nähdä.
• Origin Response: Tämä käynnistin aktivoituu, kun CloudFront on vastaanottanut vastauksen alkuperäpalvelimelta, mutta ennen kuin se tallentaa vastauksen välimuistiin. Voit käyttää sitä muokataksesi alkuperäpalvelimen vastausta, kuten lisäämällä tietoturvaotsikoita, muuttamalla kuvien kokoa tai piilottamalla alkuperäpalvelinkohtaisia otsikoita.
• Viewer Response: Tämä käynnistin aktivoituu juuri ennen kuin CloudFront lähettää lopullisen vastauksen takaisin katsojalle, riippumatta siitä, oliko se välimuistiosuma vai -huti. Se on hyödyllinen lisättäessä otsikoita, joita selain tarvitsee, kuten CORS- tai HSTS-otsikoita, tai lopullisten vastaustietojen kirjaamiseen.

Käytännön käyttötapauksia koodiesimerkein

Katsotaan, miten yleisiä ongelmia voidaan ratkaista käyttämällä Lambda@Edgen käynnistinpohjaista mallia.

Otsikkotietojen mukauttaminen tietoturvaa ja välimuistitusta varten

Käytä Viewer Response -käynnistintä lisätäksesi tärkeitä tietoturvaotsikoita, kuten `Strict-Transport-Security`, jokaiseen käyttäjälle tarjoiltuun vastaukseen.

            
// Example: Add Security Headers (Viewer Response)

'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;

    headers['strict-transport-security'] = [{ key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' }];
    headers['x-content-type-options'] = [{ key: 'X-Content-Type-Options', value: 'nosniff' }];
    headers['x-frame-options'] = [{ key: 'X-Frame-Options', value: 'DENY' }];
    headers['x-xss-protection'] = [{ key: 'X-XSS-Protection', value: '1; mode=block' }];

    callback(null, response);
};

            

              
                Copy
              
            
          

Laitekohtainen sisällönjakelu

Käyttämällä Viewer Request -käynnistintä voit tarkastaa `User-Agent`-otsikon ohjataksesi mobiilikäyttäjät erilliselle mobiilisivustolle tai kirjoittaaksesi URL-osoitteen uudelleen noutaaksesi mobiilioptimoidun version sisällöstä.

            
// Example: Mobile Redirect (Viewer Request)

'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    const userAgent = headers['user-agent'] ? headers['user-agent'][0].value : '';
    const isMobile = userAgent.includes('Mobile') || userAgent.includes('Android');

    if (isMobile) {
        const response = {
            status: '302',
            statusDescription: 'Found',
            headers: {
                'location': [{ key: 'Location', value: 'https://m.yourwebsite.com' + request.uri }]
            }
        };
        callback(null, response);
        return;
    }

    // Continue with the original request for non-mobile users
    callback(null, request);
};

            

              
                Copy
              
            
          

Alkuperäpalvelimen suojaaminen pääsynhallinnalla

Origin Request -käynnistimellä voit lisätä salaisen otsikon ennen pyynnön välittämistä alkuperäpalvelimellesi. Alkuperäpalvelimesi voidaan sitten määrittää hyväksymään vain pyyntöjä, jotka sisältävät tämän salaisen otsikon, estäen ketään ohittamasta CloudFrontia.

            
// Example: Adding a Secret Header to Origin Requests (Origin Request)

'use strict';

const SECRET_HEADER_VALUE = 'your-very-secret-value';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    // Add a secret header
    request.headers['x-origin-secret'] = [{ key: 'X-Origin-Secret', value: SECRET_HEADER_VALUE }];

    // Forward the modified request to the origin
    callback(null, request);
};

            

              
                Copy
              
            
          

Vertailussa: Cloudflare Workers vs. AWS Lambda@Edge

Molemmat alustat ovat uskomattoman tehokkaita, mutta ne on rakennettu eri filosofioiden ja arkkitehtuurien pohjalle. Niiden välillä valitseminen vaatii niiden keskeisten ominaisuuksien huolellista vertailua.

Vertailun tärkeimmät johtopäätökset:

• Puhtaan suorituskyvyn ja alhaisimman latenssin osalta Cloudflare Workers on edellä sen V8-isolaattiarkkitehtuurin ja laajan PoP-verkoston ansiosta. Kylmäkäynnistysten puuttuminen on merkittävä etu käyttäjille suunnatuissa sovelluksissa.
• Syvään integraatioon olemassa olevan AWS-infrastruktuurin kanssa Lambda@Edge on luonnollinen valinta. Se hyödyntää tuttuja AWS-käsitteitä kuten IAM ja integroituu saumattomasti CloudFrontin, S3:n ja muiden palveluiden kanssa.
• Kehittäjäkokemus mainitaan usein Cloudflare Workersin suurena vahvuutena. Wrangler CLI, nopeat käyttöönotot ja yksinkertainen API mahdollistavat nopean kehityssyklin. Lambda@Edge sisältää enemmän konfigurointia ja hitaammat käyttöönottoajat.
• Lambda@Edge tarjoaa hienojakoisempaa hallintaa neljällä erillisellä käynnistimellään, mikä mahdollistaa kustannusten ja suorituskyvyn optimoinnin ajamalla koodia vain ehdottoman välttämättömissä tilanteissa (esim. vain välimuistihudeissa).

Reunan tulevaisuus: Mitä seuraavaksi?

Frontend-reunalaskenta on vielä alkuvaiheessa, ja innovaatio tapahtuu huimaa vauhtia. Alkuperäinen keskittyminen tilattomaan laskentaan laajenee nopeasti. Tässä on joitain tulevaisuutta muovaavia trendejä:

• Tila reunalla: Suurin haaste on tilan hallinta. Palvelut, kuten Cloudflare Workers KV ja Durable Objects, ovat uranuurtajia tavoissa tallentaa dataa reunalle, mikä mahdollistaa monimutkaisempien sovellusten, kuten reaaliaikaisten chattien, yhteiskäyttöisten dokumenttien ja ostoskorien, toiminnan kokonaan reunaverkossa.
• WebAssembly (Wasm): Wasm antaa kehittäjille mahdollisuuden ajaa Rustin, C++:n ja Go:n kaltaisilla kielillä kirjoitettua koodia lähes natiivinopeudella turvallisessa hiekkalaatikossa. Tämä avaa oven suorituskykykriittisille tehtäville, kuten videonkäsittelylle, monimutkaisille laskelmille ja koneoppimisen päättelylle reunalla.
• Tietokannat reunalla: Datan replikointi ja synkronointi globaalissa verkossa on valtava haaste. Uudet palvelut, kuten Cloudflaren D1 ja FaunaDB, rakentavat globaalisti hajautettuja tietokantoja, jotka on suunniteltu toimimaan saumattomasti reunafunktioiden kanssa, minimoiden datan käyttöön liittyvän latenssin.
• Reuna-tekoäly/koneoppiminen: Laitteiden ja reunapalvelimien tehostuessa koneoppimismallien ajaminen reunalla personoinnin, petostentorjunnan ja kuva-analyysin kaltaisiin tehtäviin tulee yleiseksi, tarjoten älykkäitä vastauksia minimaalisella viiveellä.

Oikean valinnan tekeminen projektiisi

Päätös Cloudflare Workersin ja AWS Lambda@Edgen välillä riippuu vahvasti erityistarpeistasi, olemassa olevasta infrastruktuuristasi ja suorituskykytavoitteistasi.

Milloin valita Cloudflare Workers

• Suorituskyky on ykkösprioriteettisi. Jos rakennat erittäin interaktiivista sovellusta, jossa jokainen latenssin millisekunti on tärkeä, Workersin lähes olemattomat kylmäkäynnistykset ovat ratkaiseva etu.
• Logiikkasi on tilatonta tai voi käyttää reunalle natiivia tilaa. Workers loistaa tehtävissä kuten autentikointi, A/B-testaus ja uudelleenohjaukset. Tilaa varten käytät heidän ekosysteemiään (KV, Durable Objects).
• Arvostat nopeaa, modernia kehittäjäkokemusta. Jos tiimisi haluaa edetä nopeasti yksinkertaisella CLI:llä, nopeilla käyttöönotoilla ja verkkostandardeihin perustuvalla API:lla, Workers on erinomainen valinta.
• Olet rakentamassa uutta projektia tai et ole sidottu AWS-ekosysteemiin. Se tarjoaa tehokkaan, itsenäisen alustan globaalisti hajautettujen sovellusten rakentamiseen.

Milloin valita AWS Lambda@Edge

• Olet vahvasti investoinut AWS-ekosysteemiin. Jos infrastruktuurisi, tietovarastosi ja CI/CD-putkesi on jo rakennettu AWS:n päälle, Lambda@Edge integroituu luonnollisemmin.
• Tarvitset hienojakoista hallintaa pyynnön elinkaaresta. Neljän käynnistimen malli mahdollistaa hienosäädetyn logiikan, joka voi optimoida kustannuksia ja suoritusta välimuistin tilan perusteella.
• Tiimisi on jo taitava AWS Lambdan ja IAM:n käytössä. Oppimiskäyrä on paljon loivempi, koska se rakentuu olemassa olevan tiedon varaan.
• Reunalogiikkasi vaatii Node.js-kohtaisia moduuleja tai monimutkaisempia laskutoimituksia, jotka saattavat ylittää Cloudflare Workersin tiukemmat suoritinrajat.

Johtopäätös: Frontend-reunan omaksuminen

Frontend-reunalaskenta ei ole enää niche-teknologia; se on korkean suorituskyvyn verkkosovellusten tulevaisuus. Siirtämällä logiikan keskitetyiltä palvelimilta globaalisti hajautettuun verkkoon voimme rakentaa kokemuksia, jotka ovat nopeampia, turvallisempia ja kestävämpiä kuin koskaan ennen. Cloudflare Workers ja AWS Lambda@Edge ovat kaksi poikkeuksellista alustaa, jotka johtavat tätä muutosta, kumpikin omalla ainutlaatuisella arkkitehtonisella filosofiallaan ja erillisillä vahvuuksillaan.

Cloudflare Workers häikäisee puhtaalla nopeudellaan, innovatiivisella V8-isolaattiarkkitehtuurillaan ja erinomaisella kehittäjäkokemuksellaan, mikä tekee siitä fantastisen valinnan latenssikriittisille sovelluksille. AWS Lambda@Edge hyödyntää AWS-ekosysteemin valtavaa tehoa ja laajuutta, tarjoten vertaansa vailla olevaa integraatiota ja hienojakoista hallintaa niille, jotka ovat jo investoineet sen alustaan.

Kehittäjänä tai arkkitehtina reunan ominaisuuksien ymmärtäminen on nyt kriittinen taito. Se avaa mahdollisuuden ratkaista pitkäaikaisia suorituskyvyn pullonkauloja ja rakentaa uuden luokan aidosti globaaleja, välittömästi reagoivia sovelluksia. Reuna ei ole vain uusi paikka koodin käyttöönottoon – se on uusi tapa ajatella verkon rakentamista.