DEV Community: Franco Cerutti

Onion Architecture in AWS Lambdas with TypeScript: A Practical Guide with Tradeoffs

Franco Cerutti — Tue, 28 Nov 2023 11:53:32 +0000

Introduction

In the realm of software development, the Onion Architecture, also known as the Ports and Adapters pattern, has emerged as a popular design approach for building modular, maintainable, and testable applications. This architectural style encapsulates core business logic within a distinct layer, shielding it from external dependencies and facilitating seamless integration with various external adapters.

AWS Lambda, a serverless computing service offered by Amazon Web Services (AWS), provides a compelling platform for deploying event-driven applications. However, effectively implementing the Onion Architecture within Lambda functions can introduce certain tradeoffs that warrant careful consideration.

This essay delves into the intricacies of applying Onion Architecture in AWS Lambdas using TypeScript, highlighting the associated benefits and drawbacks. It aims to equip developers with a comprehensive understanding of this architectural approach and its practical implications within the serverless context.

Embracing Onion Architecture in AWS Lambdas with TypeScript

The Onion Architecture, when applied to AWS Lambdas using TypeScript, offers several advantages:

Encapsulation and Modularity

The core business logic, encapsulated within the inner layers of the onion, remains shielded from external dependencies, promoting modularity and reusability of code components.

Testability

By isolating the business logic, unit testing becomes more straightforward, as test cases can focus on the core functionality without the distractions of external dependencies.

Adaptability

The outer layers, responsible for interacting with external systems, can be easily adapted to accommodate different technologies and frameworks, enhancing the application's flexibility.

To implement Onion Architecture in AWS Lambdas with TypeScript, consider the following steps:

Define Core Domain Layer

Create a TypeScript module to house the core domain entities, value objects, and business rules. This layer is the heart of the application and should be independent of any external dependencies.

Establish Application Layer

Implement the application layer, responsible for orchestrating the core domain logic. This layer interacts with the core domain through interfaces and abstracts away the underlying implementation details.

Design Infrastructure Layer

Encapsulate the interaction with external systems, such as databases, APIs, or messaging queues, within the infrastructure layer. This layer utilizes the application layer's interfaces to communicate with the core domain.

Tradeoffs of Onion Architecture in AWS Lambdas

While the Onion Architecture offers significant benefits, it also introduces certain tradeoffs:

Increased Complexity

The layered structure adds complexity to the codebase, potentially increasing the learning curve for new developers.

Careful Dependency Management

Managing dependencies between layers requires careful planning to avoid circular dependencies and ensure proper initialization.

Code Examples

To illustrate the implementation of Onion Architecture in AWS Lambdas with TypeScript, consider the following code snippets:

Domain Layer

interface IUser {
  id: string;
  name: string;
  email: string;
}

class User implements IUser {
  id: string;
  name: string;
  email: string;

  constructor(id: string, name: string, email: string) {
    this.id = id;
    this.name = name;
    this.email = email;
  }
}

Application Layer

class UserService {
  private readonly userRepository: IUserRepository;

  constructor(userRepository: IUserRepository) {
    this.userRepository = userRepository;
  }

  async getUser(userId: string): Promise<User> {
    const userData = await this.userRepository.getUserById(userId);
    return new User(userData.id, userData.name, userData.email);
  }
}

Infrastructure Layer

class UserRepositoryImpl implements IUserRepository {
  async getUserById(userId: string): Promise<UserData> {
    // Implement database interaction to fetch user data
  }
}

Conclusion

Onion Architecture, when implemented effectively, can significantly enhance the modularity, testability, and adaptability of AWS Lambda applications. However, it is crucial to carefully consider the potential tradeoffs, such as increased complexity and performance overhead, before adopting this architectural approach.

TypeScript provides a powerful type system that can effectively support the implementation of Onion Architecture, ensuring type safety and reducing the risk of runtime errors. By leveraging TypeScript's capabilities, developers can confidently apply Onion Architecture to build robust and maintainable serverless applications on AWS Lambda.

Hope you like it and makes some changes in your daily basis

How to Create a Login for your WebApp with AWS Cognito Using OAuth 2.0

Franco Cerutti — Mon, 31 Jul 2023 14:47:59 +0000

What is AWS Cognito

Amazon Cognito is an identity platform for web and mobile apps. It’s a user directory, an authentication server, and an authorization service for OAuth 2.0 access tokens and AWS credentials.

You can authenticate and authorize users from the built-in user directory, from your enterprise directory, and from consumer identity providers like Google and Facebook.

Context

The application is going to be a webApplication where needs a login/SignUP feature, and the scope of this is to integrate the cognito user pools with Google federated Identities from Infrastructure as Code using Pulumi

Step to integrate AWS Cognito

Define the User Pool

