serverless express
v4.16.0
Ein neues Softwareprojekt starten? Schauen Sie sich den Code Genie an - einen vollständigen Stack -App -Generator, der ein komplettes AWS -serverloser Projekt mit Quellcode basierend auf Ihrem Datenmodell liefert. Einschließlich:
Führen Sie REST -APIs und andere Webanwendungen mit Ihrem vorhandenen Node.js -Anwendungs -Framework (Express, KOA, HAPI, Segel usw.) über AWS Lambda und Amazon API -Gateway oder Azure -Funktion aus.
npm install @codegenie/serverless-expressWillst du schnell aufstehen? Schauen Sie sich unser grundlegendes Starterbeispiel an, das enthält:
Wenn Sie eine vorhandene Anwendung auf AWS Lambda migrieren möchten, wird empfohlen, das minimale Beispiel zuerst in Betrieb zu nehmen und dann Ihre Anwendungsquelle zu kopieren.
Der einzige AWS Lambda -spezifische Code, den Sie schreiben müssen, ist ein einfacher Handler wie unten. Alle anderen Code, die Sie wie gewohnt schreiben können.
// lambda.js
const serverlessExpress = require ( '@codegenie/serverless-express' )
const app = require ( './app' )
exports . handler = serverlessExpress ( { app } )Wenn Ihre Anwendung einige gemeinsame Bootstrap -Aufgaben ausführen muss, z. B. eine Verbindung zu einer Datenbank, bevor die Anforderung an die API weitergeleitet wird, können Sie das folgende Muster verwenden (auch in diesem Beispiel verfügbar):
// lambda.js
require ( 'source-map-support/register' )
const serverlessExpress = require ( '@codegenie/serverless-express' )
const app = require ( './app' )
let serverlessExpressInstance
function asyncTask ( ) {
return new Promise ( ( resolve ) => {
setTimeout ( ( ) => resolve ( 'connected to database' ) , 1000 )
} )
}
async function setup ( event , context ) {
const asyncValue = await asyncTask ( )
console . log ( asyncValue )
serverlessExpressInstance = serverlessExpress ( { app } )
return serverlessExpressInstance ( event , context )
}
function handler ( event , context ) {
if ( serverlessExpressInstance ) return serverlessExpressInstance ( event , context )
return setup ( event , context )
}
exports . handler = handler Der einzige Azure -Funktionscode, den Sie schreiben müssen, ist ein einfacher index.js und eine function.json wie unten.
// index.js
const serverlessExpress = require ( '@codegenie/serverless-express' )
const app = require ( './app' )
const cachedServerlessExpress = serverlessExpress ( { app } )
module . exports = async function ( context , req ) {
return cachedServerlessExpress ( context , req )
} Der überzeugende Parameter "name": "$return" ist für serverless Express wichtig.
// function.json
{
"bindings" : [
{
"authLevel" : " anonymous " ,
"type" : " httpTrigger " ,
"direction" : " in " ,
"name" : " req " ,
"route" : " {*segments} "
},
{
"type" : " http " ,
"direction" : " out " ,
"name" : " $return "
}
]
}resolutionMode angeben, um "CONTEXT" oder "CALLBACK" zu verwendenisBase64Encoded ohne Angabe von binaryMimeTypes . Verwenden Sie binarySettings zum Anpassen. Vielen Dank an @dougmoscrop von https://github.com/dougmoscrop/serverless-httprespondWithErrors erleichtert das Debuggen während der Entwicklung leichterSiehe upgrade.md zum Upgrade von AWS-Serverless-Express und @CodeGenie/Serverless-Express 3.x
Stellen Sie fest, ob die Antwort Basis64 codiert werden sollte, bevor sie an die Ereignisquelle zurückgegeben werden, beispielsweise bei der Rückgabe von Bildern oder komprimierten Dateien. Dies ist erforderlich, da das API -Gateway und andere Ereignisquellen, die nicht in der Lage sind, binäre Antworten direkt zu behandeln. Die Ereignisquelle ist dann dafür verantwortlich, dies in ein binäres Format umzuwandeln, bevor er an den Kunden zurückgegeben wird.
Standardmäßig wird dies basierend auf den von Ihrer Anwendung zurückgegebenen content-encoding und content-type Headern ermittelt. Wenn Sie eine zusätzliche Kontrolle darüber benötigen, können Sie binarySettings angeben.
{
binarySettings : {
isBinary : ( { headers } ) => true ,
contentTypes : [ 'image/*' ] ,
contentEncodings : [ ]
}
}Jeder Wert, den Sie hier bereitstellen, sollte auch auf der API -Gateway -API angegeben werden. In Sam sieht das aus wie:
ExpressApi :
Type : AWS::Serverless::Api
Properties :
StageName : prod
BinaryMediaTypes : ['image/*']'PROMISE' ) Lambda unterstützt drei Methoden, um die Ausführung zu beenden und ein Ergebnis zurückzugeben: Kontext, Rückruf und Versprechen. Standardlos verwendet Serverless-Express eine Versprechen-Auflösung. Sie können jedoch einen "Kontext" oder "Rückruf" angeben, wenn Sie dies ändern müssen. Wenn Sie "Rückruf" angeben, ist auch context.callbackWaitsForEmptyEventLoop = false für Sie festgelegt.
serverlessExpress ( {
app ,
resolutionMode : 'CALLBACK'
} )process.env.NODE_ENV === 'development' ) Legen Sie dies auf true ein, um serverless-express zu haben, um die Fehlerstapelverfolgung im Falle einer ungehandelten Ausnahme einzuschließen. Dies ist besonders nützlich während der Entwicklung. Standardmäßig ist dies aktiviert, wenn NODE_ENV === 'development' sodass die Stapelspur nicht in der Produktion zurückgegeben wird.
Serverless-Express unterstützt das API-Gateway, ALB und Lambda@Edge nativ. Wenn Sie Express mit anderen in Lambda integrierten AWS -Diensten verwenden möchten, können Sie Ihre eigenen benutzerdefinierten Anforderungs-/Antwort -Zuordnungen über eventSource vorlegen. Siehe Beispiel für maßgeschneiderte Dynamodb.
function requestMapper ( { event } ) {
// Your logic here...
return {
method ,
path ,
headers
}
}
function responseMapper ( {
statusCode ,
body ,
headers ,
isBase64Encoded
} ) {
// Your logic here...
return {
statusCode ,
body ,
headers ,
isBase64Encoded
}
}
serverlessExpress ( {
app ,
eventSource : {
getRequest : requestMapper ,
getResponse : responseMapper
}
} ) Eine einzelne Funktion kann so konfiguriert werden, dass zusätzliche Arten von AWS -Ereignissen verarbeitet werden:
Unter der Annahme der folgenden Funktionskonfiguration in serverless.yml :
functions :
lambda-handler :
handler : src/lambda.handler
events :
- http :
path : /
method : get
- sns :
topicName : my-topic
- stream :
type : dynamodb
arn : arn:aws:dynamodb:us-east-1:012345678990:table/my-table/stream/2021-07-15T15:05:51.683
- sqs :
arn : arn:aws:sqs:us-east-1:012345678990:myQueue
- eventBridge :
pattern :
source :
- aws.cloudformationUnd die folgende Konfiguration:
serverlessExpress ( {
app ,
eventSourceRoutes : {
'AWS_SNS' : '/sns' ,
'AWS_DYNAMODB' : '/dynamodb' ,
'AWS_SQS' : '/sqs'
'AWS_EVENTBRIDGE' : '/eventbridge' ,
'AWS_KINESIS_DATA_STREAM' : '/kinesis' ,
'AWS_S3' : '/s3' ,
'AWS_STEP_FUNCTIONS' : '/step-functions' ,
'AWS_SELF_MANAGED_KAFKA' : '/self-managed-kafka' ,
}
} )Alternativ, um nur SNS -Ereignisse zu verarbeiten (die Schlüssel in der Karte sind optional )
serverlessExpress ( {
app ,
eventSourceRoutes : {
'AWS_SNS' : '/sns' ,
}
} ) Die Ereignisse POST die konfigurierten Routen.
Um sicherzustellen, dass die Ereignisse aus einem internen Ereignis ausbreitet und nicht extern, wird dringend empfohlen , um sicherzustellen, dass die Host -Header -Übereinstimmungen:
sns.amazonaws.comdynamodb.amazonaws.comsqs.amazonaws.comevents.amazonaws.comkinesis.amazonaws.com Geben Sie Protokolleinstellungen an, die an den Standardprotokoll übergeben werden. Derzeit können Sie nur die level festlegen.
{
logSettings : {
level : 'debug' // default: 'error'
}
} Geben Sie ein benutzerdefiniertes log mit info , debug und error an. Sie können beispielsweise die Standardeinstellung mit einer Winston -Protokollinstanz überschreiben.
{
log : {
info ( message , additional ) {
console . info ( message , additional )
} ,
debug ( message , additional ) {
console . debug ( message , additional )
} ,
error ( message , additional ) {
console . error ( message , additional )
}
}
} Dieses Paket enthält eine Funktion, mit der die event und context , die Lambda von der Ereignisquelle empfängt.
const { getCurrentInvoke } = require ( '@codegenie/serverless-express' )
app . get ( '/' , ( req , res ) => {
const { event , context } = getCurrentInvoke ( )
res . json ( event )
} ) npx loadtest --rps 100 -k -n 1500 -c 50 https://xxxx.execute-api.us-east-1.amazonaws.com/prod/users
Am 30.11. Die AWS Serverless Express Library hat sich von AWS zu Vendia verschoben und wird in @codegenie/serverless-express umbenannt. In ähnlicher Weise wird das aws-serverless-express NPM-Paket zugunsten von @codeGenie/Serverless-Express veraltet.
Brett Andrews, der ursprüngliche Ersteller der serverlosen Express -Bibliothek, wird das Repository weiterhin pflegen und ihm die Aufmerksamkeit und die Pflege geben, die es verdient. Gleichzeitig werden wir nach zusätzlichen Mitwirkenden suchen, um an der Entwicklung und Verwaltung der serverlosen Express -Bibliothek teilzunehmen. AWS und das SAM -Team werden neben Vendia, Brett und den neuen Betreuern, die sich dem Projekt anschließen, in eine administrative Rolle verwickelt werden.
Wir glauben, dass dies die beste Vorgehensweise ist, um sicherzustellen, dass Kunden, die diese Bibliothek nutzen, in Zukunft die bestmögliche Unterstützung erhalten. Um mehr über diesen Schritt zu erfahren oder ein Betreuer der neuen serverlosen Express -Bibliothek zu werden, wenden Sie sich über ein Github -Problem in diesem Repository.
Am besten, das AWS Serverless Team, Brett & das Vendia -Team
