Getting started with serverless for developers: Part 3 – The front door

This blog post is part 3 of Getting started with serverless for developers, helping developers to start building serverless applications from their IDE. In the previous post, I introduce AWS Lambda and show how functions are designed to run business logic for serverless applications.

In this blog post, you see how to access that business logic by creating a front door to your serverless application using Amazon API Gateway. You extend the example serverless application from part 1 to process an additional GitHub webhook URL. Finally, you see how serverless applications help to reduce complexity and code by decoupling business logic from routing logic.

Serverless architecture uses an event-driven model. The Lambda service runs a Lambda function in response to an event. This is called an invocation by instructing the Lambda service to start running a Lambda function. A Lambda function can be invoked directly from a number of integrated AWS services including API Gateway.

The serverless application deployed in part 1 notifies users via Slack when a GitHub repository is starred. The business logic for this serverless application is contained in a single Lambda function:

A GitHub webhook is configured to make an HTTP POST request to a URL when a repository is starred. This is an event. But where is the URL endpoint and how do you configure the business logic to run in response to this request?

Meet Amazon API Gateway

Amazon API Gateway is a fully managed service that allows developers to create serverless APIs to run at almost any scale. These APIs can be configured to access application business logic.

The serverless application shown previously uses Amazon API Gateway to create a URL endpoint. The URL endpoint acts as a front door to the application business logic. When the endpoint receives an HTTP POST request, it invokes a Lambda function. Future posts in the series will demonstrate how to secure this front door by adding authentication to the API request.

Routing to business logic

In part 2: The business logic. I show how traditional application architectures hold all business and routing logic together as a single unit or code base. In contrast to this, serverless applications use managed services to separate the business logic from other application components, such as the routing logic.

Take an example of a manager/worker model. Typically, the manager’s role is to take incoming requests, decide which worker should do the work and pass the request to the correct worker. The worker receives the request from the manager and carries out the task, but is not responsible for deciding about the “bigger picture”. The worker then returns the completed task to the manager.

Applying this same model in a traditional non-serverless application, the worker and manager are both implemented within the business logic. In the example serverless application, the manager is implemented using API Gateway, which routes requests to the business logic. The business logic runs within a Lambda function:

In the serverless model, the business and routing logic are decoupled. The benefits of this approach become apparent when the application starts to grow.

For example, the application is extended to post a Slack notification when a new code push is made to a GitHub repository. To implement this in a traditional application model often requires editing the existing business logic and the routing. In a serverless application, it is implemented by:

Creating a new Lambda function to run new business logic.
Creating a new path on the API endpoint that invokes the new Lambda function.
Configuring the GitHub webhook to send a POST request to the new API path.

Serverless applications built with a framework such as the AWS Serverless Application Model (AWS SAM) can implement this quickly by duplicating template code. The following steps demonstrate this, and explain how the routing logic is configured and decoupled from the business logic.

Before you start

To deploy this stage of the application, follow the steps from post 1 to clone and deploy the sample application. The code for the example application can be found in this GitHub repository.

Run the following command from the root directory of the cloned repository:
cd ./part_3Look at the /part_3/template.yaml file. This is a new AWS SAM template for the example serverless application. The new Lambda function and its API invocation event are commented out:

# PushWebhookHandler:
  #   Type: AWS::Serverless::Function
  #   Description: A github webhook handler when a new push is made
  #   Properties:
  #     CodeUri: src_push/
  #     Handler: app.handler
  #     Runtime: nodejs12.x
  #     Timeout: 3
  #     Environment:
  #       Variables:
  #         slackEndpoint: !Ref slackUrl
  #     Events:
  #       HttpApiEvent:
  #         Type: HttpApi
  #         Properties:
  #           Path: /push
  #           Method: POST

This is identical to the first Lambda function configuration except for two definitions:

The CodeUri tells the application that the business logic is located inside a separate directory for this function called /src_push. This contains a file named app.js, which contains the business logic for the new Lambda function.
The API event path creates a new API endpoint with a new path of /push.

Uncomment the configuration for the new Lambda function by deleting the # symbol.
Build and deploy the application with the following commands:
```
sam build
sam deploy --guided --config-file ../samconfig.toml
```
This command leads you through a guided deployment, which requires some input parameters. These are prefilled if you have already completed the steps in part 1.
Once the deployment completes, the following output is provided:
There are now two API endpoint outputs. Make a note of the PushGitHubEndpoint value. This URL is the gateway to the business logic that processes a code push event. A POST request to this URL, along with the correctly formatted payload, triggers the PushWebhookHandler Lambda function to run. This POSTS a message to the Slack webhook URL.The final task is to configure GitHub to send a POST request to this URL:
Follow Setting up your GitHub webhook steps in part 1 to create the new webhook.
Paste the PushGitHubEndpoint into the Payload URL input.
Choose Pushes as the individual event to trigger the webhook.

Running the serverless application

A high-level representation of the updated serverless application looks as follows:

To see the application working in your GitHub repository:

Choose the Add file button from the repository homage, then choose create new file.
Give the new file a name, enter push.md in the name your file text input and choose commit new file:

This sends the GitHub event to the serverless application, which processes and sends it to the Slack webhook URL. The message appears in the Slack channel showing that a new code push has been made:

Conclusion

This blog post shows how to create a front door to the business logic of your serverless applications using Amazon API Gateway.

You see how serverless technologies help developers to decouple routing logic from business logic. This helps reduce code complexity when building serverless applications and allows serverless applications to grow quickly. You extended the GitHub webhook also to process code push events.

The next three posts in the series will focus on the developer workflow for building serverless applications. They describe how to check logs, test, and debug your code while building locally and how this differs from traditional applications.

For more getting started content, go to serverlessland.com.

AWS Compute Blog