After a lot of tries I'm surrendering and asking this
this is my serverless.yml
console: true
service: notifications
frameworkVersion: '3'
useDotenv: true
plugins:
- serverless-offline
- serverless-dotenv-plugin
- serverless-plugin-typescript
- serverless-middleware
custom:
middleware:
folderName: middleware # defaults to '.middleware'
cleanFolder: false # defaults to 'true'
provider:
name: aws
runtime: nodejs14.x
versionFunctions: false
region: ${opt:region, 'sa-east-1'}
functions:
findAllLeads:
handler: src/server.findAllLeads
events:
- http:
path: leads
method: get
cors: true # <-- CORS!
findLead:
handler: src/server.findLead
middleware:
pre:
- middleware/middleware.myF
events:
- http:
path: leads/{id}
method: get
cors:
origin: "*"
createLead:
handler: src/server.createLead
middleware:
pre:
- middleware/middleware.myF
events:
- http:
path: leads
method: post
cors: true # <-- CORS!
and my project strcucture is something like
middleware/
middleware.ts
src/
servers.ts // with handlers
and my middleware.ts is
// export const middleware = (event: any) => {
// console.log(event.body);
// };
export const myF = (event) => {
// will do some logic if I make it work
console.log(event.body);
};
and ALL im getting is
{"message": "Internal server error"}
as a response and in the logs
Does anyone know how to fix this?
Related
I'm trying to execute lambda in go
using serverless offline (SLS_DEBUG=* sls offline --stage dev --printOutput --useDocker )
even running it seems that my Router function in lambda.start isn't being called.
The "main working" was showed, but not the "Request info".
And this message appears in serverless log:
Here is my main.go:
package main
import (
"context"
"database/sql"
"os"
"net/http"
"saws/database"
"github.com/joho/godotenv"
"github.com/sirupsen/logrus"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
type Response events.APIGatewayProxyResponse
type Request events.APIGatewayProxyRequest
type Ctx context.Context
func Router(ctx Ctx, req Request) (Response, error) {
logrus.Error("Request info")
logrus.Error(req)
if req.Path == "/settings" {
if req.HTTPMethod == "GET" {
return HandleGetSettings(req, ctx)
}
if req.HTTPMethod == "POST" {
return HandleSetSettings(req, ctx)
}
}
return Response{
StatusCode: http.StatusMethodNotAllowed,
Body: http.StatusText(http.StatusMethodNotAllowed),
}, nil
}
func main() {
logrus.Error("main working")
lambda.Start(Router)
}
And here is my serverless.yml:
service: sss
frameworkVersion: '>=2.0.0'
variablesResolutionMode: 20210326
configValidationMode: error
provider:
name: aws
runtime: go1.x
region: us-east-2
profile: saws
versionFunctions: false
stage: ${opt:stage,'dev'}
timeout: 30
lambdaHashingVersion: 20201221
apiGateway:
shouldStartNameWithService: true
apiKeys:
- ${self:provider.stage}-${self:service}-apikey
custom:
stages:
- dev
- prod
package:
individually: true
patterns:
- '!./**'
functions:
sync_saws:
handler: bin/main
package:
patterns:
- './bin/main'
events:
- http:
path: /settings
method: any
integration: lambda
plugins:
- serverless-stage-manager
- serverless-offline
How to solve that??
I'm new to AWS and attempting to build an API for a basic course scheduling app. I am currently able to get the API running locally and able to invoke two functions. Function 1 is executing properly, but function 2 seems to be executing the code from function 1. Here is how I have my SAM app structured:
- sam-app
| - events
| - tests
| - src
| - api
| - course
| - AddCourse Lambda
| app.js (Index Lambda, the default hello world sample function, mostly just using to check that API is up)
The Index Lambda at app.js does a GET / and returns status code 200 and body with message "Hello World!" so long as the API is reachable.
The AddCourse Lambda is supposed to do the following via POST /courses:
try {
console.log("Adding a new item...");
await docClient.put(params).promise();
response = {
'statusCode': 200,
'headers': {
'Content-Type': "application/json"
},
'body': JSON.stringify({
message: 'Successfully created item!'
})
}
} catch (err) {
console.error(err);
response = {
'statusCode': 400,
'headers': {
'Content-Type': "application/json"
},
'body': JSON.stringify(err)
}
}
Instead, it is returning status code 200 and body with message "Hello World!".
My template.yml seems to have the correct routes specified too:
Resources:
Index:
Type: AWS::Serverless::Function
Properties:
CodeUri: src
Handler: app.handler
Runtime: nodejs14.x
Policies: AmazonDynamoDBReadOnlyAccess
PackageType: Image
Events:
GetEvent:
Type: Api
Properties:
Path: /
Method: get
Metadata:
DockerTag: nodejs14.x-v1
DockerContext: ./src
Dockerfile: Dockerfile
AddCourse:
Type: AWS::Serverless::Function
Properties:
CodeUri: src/api/course/Course-POST-CreateNewCourse
Handler: index.lambdaHandler
Runtime: nodejs14.x
Policies: AmazonDynamoDBFullAccess
PackageType: Image
Events:
GetEvent:
Type: Api
Properties:
Path: /courses
Method: post
Metadata:
DockerTag: nodejs14.x-v1
DockerContext: ./src
Dockerfile: Dockerfile
What could possibly be going on here? Is there something inherently wrong with how I structured my app?
I am using serverless framework to deploy a graphql nodejs package to lambda function.
My current serverless.yml file involves with a POST method for all communication and also another one for playground which looks like below.
functions:
graphql:
handler: handler.server
events:
- http:
path: /
method: post
cors: true
playground:
handler: handler.playground
events:
- http:
path: /
method: get
cors: true
And my handler.ts looks like this.
const { GraphQLServerLambda } = require("graphql-yoga");
const {documentSubmissionMutation} = require('./mutations/documentMutation');
const {signUpMutation, whatever} = require('./mutations/signUpMutation');
const typeDefs = `
type Query {
hello(name: String): String!
},
type Mutation {
signUp(
email: String!
password: String!
): String
sendDocuments(
user_id: String!
documents: String!
): String!
}
`
const resolvers = {
Query : {
hello : whatever
},
Mutation: {
sendDocuments: documentSubmissionMutation,
signUp: signUpMutation,
}
}
const lambda = new GraphQLServerLambda({
typeDefs,
resolvers
});
exports.server = lambda.graphqlHandler;
exports.playground = lambda.playgroundHandler;
What I would like to do now is have 3 different paths.
1 for secure and 1 for public and 1 for admin.
So basically the URL would be something like.
localhost/public localhost/secre localhost/admin
The secure path will use aws cognito pool to identify the API user api and and the other one would be open. The admin will use another aws cognito admin pool.
So first what I did was add it like this for a secure one.
const lambda = new GraphQLServerLambda({
typeDefs,
resolvers,
context: req => ({ ...req })
});
const lambdaSecure = new GraphQLServerLambda({
typeDefsSecure,
resolversSecure,
context: req => ({ ...req })
});
exports.server = lambda.graphqlHandler;
exports.playground = lambda.playgroundHandler;
exports.serverSecure = lambdaSecure.graphqlHandler;
exports.playgroundSecure = lambdaSecure.playgroundHandler;
Then in my serverless.yml file tried to put it like this.
functions:
graphql:
handler: handler.server
events:
- http:
path: /
method: post
cors: true
graphql:
handler: handler.serverSecure
events:
- http:
path: /
method: post
cors: true
playground:
handler: handler.playground
events:
- http:
path: /
method: get
cors: true
playground:
handler: handler.playgroundSecure
events:
- http:
path: /
method: get
cors: true
It din't work and threw an error
duplicated mapping key in "/Users/nihit/Desktop/serverless/cvtre/serverless.yml" at line 50, column -135:
graphql:
I tried it in different ways but I am not really sure which one is the right way to get two different URL paths.
The problem appears to be in your serverless.yml. In particular in the functions specification. The combination of path and method as well as the function name must be unique for each function.
So, the serverless.yml should look like:
functions:
graphqlServer:
handler: handler.server
events:
- http:
path: server/public
method: post
cors: true
graphqlServerSecure:
handler: handler.serverSecure
events:
- http:
path: server/secure
method: post
cors: true
playground:
handler: handler.playground
events:
- http:
path: playground/public
method: get
cors: true
playgroundSecure:
handler: handler.playgroundSecure
events:
- http:
path: playground/secure
method: get
cors: true
I am using serverless framework for the backend. How can I implement request validation? (do not want to write validation inside lambda functions).
To implement request validation using serverless you need to do a couple of things:
Include your model/header definitions in your stack, and then tell API gateway to use them for request validation.
You'll need to install the following packages:
serverless-aws-documentation
serverless-reqvalidator-plugin
And then you'll need to include them in your serverless.yml:
plugins:
- serverless-reqvalidator-plugin
- serverless-aws-documentation
Note: below is only a quick run-down of how to incorporate the packages. Visit the packages' documentation pages for more comprehensive examples...
Provide API gateway with a description of your models / headers.
You can import json schemas for your models, and declare http headers using the serverless-aws-documentation plugin.
Here's how you'd add a model to your serverless.yml:
custom:
documentation:
api:
info:
version: v0.0.0
title: Some API title
description: Some API description
models:
- name: SomeLambdaRequest
contentType: application/json
schema: ${file(models/SomeLambdaRequest.json)} # reference to your model's json schema file. You can also declare the model inline.
And here's how you'd reference the model in your lambda definition:
functions:
someLambda:
handler: src/someLambda.handler
events:
- http:
# ... snip ...
documentation:
summary: some summary
description: some description
requestBody:
description: some description
requestModels:
application/json: SomeLambdaRequest
You can also declare request headers against your lambda definition like so:
functions:
someLambda:
handler: src/someLambda.handler
events:
- http:
# ... snip ...
documentation:
summary: some summary
description: some description
requestHeaders:
- name: x-some-header
description: some header value
required: true # true or false
- name: x-another-header
description: some header value
required: false # true or false
Tell API gateway to actually use the models for validation
This part makes use of the serverless-reqvalidator-plugin package, and you need to add AWS::ApiGateway::RequestValidator resources to your serverless.yml file.
You can specify whether you want to validate request body, request headers, or both.
resources:
Resources:
onlyBody:
Type: AWS::ApiGateway::RequestValidator
Properties:
Name: 'only-body'
RestApiId:
Ref: ApiGatewayRestApi
ValidateRequestBody: true # true or false
ValidateRequestParameters: false # true or false
And then on individual functions you can make use of the validator like so:
functions:
someLambda:
handler: src/someLambda.handler
events:
- http:
# ... snip ...
reqValidatorName: onlyBody # reference and use the 'only-body' request validator
Put all together your lambda definition would end up looking a little like this:
functions:
someLambda:
handler: src/someLambda.handler
events:
- http:
# ... snip ...
reqValidatorName: onlyBody # reference and use the 'only-body' request validator
documentation:
summary: some summary
description: some description
requestBody:
description: some description
requestModels:
application/json: SomeLambdaRequest
requestHeaders:
- name: x-some-header
description: some header value
required: true # true or false
- name: x-another-header
description: some header value
required: false # true or false
This is now supported by Serverless framework, so there is no need to use external plugins.
To enable requests validation one need is to add the following to the serverless.yml:
HttpHandler:
handler: src/lambda/http/create.handler
events:
- http:
method: post
path: items
request:
schemas:
application/json: ${file(models/create-todo-model.json)}
Instead of keeping the file location directly under application/json you can also keep the name of the model after defining it under serverless.yml file's apiGateway section. link to documentation
Kindly note that, as of Feb-2022, serverless-offline plugin is not validating the http.request.schemas in your local. Though they are supporting deprecated version http.request.schema.
As Ivan indicated, there is no need for external plugins as this is supported by the Serverless framework. However, I think the way to configure this has changed.
functions:
create:
handler: posts.create
events:
- http:
path: posts/create
method: post
request:
schema:
application/json: ${file(create_request.json)}
This example was taken from:
https://www.serverless.com/framework/docs/providers/aws/events/apigateway/#request-schema-validators
In case you are like me and you don't want to add plugins as suggested in "https://stackoverflow.com/questions/49133294/request-validation-using-serverless-framework".
If you set parameters as required and want to validate them, you must add a request validator to your serverless.yml
Resources:
ParameterRequestValidator:
Type: AWS::ApiGateway::RequestValidator
Properties:
Name: ParameterRequestValidator
RestApiId:
Ref: ApiGatewayRestApi
ValidateRequestBody: false
ValidateRequestParameters: true
ApiGatewayMethodNameOfYourApiLookItUpInYourTemplate:
Properties:
RequestValidatorId:
Ref: ParameterRequestValidator
The method you want to validate will be named something like ApiGateway<Method><Get | Post | Patch | Put | Delete >:. You can look the name up when you package your serverless functions in the created template files.
Courtesy for this solutions goes to https://github.com/serverless/serverless/issues/5034#issuecomment-581832806
Request validation using serverless
plugins:
- serverless-python-requirements
- serverless-wsgi
- serverless-reqvalidator-plugin
- serverless-aws-documentation
provider:
name: aws
runtime: python3.8
region: us-east-1
functions:
hello:
handler: handler.hello
events:
- http:
path: /
method: get
likes:
handler: handler.likes
events:
- http:
path: /likes
method: get
integration: lambda
reqValidatorName: xMyRequestValidator
request:
passThrough: NEVER
parameters:
querystrings:
userid: true
activityid: true
template:
application/json: '{ "userid":"$input.params(''userid'')","activityid":"$input.params(''activityid'')"}'
response:
headers:
Content-Type: "'application/json'"
custom:
wsgi:
app: handler.app
pythonBin: python # Some systems with Python3 may require this
packRequirements: false
pythonRequirements:
dockerizePip: non-linux
resources:
Resources:
xMyRequestValidator:
Type: "AWS::ApiGateway::RequestValidator"
Properties:
Name: 'my-req-validator'
RestApiId:
Ref: ApiGatewayRestApi
ValidateRequestBody: true
ValidateRequestParameters: true
So I'm trying to run a lambda on amazon and narrowed down the error finally by testing the lambda in amazons testing console.
The error I got is this.
{
"errorMessage": "Please install mysql2 package manually",
"errorType": "Error",
"stackTrace": [
"new MysqlDialect (/var/task/node_modules/sequelize/lib/dialects/mysql/index.js:14:30)",
"new Sequelize (/var/task/node_modules/sequelize/lib/sequelize.js:234:20)",
"Object.exports.getSequelizeConnection (/var/task/src/twilio/twilio.js:858:20)",
"Object.<anonymous> (/var/task/src/twilio/twilio.js:679:25)",
"__webpack_require__ (/var/task/src/twilio/twilio.js:20:30)",
"/var/task/src/twilio/twilio.js:63:18",
"Object.<anonymous> (/var/task/src/twilio/twilio.js:66:10)",
"Module._compile (module.js:570:32)",
"Object.Module._extensions..js (module.js:579:10)",
"Module.load (module.js:487:32)",
"tryModuleLoad (module.js:446:12)",
"Function.Module._load (module.js:438:3)",
"Module.require (module.js:497:17)",
"require (internal/module.js:20:19)"
]
}
Easy enough, so I have to install mysql2. So I added it to my package.json file.
{
"name": "test-api",
"version": "1.0.0",
"description": "",
"main": "handler.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 0"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"aws-sdk": "^2.153.0",
"babel-core": "^6.26.0",
"babel-loader": "^7.1.2",
"babel-plugin-transform-runtime": "^6.23.0",
"babel-preset-es2015": "^6.24.1",
"babel-preset-stage-3": "^6.24.1",
"serverless-domain-manager": "^1.1.20",
"serverless-dynamodb-autoscaling": "^0.6.2",
"serverless-webpack": "^4.0.0",
"webpack": "^3.8.1",
"webpack-node-externals": "^1.6.0"
},
"dependencies": {
"babel-runtime": "^6.26.0",
"mailgun-js": "^0.13.1",
"minimist": "^1.2.0",
"mysql": "^2.15.0",
"mysql2": "^1.5.1",
"qs": "^6.5.1",
"sequelize": "^4.31.2",
"serverless": "^1.26.0",
"serverless-plugin-scripts": "^1.0.2",
"twilio": "^3.10.0",
"uuid": "^3.1.0"
}
}
I noticed when I do sls deploy however, it seems to only be packaging some of the modules?
Serverless: Package lock found - Using locked versions
Serverless: Packing external modules: babel-runtime#^6.26.0, twilio#^3.10.0, qs#^6.5.1, mailgun-js#^0.13.1, sequelize#^4.31.2, minimi
st#^1.2.0, uuid#^3.1.0
Serverless: Packaging service...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
................................
Serverless: Stack update finished...
I think this is why it's not working. In short, how do I get mysql2 library to be packaged correctly with serverless so my lambda function will work with the sequelize library?
Please note that when I test locally my code works fine.
My serverless file is below
service: testapi
# Use serverless-webpack plugin to transpile ES6/ES7
plugins:
- serverless-webpack
- serverless-plugin-scripts
# - serverless-domain-manager
custom:
#Define the Stage or default to Staging.
stage: ${opt:stage, self:provider.stage}
webpackIncludeModules: true
#Define Databases Here
databaseName: "${self:service}-${self:custom.stage}"
#Define Bucket Names Here
uploadBucket: "${self:service}-uploads-${self:custom.stage}"
#Custom Script setup
scripts:
hooks:
#Script below will run schema changes to the database as neccesary and update according to stage.
'deploy:finalize': node database-schema-update.js --stage ${self:custom.stage}
#Domain Setup
# customDomain:
# basePath: "/"
# domainName: "api-${self:custom.stage}.test.com"
# stage: "${self:custom.stage}"
# certificateName: "*.test.com"
# createRoute53Record: true
provider:
name: aws
runtime: nodejs6.10
stage: staging
region: us-east-1
environment:
DOMAIN_NAME: "api-${self:custom.stage}.test.com"
DATABASE_NAME: ${self:custom.databaseName}
DATABASE_USERNAME: ${env:RDS_USERNAME}
DATABASE_PASSWORD: ${env:RDS_PASSWORD}
UPLOAD_BUCKET: ${self:custom.uploadBucket}
TWILIO_ACCOUNT_SID: ""
TWILIO_AUTH_TOKEN: ""
USER_POOL_ID: ""
APP_CLIENT_ID: ""
REGION: "us-east-1"
IDENTITY_POOL_ID: ""
RACKSPACE_API_KEY: ""
#Below controls permissions for lambda functions.
iamRoleStatements:
- Effect: Allow
Action:
- dynamodb:DescribeTable
- dynamodb:UpdateTable
- dynamodb:Query
- dynamodb:Scan
- dynamodb:GetItem
- dynamodb:PutItem
- dynamodb:UpdateItem
- dynamodb:DeleteItem
Resource: "arn:aws:dynamodb:us-east-1:*:*"
functions:
create_visit:
handler: src/visits/create.main
events:
- http:
path: visits
method: post
cors: true
authorizer: aws_iam
get_visit:
handler: src/visits/get.main
events:
- http:
path: visits/{id}
method: get
cors: true
authorizer: aws_iam
list_visit:
handler: src/visits/list.main
events:
- http:
path: visits
method: get
cors: true
authorizer: aws_iam
update_visit:
handler: src/visits/update.main
events:
- http:
path: visits/{id}
method: put
cors: true
authorizer: aws_iam
delete_visit:
handler: src/visits/delete.main
events:
- http:
path: visits/{id}
method: delete
cors: true
authorizer: aws_iam
twilio_send_text_message:
handler: src/twilio/twilio.send_text_message
events:
- http:
path: twilio/sendtextmessage
method: post
cors: true
authorizer: aws_iam
#This function handles incoming calls and where to route it to.
twilio_incoming_call:
handler: src/twilio/twilio.incoming_calls
events:
- http:
path: twilio/calls
method: post
twilio_failure:
handler: src/twilio/twilio.twilio_failure
events:
- http:
path: twilio/failure
method: post
twilio_statuschange:
handler: src/twilio/twilio.statuschange
events:
- http:
path: twilio/statuschange
method: post
twilio_incoming_message:
handler: src/twilio/twilio.incoming_message
events:
- http:
path: twilio/messages
method: post
twilio_whisper:
handler: src/twilio/twilio.whisper
events:
- http:
path: twilio/whisper
method: post
- http:
path: twilio/whisper
method: get
twilio_start_call:
handler: src/twilio/twilio.start_call
events:
- http:
path: twilio/startcall
method: post
- http:
path: twilio/startcall
method: get
resources:
Resources:
uploadBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: ${self:custom.uploadBucket}
RDSDatabase:
Type: AWS::RDS::DBInstance
Properties:
Engine : mysql
MasterUsername: ${env:RDS_USERNAME}
MasterUserPassword: ${env:RDS_PASSWORD}
DBInstanceClass : db.t2.micro
AllocatedStorage: '5'
PubliclyAccessible: true
#TODO: The Value of Stage is also available as a TAG automatically which I may use to replace this manually being put here..
Tags:
-
Key: "Name"
Value: ${self:custom.databaseName}
DeletionPolicy: Snapshot
DNSRecordSet:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneName: test.com.
Name: database-${self:custom.stage}.test.com
Type: CNAME
TTL: '300'
ResourceRecords:
- {"Fn::GetAtt": ["RDSDatabase","Endpoint.Address"]}
DependsOn: RDSDatabase
UPDATE:: So I confirmed that running sls package --stage dev seems to create this in the zip folder that would eventually upload to AWS. This confirms that serverless is not creating the package correctly with the mysql2 reference for some reason? Why is this?
webpack config file as requested
const slsw = require("serverless-webpack");
const nodeExternals = require("webpack-node-externals");
module.exports = {
entry: slsw.lib.entries,
target: "node",
// Since 'aws-sdk' is not compatible with webpack,
// we exclude all node dependencies
externals: [nodeExternals()],
// Run babel on all .js files and skip those in node_modules
module: {
rules: [
{
test: /\.js$/,
loader: "babel-loader",
include: __dirname,
exclude: /node_modules/
}
]
}
};
Thanks to dashmugs comment after some investigation on this page (https://github.com/serverless-heaven/serverless-webpack), there is a section on Forced Inclusion. I'll paraphrase it here.
Forced inclusion Sometimes it might happen that you use dynamic
requires in your code, i.e. you require modules that are only known at
runtime. Webpack is not able to detect such externals and the compiled
package will miss the needed dependencies. In such cases you can force
the plugin to include certain modules by setting them in the
forceInclude array property. However the module must appear in your
service's production dependencies in package.json.
# serverless.yml
custom:
webpackIncludeModules:
forceInclude:
- module1
- module2
So I simply did this...
webpackIncludeModules:
forceInclude:
- mysql
- mysql2
Now it works! Hope this helps someone else with the same issue.
None of the previous helped me, I used this solution: https://github.com/sequelize/sequelize/issues/9489#issuecomment-493304014
The trick is to use dialectModule property and override sequelize.
import Sequelize from 'sequelize';
import mysql2 from 'mysql2'; // Needed to fix sequelize issues with WebPack
const sequelize = new Sequelize(
process.env.DB_NAME,
process.env.DB_USER,
process.env.DB_PASSWORD,
{
dialect: 'mysql',
dialectModule: mysql2, // Needed to fix sequelize issues with WebPack
host: process.env.DB_HOST,
port: process.env.DB_PORT
}
)
export async function connectToDatabase() {
console.log('Trying to connect via sequelize')
await sequelize.sync()
await sequelize.authenticate()
console.log('=> Created a new connection.')
// Do something
}
The previous so far works on MySql but is not working with Postgres