Che cos'è un API gateway?

Un API gateway è la porta d’ingresso gestita alle API: un unico punto di accesso che instrada, autentica e applica il rate limiting a ogni richiesta. L’idea è la centralizzazione: il lavoro trasversale di cui ogni endpoint ha bisogno (chi è chi, con che frequenza può chiamare, dove va questa richiesta, che cosa è successo) esce da N servizi e si concentra in un unico livello di policy che i client non possono scavalcare.

Punti chiave

Che cosa fa la porta d’ingresso

La lista dei compiti di un gateway, sotto forma di configurazione invece di N copie di middleware – una tipica route dichiarativa:

# route della gateway: un ingresso, policy allegate
route: /orders/**
  service: orders-api:8080          # routing – la topologia resta privata
  auth: bearer-jwt                  # autenticazione alla porta
  rate_limit: 100/min per key       # budget prima dei backend
  transform:
    strip_headers: [X-Internal-*]   # tradurre tra l'edge e l'interno
  timeout: 5s
  observe: log + trace + metrics    # un unico posto da cui osservare tutto

Dal lato del client, un gateway gestito scompare dentro l’SDK – una sola chiamata, con i controlli della porta applicati prima che venga eseguita una riga di codice applicativo:

// JavaScript / Node.js — Back4app JS SDK
// One managed entry point: auth, rate limits, and routing applied per call
const receipt = await Parse.Cloud.run('placeOrder', { cartId: 'crt_812' });
// The platform's gateway verified the session, applied limits,
// and routed to the function — none of it in your code.
console.log(`Order ${receipt.orderId} confirmed`);

// Flutter / Dart — Back4app Flutter SDK
// One managed entry point: auth, rate limits, and routing applied per call
final function = ParseCloudFunction('placeOrder');
final response = await function.execute(parameters: {'cartId': 'crt_812'});
if (response.success) {
  print('Order ${response.result['orderId']} confirmed');
}

// iOS / Swift — Back4app Swift SDK
// One managed entry point: auth, rate limits, and routing applied per call
ParseCloud.callFunction("placeOrder",
                        parameters: ["cartId": "crt_812"]) { result in
  if case .success(let receipt) = result {
    print("Order confirmed: \(receipt)")
  }
}

// Android / Kotlin — Back4app Android SDK
// One managed entry point: auth, rate limits, and routing applied per call
val params = hashMapOf("cartId" to "crt_812")
ParseCloud.callFunctionInBackground<Map<String, Any>>("placeOrder", params) { receipt, e ->
  if (e == null) Log.d("Orders", "Order ${receipt["orderId"]} confirmed")
}

I quattro sosia, messi in chiaro

La descrizione canonica del pattern aggiunge la variante che vale la pena conoscere: il Backend-for-Frontend – un gateway leggero per tipo di client, ciascuno a modellare le risposte per il proprio – che scambia più unità da fare il deployment con la fine delle API taglia unica che non stanno bene a nessuno.

Gli svantaggi, detti chiaramente

Il gateway centralizza il potere, e la centralizzazione presenta il conto in quattro modi. Single point of failure: tutto gli passa attraverso – va fatto girare in cluster dietro un load balancer, oppure si accetta che il suo disservizio sia il disservizio. Il nuovo collo di bottiglia: ogni team di prodotto deposita ora le proprie modifiche di configurazione su un unico componente condiviso; governance e strumenti self-service fanno parte dell’adozione, non sono accessori. Il monolite resuscitato: la logica di aggregazione che si accumula nel gateway ricostruisce in silenzio l’applicazione centralizzata che si era appena scomposta – conviene tenerlo ricco di policy e povero di logica. La proliferazione della configurazione: centinaia di route con policy per singola route sono una codebase; va riletta come tale. Nessuno di questi punti è un argomento contro i gateway; tutti sono argomenti contro i gateway adottati con leggerezza.

Casi d’uso tipici

• Porta d’ingresso dei microservizi – la storia delle origini: molti servizi, un’unica API coerente, una topologia libera di evolvere dietro di essa.
• Prodotti multi-client – web, mobile e partner con auth, forme e limiti diversi – il terreno di casa del BFF.
• Monetizzazione delle API – chiavi, piani, quote e misurazione dell’uso imposti in un unico punto.
• Migrazioni – lo strangler pattern: il gateway instrada i path vecchi verso il sistema legacy e quelli nuovi verso il suo sostituto, in modo invisibile.
• Policy al bordo – CORS, TLS, igiene degli header e rate limiting applicati una volta sola invece di N.

Serve davvero? Matrice decisionale

La risposta che nessuna pagina di confronto si assume: non ancora è un’architettura legittima. La porta si aggiunge quando dietro c’è un edificio.

Limiti e trade-off

• La disponibilità diventa quella del gateway. Va messo in cluster, sorvegliato con health check e provato nel suo guasto – la contromisura è standard e non opzionale.
• Un salto di latenza, messo onestamente in bilancio con gli andata e ritorno e il middleware duplicato che elimina; conviene misurare, senza dare per scontato né un verso né l’altro.
• L’aggregazione è un piano inclinato. Comporre le risposte è legittimo; la logica di business nel gateway è il pattern ESB con una targhetta nuova.
• Le opzioni open source portano con sé il lavoro operativo. Esistono gateway eccellenti in open source (stack basati su Envoy e simili) – ciascuno è un sistema distribuito che da quel momento va fatto girare, aggiornato e messo in sicurezza.
• I gateway gestiti scambiano controllo con silenzio. La porta gestita dalla piattaforma è la risposta giusta esattamente quando gestire un gateway sarebbe fatica senza valore differenziante.

Il gateway su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il livello gateway arriva con la piattaforma: ogni richiesta – REST, GraphQL, SDK o chiamata a Cloud Code, come nei tab di codice qui sopra – entra da un edge gestito che autentica sessioni e chiavi, applica il rate limiting per singola app e instrada verso le API generate o verso le funzioni scritte a mano, mentre la piattaforma si occupa del clustering e della scalabilità che rendono sicura una porta d’ingresso. La matrice decisionale si semplifica: le garanzie di un gateway ci sono dal primo giorno, senza mai dover presidiare la porta.