AWS Application Composer: Transforming Application Development with Visual Tools

Introduction

Last year AWS released Application Composer, a low-code tool that helps you visually compose and configure modern applications from AWS services. The tool is backed by robust infrastructure as code (IaC), streamlining deployment and operations.

Core Features

AWS Application Composer’s standout feature is its visual canvas, which allows users to assemble and configure various resource components. This facilitates the creation of IaC for application architectures. Additionally, its integration with Visual Studio Code enables simultaneous visualization and CloudFormation template editing within the IDE, enhancing the development experience.

The rise of low-code solutions is undeniable. Gartner’s studies project that by 2026, at least 80% of low-code tool users will be outside formal IT departments, up from 60% in 2021 (source: Gartner). AWS’s attempt into this sector with Application Composer seems both timely and strategic.

In this article, we want to explore the readiness of Application Composer for the market in 2024, and define its position and potential in the evolving tech landscape.

Available Resources and Components

At present, AWS Application Composer offers 14 Enhanced Components, such as AWS Lambda, API Gateway, DynamoDB, and Cognito UserPool. These components facilitate the creation of a range of applications, from basic to complex structures.

Building a Simple To-Do List Application

We have decided to test the tool’s capabilities and construct a simple to-do list application. This example will utilize API Gateway, integrated with Lambdas for various CRUD operations, and a DynamoDB table for data storage.

The process begins with adding and configuring Lambdas on the canvas. Clicking on the created elements, we can edit the configuration. Let’s set the runtime to Python 3.11 and reduce the default Lambda memory to a more suitable 128 MB for this application, as opposed to the 3008 MB proposed by the Application Composer.

First, we need to drag Lambda resources onto the canvas and edit their properties.

Then, we will create a DynamoDB table named tasksTable with Partition key taskId.

Linking the Lambdas to the DynamoDB table automatically attaches necessary policies and environment variables for database access.

When linking Lambda resources to a DynamoDB table, policies and variables will be added to the Lambdas automatically.

The next step involves creating and configuring a Lambda Layer, named tasksLayer, and adding this layer to the Lambdas. To do it, we need to enter the following code in the Layers configuration section of the function:

- !Ref tasksLayer

An API Gateway is then added to the canvas, with appropriate methods and routes configured. The final step in the visual process is linking these methods to the corresponding Lambdas.

Each API Gateway route method can be connected to a Lambda function.

Generating and Deploying the Application

AWS Application Composer is able to generate a deployment-ready AWS SAM template. You can download the template by clicking the menu in the upper right corner to build and deploy your application using AWS SAM and AWS CLI tools.

Coding and Deployment

After configuring the resources visually, the next step involves coding the Lambda functions and building the application using the AWS SAM CLI. This includes setting up AWS CLI, creating the project structure, writing Lambda handlers, and deploying the stack. If you do not have AWS CLI and AWS SAM installed on your machine, you can check out this guide by AWS.

Let’s create an empty project in the IDE and start by creating folders and code files for our layer and lambdas. The template.yaml that we downloaded in the previous step needs to sit at the project root.

Here’s the final project layout:

template.yaml
src
├── createTask
| └── handler.py
├── deleteTask
| └── handler.py
├── getTask
| └── handler.py
├── listTasks
| └── handler.py
├── updateTask
| └── handler.py
└── tasksLayer
└── utils.py

Let’s create a simple function in the tasksLayer/python/utils.py file so that we can test it later:

def print_hello():
    print("Hello from utils.py")
    return

Now let’s add some code to our handlers.

In createTask/handler.py file, we want to test if we have access to the layer from the Lambda function as well as test the DynamoDB connection by putting an item into the table.

import os
import uuid
import json
import boto3

from utils import print_hello

dynamodb_table = os.environ["TASKSTABLE_TABLE_NAME"]

table_resource = boto3.resource("dynamodb").Table(dynamodb_table)


def handler(event, context):
    print_hello()
    task_id = uuid.uuid4().hex
    item = {
        "taskId": task_id,
        "title": "New Task",
        "description": "New Task Description",
        "completed": False,
     }

    table_resource.put_item(Item=item)
    return {"statusCode": 200, "body": json.dumps(item)}

In listTasks/handler.py we check if the item was created successfully.

import os
import json
import boto3
dynamodb_table = os.environ["TASKSTABLE_TABLE_NAME"]
table_resource = boto3.resource("dynamodb").Table(dynamodb_table)


def handler(event, context):
    tasks = table_resource.scan()
    items = tasks.get("Items", [])
    return {"statusCode": 200, "body": json.dumps(items)}

The rest of the lambdas can have a simple handler that will return a 200 status code and the function name.

def handler(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from getTask"
    }

Now, we need to build and deploy the template. Make sure you already have AWS CLI and AWS SAM installed.

In your terminal, run aws configure to set up your credentials and create a profile.

Then run sam build. This will create a .aws-sam folder with the built code. If the command ran without any errors, you can now deploy the stack.

Use the command sam deploy — guided to set up the configuration and start the deployment. If you do not have a Managed Stack for AWS SAM CLI, it will be created before your stack is deployed.

Testing and Observations

Now that our stack is deployed, we can return to the AWS Console to test the application. First, we will check our endpoints in API Gateway. If we open the POST method at the / path, we will see a Test tab. Once we launch our test, we get a response containing a newly created item.

The POST method correctly invokes our Lambda function, producing a valid result.

If we go to CloudWatch to check the logs, we will see that the print_hello function from the Layer was invoked successfully as we see the result printed.

We can check the logs of our Lambda function to prove that the layer was connected successfully.

If we go and test the GET method at the / path, we will see our newly created item in the list.

All the tests prove that all the resources created function correctly, have the valid permissions, environment variables, and configuration.

Limitations and Conclusion

While AWS Application Composer can simplify the application development process, it still has limitations. Its current scope is restricted to the Enhanced Components available. Additional requirements, like API Gateway Authorizers or CloudFront Distributions, need to be configured manually using CloudFormation syntax.

Moreover, the current version lacks a feature to save and reopen projects, requiring users to save their templates externally.

Despite these limitations, AWS Application Composer is a valuable tool for visualizing architectures and developing smaller applications, such as POCs or simple tasks. Its user-friendly interface and integration with AWS services make it an attractive option for both seasoned developers and those new to cloud computing.

Looking Ahead

As AWS continues to evolve Application Composer, we anticipate that future updates will address current limitations and expand its capabilities, further improving the appearance of AWS in the low-code development space.