Compilazione di funzioni Lambda con Node.js
Puoi eseguire il codice JavaScript con Node.js in AWS Lambda. Lambda fornisce Runtime per Node.js che eseguono il tuo codice per elaborare gli eventi. Il tuo codice viene eseguito in un ambiente che include AWS SDK per JavaScript con le credenziali di un ruolo AWS Identity and Access Management (IAM) gestito. Per ulteriori informazioni sulle versioni SDK incluse nei runtime di Node.js, consulta Versioni SDK incluse nel runtime.
Lambda supporta i seguenti runtime di Node.js.
| Nome | Identificatore | Sistema operativo | Data di ritiro | Blocco creazione funzioni | Blocco aggiornamento funzioni |
|---|---|---|---|---|---|
|
Node.js 22 |
|
Amazon Linux 2023 |
30 aprile 2027 |
1 giugno 2027 |
1 luglio 2027 |
|
Node.js 20 |
|
Amazon Linux 2023 |
30 aprile 2026 |
1 giugno 2026 |
1 luglio 2026 |
Le versioni upstream del linguaggio Node.js abilitano alcune funzionalità sperimentali per impostazione predefinita. Lambda disabilita queste funzionalità per garantire stabilità di runtime e prestazioni costanti. Nella tabella di seguito vengono elencate le funzionalità sperimentali disabilitate da Lambda.
| Funzionalità sperimentali | Versioni di Node.js supportate | Flag Node.js applicato da Lambda | Flag Lambda da riabilitare |
|---|---|---|---|
|
Supporto per l'importazione di moduli utilizzando la richiesta in moduli ES |
Node.js 20 e Node.js 22 |
|
|
|
Supporto per il rilevamento automatico dei moduli ES rispetto a CommonJS |
Node.js 22 |
|
|
Per abilitare una funzionalità sperimentale disabilitata, imposta il flag di riabilitazione nella variabile di ambiente NODE_OPTIONS. Ad esempio, per abilitare la richiesta di supporto del modulo ES, imposta NODE_OPTIONS su --experimental-require-module. Lambda rileva questa sostituzione e rimuove il flag di disabilitazione corrispondente.
Importante
L'utilizzo di funzionalità sperimentali può portare a problemi in termini di instabilità e prestazioni. Queste funzionalità potrebbero essere modificate o rimosse nelle future versioni di Node.js. Le funzioni che utilizzano funzionalità sperimentali non sono idonee per l’Accordo sul livello di servizio (SLA) Lambda Supporto AWS.
Per creare una funzione Node.js.
-
Aprire la console Lambda
. -
Scegli Crea funzione.
-
Configura le impostazioni seguenti:
-
Nome della funzione: inserisci il nome della funzione.
-
Runtime: scegli Node.js 22.x.
-
-
Scegli Crea funzione.
La console crea una funzione Lambda con un singolo file di origine denominato index.mjs. È possibile modificare questo file e aggiungere altri file nell'editor di codice predefinito. Nella sezione DEPLOY, scegli Implementa per aggiornare il codice della tua funzione. Quindi, per eseguire il codice, scegli Crea evento di test nella sezione EVENTI DI TEST.
Il file index.mjs esporta una funzione denominata handler che richiede un oggetto evento e un oggetto contesto. Questa è la funzione del gestore chiamata da Lambda quando la funzione viene richiamata. Il runtime della funzione Node.js riceve gli eventi di chiamata da Lambda e li passa al gestore. Nella configurazione della funzione il valore del gestore è index.handler.
Quando si salva il codice funzione, la console Lambda crea un pacchetto di implementazione dell'archivio di file .zip. Quando sviluppi il codice funzione al di fuori della console (utilizzando un IDE) devi creare un pacchetto di implementazione per caricare il codice nella funzione Lambda.
Il runtime della funzione passa un oggetto contesto al gestore, oltre all'evento di chiamata. L'oggetto contesto contiene ulteriori informazioni sulla chiamata, sulla funzione e sull'ambiente di esecuzione. Altre informazioni sono disponibili con le variabili di ambiente.
La funzione Lambda include un gruppo di log CloudWatch Logs. Il runtime della funzione invia i dettagli su ogni chiamata ai CloudWatch Logs. Si trasmette qualsiasi log che la tua funzione emette durante la chiamata. Se la funzione restituisce un errore, Lambda formatta l'errore e lo restituisce al chiamante.
Argomenti
Inizializzazione di Node.js
Node.js ha un modello di ciclo di eventi univoco che fa sì che il suo comportamento di inizializzazione sia diverso dagli altri tempi di esecuzione. In particolare, Node.js utilizza un modello di I/O senza blocchi che supporta operazioni asincrone. Questo modello consente a Node.js di funzionare in modo efficiente per la maggior parte dei carichi di lavoro. Ad esempio, se una funzione Node.js effettua una chiamata di rete, tale richiesta può essere designata come operazione asincrona e inserita in una coda di callback. La funzione può continuare a elaborare altre operazioni all'interno dello stack di chiamate principale senza essere bloccata in attesa che la chiamata di rete sia restituita. Una volta completata la chiamata di rete, viene eseguita la richiamata e quindi rimossa dalla coda di richiamata.
Alcune attività di inizializzazione possono essere eseguite in modo asincrono. L'esecuzione di queste attività asincrone potrebbe non essere completata prima di una chiamata. Ad esempio, il codice che effettua una chiamata di rete per recuperare un parametro da Parameter Store AWS potrebbe non essere completato quando Lambda esegue la funzione di gestore. Di conseguenza, la variabile potrebbe essere null durante una chiamata. Inoltre, può verificarsi un ritardo tra INIT e INVOKE che può causare errori nelle operazioni urgenti. In particolare, le chiamate di servizio AWS possono basarsi su firme di richieste urgenti, con conseguenti errori nelle chiamate di servizio se la chiamata non viene completata durante la fase INIT.
Per evitare tale situazione, consigliamo di implementare il codice come modulo ECMAScript (modulo ES) e di utilizzare await di livello superiore per garantire che l'inizializzazione sia interamente completata durante la fase INIT della funzione. Ciò garantisce il completamento delle attività di inizializzazione prima delle invocazioni del gestore, evita ritardi tra INIT e INVOKE che interrompono operazioni urgenti e massimizza inoltre l'efficacia della simultaneità fornita nel ridurre la latenza di avvio a freddo. Per ulteriori informazioni e un esempio, consulta Utilizzo di moduli ES Node.js e attesa di primo livello in AWS Lambda
Impostazione di un gestore di funzioni come modulo ES
Per impostazione predefinita, Lambda tratta i file con il suffisso .js come moduli CommonJS. Facoltativamente, puoi designare il tuo codice come modulo ES. Ciò è possibile in due modi: specificando il type come module nel file package.json della funzione o utilizzando l'estensione del nome file .mjs. Nel primo scenario, il codice funzione tratta tutti i file .js come moduli ES, mentre nel secondo scenario solo il file specificato con .mjs è un modulo ES. È possibile combinare moduli ES e moduli CommonJS chiamandoli rispettivamente .mjs e .cjs, poiché i file .mjssono sempre moduli ES e i file .cjs sono sempre moduli CommonJS.
Lambda cerca le cartelle nella variabile d'ambiente NODE_PATH durante il caricamento dei moduli ES. Puoi caricare l'SDK AWS incluso nel runtime utilizzando le istruzioni import del modulo ES. È inoltre possibile caricare i moduli ES dai livelli.
Versioni SDK incluse nel runtime
Tutti i runtime Lambda Node.js supportati includono una versione secondaria specifica di AWS SDK per JavaScript v3, non la versione più recente
Esempio index.mjs
import packageJson from '@aws-sdk/client-s3/package.json' with { type: 'json' }; export const handler = async () => ({ version: packageJson.version });
Restituisce una risposta nel seguente formato:
{ "version": "3.632.0" }
Per ulteriori informazioni, consulta Utilizzo dell'SDK per JavaScript v3 nel gestore.
Utilizzo di keep-alive per le connessioni TCP
L'agente HTTP/HTTPS Node.js predefinito crea una nuova connessione TCP per ogni nuova richiesta. Per evitare il costo della creazione di nuove connessioni, il keep-alive è abilitato per impostazione predefinita in tutti i runtime Node.js supportati. Il keep-alive può ridurre i tempi di richiesta per le funzioni Lambda che effettuano più chiamate API utilizzando l'SDK.
Per disabilitare il keep-alive, consulta Riutilizzo delle connessioni con keep-alive in Node.js nella Guida per gli sviluppatori di SDK AWS per JavaScript 3.x. Per ulteriori informazioni sull'utilizzo del keep-alive, consulta Keep-alive HTTP attivo per impostazione predefinita nell'SDK AWS modulare per JavaScript
Caricamento di certificati CA
Per le versioni di runtime di Node.js fino a Node.js 18, Lambda carica automaticamente i certificati CA (autorità di certificazione) specifici di Amazon per semplificare la creazione di funzioni che interagiscono con altri Servizi AWS. Ad esempio, Lambda include i certificati Amazon RDS necessari per convalidare il certificato di identità del server installato sul tuo database Amazon RDS. Questo comportamento può avere un impatto sulle prestazioni durante gli avvii a freddo.
A partire da Node.js 20, Lambda non carica più certificati CA aggiuntivi per impostazione predefinita. Il runtime Node.js 20 contiene un file di certificato con tutti i certificati Amazon CA nella posizione /var/runtime/ca-cert.pem. Per ripristinare lo stesso comportamento da Node.js 18 e runtime precedenti, imposta la variabile di ambiente NODE_EXTRA_CA_CERTS su /var/runtime/ca-cert.pem.
Per prestazioni ottimali, consigliamo di raggruppare nel pacchetto di implementazione solo i certificati necessari e di caricarli tramite la variabile di ambiente NODE_EXTRA_CA_CERTS. Il file dei certificati deve essere composto da uno o più certificati CA root o intermedi affidabili in formato PEM. Ad esempio, per RDS, includi i certificati richiesti insieme al codice come certificates/rds.pem. Quindi, carica i certificati impostando NODE_EXTRA_CA_CERTS su /var/task/certificates/rds.pem.