Create a user pool when you want to authenticate and authorize users to your app or API. User pools are a user directory with both self-service and administrator-driven user creation, management, and authentication



 const userPool = new aws.cognito.UserPool(
    `${appShortName}-user-pool-${NODE_ENV}`,
    {
      autoVerifiedAttributes: ['email'],
      emailConfiguration: {
        replyToEmailAddress: process.env.REPLY_EMAIL_ADDRESS,
        emailSendingAccount: 'COGNITO_DEFAULT',
      },
      mfaConfiguration: 'OPTIONAL',
      softwareTokenMfaConfiguration: {
        enabled: true,
      },
      accountRecoverySetting: {
        recoveryMechanisms: [
          {
            name: 'verified_email',
            priority: 1,
          },
          {
            name: 'verified_phone_number',
            priority: 2,
          },
        ],
      },
      adminCreateUserConfig: {
        allowAdminCreateUserOnly: true,
      },
    }
  );

Create Federated Identities Provider

In this case we're going to create a Goggle Identity, and we defined the provider configuration

Before continuing with the Infrastructure in Pulumi we need to go to GCP Console and make the next config.

GCP Config

Once you're in the Console, go to API & Services, Credentials, create a Oauth Client, declare mocked URL and continue. This you will need to modify once you have your Cognito DNS.



  const googleCredentials = {
    clientId: process.env.GOOGLE_CREDENTIALS_CLIENT_ID,
    clientSecret: process.env.GOOGLE_CREDENTIALS_CLIENT_SECRET,
  };

  const googleProvider = new aws.cognito.IdentityProvider(
    `${appShortName}-identity-google-provider-${NODE_ENV}`,
    {
      providerName: 'Google',
      userPoolId: userPool.id,
      providerType: 'Google',
      providerDetails: {
        client_id: googleCredentials.clientId,
        client_secret: googleCredentials.clientSecret,
        authorize_scopes: 'email profile openid',
      },
      attributeMapping: {
        email: 'email',
        username: 'sub',
      },
    }
  );

Create the Client App for the User Pool



  const userPoolClient = new aws.cognito.UserPoolClient(
    `${appShortName}-user-pool-client-${NODE_ENV}`,
    {
      userPoolId: userPool.id,
      callbackUrls: [process.env.CALLBACK_WEB_APP_URL],
      logoutUrls: [process.env.LOGOUT_WEB_APP_URL],
      explicitAuthFlows: [
        'ALLOW_USER_SRP_AUTH',
        'ALLOW_REFRESH_TOKEN_AUTH',
        'ALLOW_CUSTOM_AUTH',
      ],
      allowedOauthFlowsUserPoolClient: true,
      allowedOauthScopes: ['profile', 'openid', 'email'],
      allowedOauthFlows: ['code'],
      supportedIdentityProviders: ['COGNITO', googleProvider.providerName],
    }
  );

Here you have declared the OauthFlows, Scopes and Providers that your Cognito IDP will support.

Deploy

Deploy the infrastructure to AWS



pulumi up

AWS Config

Go to the AWS Cognito, in the AWS Console, fetch the one created recently.

Navigate to the App integration tab for your user pool.

Next to Domain, choose Actions and select Create custom domain or Create Amazon Cognito domain. If you have already configured a user pool domain, choose Delete Amazon Cognito domain or Delete custom domain before creating your new custom domain.

Enter an available domain prefix to use with a Amazon Cognito domain

Choose Create.

Verify DNS

Verify that the sign-in page is available from your Amazon Cognito hosted domain.



https://<your_domain>/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>

Your domain is shown on the Domain name page of the Amazon Cognito console. Your app client ID and callback URL are shown on the App client settings page.

Summary

With that being done, you will have a functional Authorization & Authentication with Google Federated Identities using OAuth 2.0 from Infrastructure as Code.

This is a guide from and for the community

Hope you like it!

Lift and Shift to AWS with IaC

Franco Cerutti — Mon, 24 Jul 2023 11:54:21 +0000

What is Lift and Shift?

Lift and Shift, or re-hosting, is one of the strategies to migrate existing applications into the cloud, where the application is not modified, only the hosting platform is changed.

Check the next link for the 6'R of migrations: AWS Docs

In this article case we're going to see the Open Source project of E-Commerce Medusa Backend Server and an Admin Panel

What is Medusa?

Medusa is an open source project for building blocks of e-commerce, in order to not re-invent the wheel, which provides a extensive API's, Backoffice and the UI using SSR/SSG with Next.JS

How to migrate to AWS?

To migrate to AWS, we have to make some considerations before dropping that artifact in a compute and expose it with a DNS.

Considerations when migrating to AWS

1 - Operations

What things do we need to keep running in order to sustain the platform?

2 - Security

What security assessment or compliances i need to be comply to?

3 - Costs

What is my monthly and annually budget?

4 - Performance

Which is my desired traffic, or user consumption business goal?

5 - Availability

How is my application going to be available in case of a cloud provider failure?

6 - Resillience

Is my application going to be ready to fail, and keep running?

With that being said we can choose the right resources in AWS to make this lift-shift migration strategy

Ready?

Let's migrate.

