WASM nel Browser: Distribuire VERT su CloudFront Gratuitamente

Cos’è WebAssembly?

#

WebAssembly (WASM) è un formato di istruzione binaria che gira nel browser a velocità quasi nativa. Pensalo come un target di compilazione portabile: scrivi codice in Rust, C, C++ o Go, compilalo in .wasm, e il browser lo esegue direttamente in una VM sandbox accanto a JavaScript.

Il browser ha sempre potuto eseguire calcoli, ma JavaScript è un linguaggio interpretato e tipizzato dinamicamente. È abbastanza veloce per la maggior parte dei compiti, ma non per encoding video, elaborazione immagini, crittografia o simulazioni fisiche. Prima di WASM, questi carichi di lavoro dovevano vivere su un server. Ora possono vivere nel tab del browser.

Come Funziona

#

WASM non è un linguaggio. È un target di compilazione con quattro tipi fondamentali (i32, i64, f32, f64) e una macchina virtuale basata su stack. Quando carichi un modulo .wasm, il motore JS lo compila in codice macchina nativo via JIT — partendo da una rappresentazione molto più vicina all’hardware.

sequenceDiagram
    participant Browser
    participant WASM VM
    participant JS

    Browser->>WASM VM: Carica modulo .wasm (fetch)
    WASM VM->>WASM VM: Compilazione JIT in codice nativo
    JS->>WASM VM: istanza + buffer Memory condiviso
    JS->>WASM VM: chiama funzione esportata(inputPtr, len)
    WASM VM->>WASM VM: elabora bytes nella memoria lineare
    WASM VM-->>JS: restituisce outputPtr
    JS-->>Browser: legge risultato dal buffer condiviso

Il modello di memoria è esplicito: WASM ottiene un buffer WebAssembly.Memory lineare, e JS e WASM comunicano leggendo e scrivendo in esso. Nessun garbage collector che attraversa i confini, nessun overhead di serializzazione.

// Carica e istanzia un modulo WASM da JavaScript
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('/converter.wasm'),
  { env: { memory: new WebAssembly.Memory({ initial: 256 }) } }
);

// Chiama le funzioni WASM esportate direttamente via memoria condivisa
const result = instance.exports.convert_image(inputPtr, inputLen, outputPtr);

Il Vantaggio Pratico

#

La conseguenza più importante è zero round-trip al server per lavori CPU-intensivi. Se stai convertendo un’immagine, il file non lascia mai il browser. Nessuna latenza di upload, nessun costo server, nessun problema di privacy. La CPU dell’utente fa il lavoro.

VERT: 250+ Conversioni di Formato, Completamente Locale

#

VERT è un convertitore di file open-source costruito con SvelteKit e TypeScript. Internamente delega a moduli WASM compilati (FFmpeg, ImageMagick e altri) per convertire immagini, audio e documenti interamente nel browser.

Hosting su CloudFront + S3 a Costo Zero

#

L’output di build di VERT è un sito statico standard: HTML, JS, CSS e file .wasm. I binari WASM sono grandi (FFmpeg compilato in WASM pesa diversi megabyte), quindi la scelta giusta è una CDN che li serve da una cache edge vicina all’utente.

CloudFront ha un free tier permanente: 1 TB di trasferimento dati al mese e 10 milioni di richieste HTTP/S al mese — senza scadenza.

flowchart LR
    User([Browser Utente]) -->|HTTPS| CF[CloudFront Edge]
    CF -->|Solo cache miss| S3[(S3 Bucket\nprivato)]
    CF -.->|.wasm, .js, .css in cache| User

    subgraph AWS
        CF
        S3
        OAC[Origin Access Control]
    end

    OAC -- firma SigV4 --> S3
    CF -- usa --> OAC

Step 1: Build di VERT

#

git clone https://github.com/VERT-sh/VERT.git
cd VERT
npm install
npm run build

L’output si trova in build/. È un sito statico completamente autonomo.

Step 2: Crea un Bucket S3

#

aws s3 mb s3://my-vert-instance --region eu-central-1

# Blocca tutto l'accesso pubblico — CloudFront è l'unico punto di ingresso
aws s3api put-public-access-block \
  --bucket my-vert-instance \
  --public-access-block-configuration \
  "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Step 3: Carica la Build

#

# Asset hashati: cache per sempre
aws s3 sync build/ s3://my-vert-instance/ \
  --delete \
  --cache-control "public, max-age=31536000, immutable"

# Entry point: rivalidare sempre
aws s3 cp build/index.html s3://my-vert-instance/index.html \
  --cache-control "public, max-age=0, must-revalidate"

Step 4: Distribuzione CloudFront

#

Crea un OAC in modo che CloudFront possa leggere dal bucket S3 privato, poi crea la distribuzione:

{
  "Origins": {
    "Items": [{
      "Id": "s3-vert",
      "DomainName": "my-vert-instance.s3.eu-central-1.amazonaws.com",
      "S3OriginConfig": { "OriginAccessIdentity": "" },
      "OriginAccessControlId": "<OAC_ID>"
    }]
  },
  "DefaultCacheBehavior": {
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
    "Compress": true
  },
  "CustomErrorResponses": {
    "Items": [{
      "ErrorCode": 403,
      "ResponsePagePath": "/index.html",
      "ResponseCode": "200"
    }]
  },
  "DefaultRootObject": "index.html"
}

Riepilogo Costi

#

Perché Questo Pattern Funziona

#

Il motivo per cui il costo è zero è lo stesso motivo per cui WASM rende possibile VERT: tutto il calcolo è spostato al client. Il server (CloudFront + S3) deve solo servire byte statici una volta. Dopo il primo caricamento, il browser mette in cache i moduli WASM aggressivamente.

Un convertitore di file tradizionale richiederebbe una flotta di istanze worker che elaborano upload 24/7. Con WASM, il costo dell’infrastruttura collassa a “archivia e distribuisci file statici” — che AWS essenzialmente regala a scala personale.