As I wrote in AWS CloudFormation Articles, AWS Lambda and API Gateway are managed in Serverless.
Here is a poem about how we got there and a brief explanation of how to use Serverless.
impetus
What URL the Lambda is called with is configured in the API Gateway, not in the Lambda.
The API Gateway configuration can be done through the GUI as shown below, but there are quite a few configuration points, and I soon reached the limit of manually managing Lambda and API Gateway, so I began to investigate the need to use some sort of management tool.
lack of motivation
In my research, I came up with candidates such as "Serverless," "AWS SAM," and "Swagger" as management tools, but in the process, I came across the keyword "GraphQL.
GraphQL" is a new API procedure proposed by Facebook to replace the REST API, and although I did not intend to use it this time, the fact that such a thing is now available makes me wonder if the REST API is in transition, and my motivation to work on the REST API has suddenly cooled. I was not planning to use the REST API this time.
GCP and Azure also provide similar Function and API services, but their mechanisms are disparate, and I felt that it would be difficult to create a universal tool to bring them together.
So I started thinking that I would like something as easy to use and with as low a learning cost as possible, even if it is not general-purpose.
I'll give it a try.
In the midst of all this, I thought CloudFormation would be a good idea because I could use that knowledge for AWS in general, so I gave it a try, but As noted in the article., I got a painful experience.
Next, we tried "Serverless," which was easy to use and we ended up continuing to use it.
Serverless Advantages
- It works well with a minimum of description.
- Lambda and API Gateway functions are mostly covered.
- What Serverless does not cover, CloudFormation can make up for.
The unsettled parts are supplemented with default settings by Serverless, so the configuration was easy to understand, requiring only a small amount of description.
Usage Procedure
Serverless is installed using npm install -g serverless and npm.
Next, write the configuration file "serverless.yml" and place it in the directory where the program is located.
Then, if you do serverless deploy, the program will be uploaded, the Lambda will be created, the path will be created by API Gateway, and the path will be tied to the Lambda.
If you change the program or path, use serverless deploy again to update the file.
Example
For example, a Lambda+API Gateway that returns "{'result': 'Hello World!'}" when the path "/test/message" is accessed with GET is as follows. Furthermore, here we will try to make it possible to separate APIs for development and production.
helloWorld.ts (converted to JavaScript)
exports.handler = async (event: any, context: any) => { try { return { result: 'Hello World!' }; } catch (err) { console.error(err); throw err; } }
serverless.yml
service: serverless-test-api # プロジェクト名 provider: name: aws stage: ${opt:stage} # ステージ名（パラメータ化） endpointType: REGIONAL role: arn:aws:iam::xxxx # Lambdaのロール runtime: nodejs8.10 region: ap-northeast-1 deploymentBucket: name: serveless-test-bucket # Lambdaのアップ先のS3バケット名 functions: hello-world: # 関数名（論理名） name: hello-world-dev-${self:provider.stage} # 関数名（Lambda実名） handler: helloWorld.handler # ハンドラ（<JavaScriptファイル名>.<function名>） events: - http: path: test/message # パス method: get # メソッド integration: lambda
Type serverless deploy --stage 'dev' to upload Lambda and API Gateway.
Serverless includes a mechanism for separating development and production stages, which is configured in the YAML "stage". The overall API is created with that stage name, so it is possible to separate development and production APIs by stage name.
The stage name can be parameterized and determined when the serverless deploy command is executed. And since we wanted to change the Lambda function for each stage, we used the variable "${self:provider.stage}" to refer to the stage name in the YAML to switch the name.
This allows me to change paths and add/switch stages with just a small change in description. I shudder to think of doing this in the AWS GUI....
supplementary explanation
- Serverless uses CloudFormation internally to deploy Lambda and API Gateway, so it is possible to delete the entire Lambda and API Gateway using
serverless remove. - In addition to API Gateway, other Lambda triggers such as S3 and CloudWatch can also be written in Serverless.
When using Lambda, you may want to manage related AWS resources together, and Serverless allows you to create and configure them in the "resources" section using CloudFormation descriptions.
For example, if you create Lambda roles in Serverless, you can avoid cases such as forgetting to grant privileges when deploying to production. Also, when you delete a Lambda, the role will be deleted along with it, which is very convenient because you will not be left with garbage roles of unknown use.
impressions
When I first started looking for a tool, I was daunted by how hard it would be to learn, but I am glad I found a simple tool.
It seems that GraphQL can also be written in Serverless, so if GraphQL becomes popular, I would like to try it someday.
I wrote this in a separate post because I got stuck on some Serverless settings around the Lambda authorizer.