Steps to migrate to AWS

Install Dependencies

npm install @medusajs/medusa-cli -g

Create the Medusa Backend Server

medusa new my-medusa-store

Dockerize the application

You can use the next Docker, i recommend to make this one with Multi-stage pattern for PROD and keep the platform in case the CI is running on arm64 if not, remove it

FROM  --platform=linux/amd64 public.ecr.aws/docker/library/node:lts

# Create app directory
WORKDIR /usr/src/app

# Bundle app source
COPY . .

RUN npm install

# If you are building your code for production
# RUN npm ci --omit=dev

EXPOSE 80

CMD [ "node", "index.js" ]

Build Docker and Run it Locally

docker build -f ./Dockerfile. -t <myImage> --no-cache

docker run <myImage> -p 80:80

Deploy to AWS

For this architecture we decided to go with AWS ECS Launch Type Fargate, since the business needs a fully managed container service orchestration to handle the deployment, load balancing, where Amazon ECS will launch, monitor, and scale your application across flexible compute options with automatic integrations to other supporting AWS services that your application needs

*How we are going to deploy *

For deployment we're going to use best practice DevOps using Infrastructure as Code ( IaC ) with Pulumi

Run the next code at the root level

pulumi new aws-typescript --dir ./infra

First we need to create Roles, Repository of ECR and Image for our Docker

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

const imageName = 'medusa-ecr-image';
const repositoryName = 'medusa-ecr-repository';

const repository = new awsx.ecr.Repository(repositoryName);

const imageArgs: awsx.ecr.ImageArgs = {
    dockerfile: '../dockerfile',
    path: '../',
    repositoryUrl: repository.url,
};

const dockerImage = new awsx.ecr.Image(imageName, imageArgs);

// Define the Log Group Creator IAM
const logGroupCreatorPolicy = new aws.iam.Policy("logGroupCreatorPolicy", {
    policy: JSON.stringify({
        Version: "2012-10-17",
        Statement: [{
            Action: [
                "*"
            ],
            Effect: "Allow",
            Resource: "*"
        }]
    })
});

// Create a new Role
const ecsRole = new aws.iam.Role("ecsRole", {
    assumeRolePolicy: JSON.stringify({
        Version: "2012-10-17",
        Statement: [{
            Action: "sts:AssumeRole",
            Principal: {
                Service: "ecs-tasks.amazonaws.com",
            },
            Effect: "Allow",
        }],
    }),
});

// Attach the log creator policy to the role
new aws.iam.RolePolicyAttachment("rolePolicyAttachment", {
    role: ecsRole.name,
    policyArn: logGroupCreatorPolicy.arn,
});

const executionECSRole = {
    roleArn: ecsRole.arn,
};

Now we need to create:

ECS Cluster
Fargate Service
Task Definition
Load Balancer


// create ECS cluster

const clusterName = 'medusa-ecs-cluster';
const loadBalancer = 'medusa-ecs-load-balancer';
const ecsService = 'medusa-ecs-service';


const configLoadBalancer: awsx.lb.ApplicationLoadBalancerArgs = {
    defaultTargetGroup: {
        port: 80,
        healthCheck: {
            path: '/health',
        }
    },
    enableWafFailOpen: true,
};

const lb = new awsx.lb.ApplicationLoadBalancer(loadBalancer, configLoadBalancer);


const cluster = new aws.ecs.Cluster(clusterName, {});

const service = new awsx.ecs.FargateService(ecsService, {
    cluster: cluster.arn,
    assignPublicIp: true,
    desiredCount: 2,
    taskDefinitionArgs: {
        executionRole: executionECSRole,
        containers: {
            app: {
                image: dockerImage.imageUri,
                cpu: 512,
                memory: 1024,
                essential: true,
                portMappings: [{
                    containerPort: 80,
                    hostPort: 80,
                    targetGroup: lb.defaultTargetGroup,
                }],
                healthCheck: {
                    command: ["CMD-SHELL", "curl --fail http://localhost/health || exit 1"],
                    interval: 30,
                    timeout: 3,
                    retries: 3
                },
                logConfiguration: {
                    logDriver: "awslogs",
                    options: {
                        "awslogs-create-group": "true",
                        "awslogs-group": "medusa-logs-group",
                        "awslogs-region": "us-east-1",
                        "awslogs-stream-prefix": "medusa-ecs-logs"
                    }
                }
            }
        },
    },

});

export const url = lb.loadBalancer.dnsName;

You can see important things here.

Load balancer config with healthcheck route, the definition of the container app with hardware resources and port mapping, this will allow that the Task Definition of the Cluster exposes a port to the cluster and to the container.

Last the container has a healthcheck inside where checks if the Docker is healthy

Now let's wrap this up!

pulumi up

Pulumi will expose the DNS for our service, check the /health route and it should be returning OK.

Also check the /app which holds the Admin Panel.

Hope you enjoy it and learn how to Lift and Shift an App to AWS using ECS Fargate.