SAM on {O}

Building a Practical Serverless API with SAM: Leveraging Nested Stacks for Organization

Mon, 01 Jan 0001 00:00:00 +0000

This example demonstrates how to build and deploy a simple serverless API using AWS Lambda, API Gateway, and AWS SAM (Serverless Application Model). The core focus here is on leveraging modularity and nested stacks to create a well-organized and scalable project structure.

Project Structure

Here’s a quick overview of the project’s key components:

api.yaml: This SAM file defines the API Gateway. It’s responsible for linking HTTP paths (like /orders and /logs) to the appropriate Lambda Functions. Crucially, it imports the API definition from openapi.yaml.
log.yaml: This SAM file contains the definition for the Lambda Function responsible for fetching logs (GetLogs).
order.yaml: This SAM file contains the definition for the Lambda Function responsible for fetching orders (GetOrders).
openapi.yaml: This is the OpenAPI (Swagger) file that specifies the API paths (e.g., /orders, /logs) and how they integrate with the Lambda Functions. Here, we define the x-amazon-apigateway-integration that links each path to the ARN of the relevant Lambda Function.
template.yaml: This is the main SAM template for your project. It acts as an orchestrator for all the sub-stacks (OrderStack, LogStack, ApiStack). Each sub-stack points to its respective YAML file using the Location property of AWS::Serverless::Application.

Why Modularity and Nested Stacks?

Modularity & Organization: When you split your project into separate files like order.yaml, log.yaml, and api.yaml, your project becomes easier to organize and understand. Each file focuses on one part of the app, so it’s easier to work on and update, especially when the project gets bigger.

Build a Simple API on AWS with Lambda, API Gateway, and SAM

Mon, 01 Jan 0001 00:00:00 +0000

This example shows how to build and deploy a simple serverless API using AWS Lambda, API Gateway, and AWS SAM (Serverless Application Model). The API fetches a list of todos from a public endpoint and returns them via an HTTP GET request.

Project Structure

Here’s a quick overview of the project’s key components:

functions/: Contains the Lambda function ListTodos.mjs, which fetches todo items from a public API using Axios.
tests/: Contains a Jest test to ensure the function returns items with a 200 status code.
layers/: Optional shared layer for common dependencies (e.g., axios), defined under nodejs/package.json.
template.yaml: AWS SAM template that defines the infrastructure:
- Lambda function (ListTodosFunction)
- API Gateway (/posts)
- Shared Layer

How It Works

When a client makes a GET request to /todos, the Lambda function is triggered, fetches data from https://jsonplaceholder.typicode.com/todos?_limit=3, and returns it as JSON.

Serverless Messaging with AWS SAM: SNS, SQS, and Lambda

Mon, 01 Jan 0001 00:00:00 +0000

This example shows how to build a serverless messaging pipeline using AWS SAM. The project uses SNS to publish messages, SQS queues to separate concerns, and Lambda functions to process the data. It also uses filter policies to control message delivery to each queue.

This architecture is useful when you want to send different types of data to different consumers, and keep your application components decoupled.

Project Structure

The template defines:

Organize AWS Lambda Projects with Nested Stacks and Layers in SAM

Mon, 01 Jan 0001 00:00:00 +0000

This example shows how to build a modular AWS Lambda project using SAM (Serverless Application Model) with nested stacks and a shared layer. This helps keep your project clean and organized by separating logic and shared dependencies.

How It Works

layer.yaml creates a shared Lambda Layer that contains Node.js packages (like axios).
order.yaml and log.yaml are two Lambda functions that use this shared layer.
The root template (template.yaml):
- Creates the layer stack.
- Passes the layer reference to the other stacks as a parameter.

sam build
sam deploy --guided

Project Repository: https://github.com/OmarMakled/sam-nested-layer

AWS SAM Nested Stacks for a Structured GraphQL API

Mon, 01 Jan 0001 00:00:00 +0000

This example provides a structured approach to deploying a Serverless GraphQL API using AWS Serverless Application Model (SAM), leveraging Nested Stacks for modularity.

Project Structure: Modular Stacks

The core idea is to break down the infrastructure into specialized, manageable units using SAM’s Nested Stacks. This separation enhances clarity, reusability, and maintainability.

The Root Template acts as the orchestrator, defining the dependencies between the smaller stacks:

RolesStack (stacks/roles.yaml): Creates the necessary IAM Roles for Lambda execution and for AppSync to invoke the Lambda function.
GraphQLStack (stacks/graphql.yaml): Provisions the AWS AppSync GraphQL API, including the API itself, the API Key, and the Schema definition (which is assumed to be uploaded to an S3 location).
FunctionsStack (stacks/functions.yaml): Deploys the Lambda function, the AppSync Data Source, and the Resolvers
query.graphql the schema definition can also be split into smaller files (types, queries, and mutations). These fragments are then merged into a single final schema file (schema.graphql).

The best thing about this design is that everything is organized and independent. Each group of functions or resources is in its own box (stack).

Organizing Serverless Code with AWS SAM: Lambda Layers and Testing with Jest

Mon, 01 Jan 0001 00:00:00 +0000

This example demonstrates how to build clean, testable, and modular serverless applications on AWS using AWS SAM, Lambda Layers, and Jest. It focuses on two essential practices for scalable serverless development:

Using Lambda Layers to share code across functions
Using Jest to properly test each function and its dependencies

By combining these two patterns, you get a powerful structure that’s maintainable, reusable, and confidently testable.

Project Overview: Shared Logic + Layer for Node Modules + Testing

functions/ – Your Lambda function handlers:

Using Parameters vs. Export/Import in AWS SAM: What’s Better?

Mon, 01 Jan 0001 00:00:00 +0000

When you build serverless applications with AWS SAM or CloudFormation, sometimes you need to share resources between stacks. For example, you may have:

A Cognito User Pool in one stack (for user authentication)
And an API Gateway in another stack that needs to use that Cognito pool

There are two main ways to connect these stacks:

Option 1: Using Parameters

You can pass values like the User Pool ARN or ID as a parameter when you deploy the second stack.