Latest news

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej D. Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-04-17 </dd>

With the rising popularity of Function URLs, which are dedicated HTTP(S) endpoints for your Lambda function, we can avoid many of the complexities, costs and limitations associated with Amazon API Gateway. The downside is we also lose some of the nice features of an API Gateway that we get out of the box, one key feature being API routing based on method and path of an http event. This is where Middy, a Node.js middleware engine for AWS Lambda really comes in handy.

In particular, we can achieve nested http routing within our Lambdas by leveraging Middy's [http-router](https://middy.js.org/docs/routers/http-router) handler. Let's start by cloning the starter project repo:

```bash
git clone https://github.com/AndrzejKomarnicki/awscdk-nodejsfunction-middy
```

Next let's install the npm packages and run some AWS CDK CLI commands from the root working directory of our cloned repo.

```bash
npm install
cdk synth && cdk diff
```

By default AWS CDK CLI will check your environment variables for your AWS creds and region first, if not found it will default back to your AWS credentials and config files. You can of course also specify the AWS CLI profile of choice. For more info on how to setup environments for your Stack instance head over to https://docs.aws.amazon.com/cdk/v2/guide/environments.html.

Anyway, if everything checks out let's proceed to deploy the Stack as part of our CDK app:

```bash
cdk deploy
```

After deployment, you should see output similar to below:

![functionurl](/images/functionurl-blog2.png "functionurl")

Next let's dive into the Lambda function source code before we test the endpoints... 
Open up **index.ts** from _/services/node-lambda/_

```javascript
import middy from "@middy/core";
import jsonBodyParser from "@middy/http-json-body-parser";
import httpErrorHandler from "@middy/http-error-handler";
import httpSecurityHeaders from "@middy/http-security-headers";
import httpRouterHandler from "@middy/http-router";
import { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from "aws-lambda";
import { Logger, injectLambdaContext } from "@aws-lambda-powertools/logger";

const logger = new Logger({
 logLevel: "INFO",
 serviceName: "middy-example-api",
});

async function getHandler(
 event: APIGatewayProxyEventV2,
 context: any
): Promise<APIGatewayProxyResultV2> {
 // the returned response will be checked against the type `APIGatewayProxyResultV2`
 logger.info("This is a INFO log with some context");
 console.log("event 👉", event);
 return {
 statusCode: 200,
 body: JSON.stringify(`Hello from ${event.rawPath}`),
 };
}

async function postHandler(
 event: APIGatewayProxyEventV2,
 context: any
): Promise<APIGatewayProxyResultV2> {
 // the returned response will be checked against the type `APIGatewayProxyResultV2`
 logger.info("This is a INFO log with some context");
 console.log("event 👉", event);
 return {
 statusCode: 200,
 body: JSON.stringify(event.body),
 };
}

// routes served by httpRouterHandler middleware
// you can add more nested handlers for routes (method and path) as needed
const routes = [
 {
 method: "GET",
 path: "/user/{id}",
 handler: getHandler,
 },
 {
 method: "POST",
 path: "/user",
 handler: postHandler,
 },
];

export const handler = middy()
 .use(jsonBodyParser())
 .use(httpSecurityHeaders())
 .use(httpErrorHandler())
 .use(injectLambdaContext(logger)) // Change to (logger, { logEvent: true }) to log the incoming event
 .handler(httpRouterHandler(routes));
```

As you can tell we import **httpRouterHandler** from **@middy/http-router**, and we define two async node.js functions - _getHandler()_ and _postHandler()_, which are referenced by the routes object as part of its handler property depending on http path and method in the http event.

Of course you can re-organize these nested Lambda handlers to be exported as modules instead of having everything in one monolithic index.ts file, this only serves as a starting point for demonstration purposes.

Let's proceed to test our endpoints with the different paths and methods we defined. You can go back to the outputs generated by "CDK deploy" and test against both the _Function URL_ and _CloudFront URL_.

```json
GET method on /user/{userid}
```

![getmethod](/images/getmethod-blog2.png "getmethod")

```json
POST method on /user
```

![postmethod](/images/postmethod-blog2.png "postmethod")

Using AWS CDK with TypeScript to deploy and manage AWS Lambda functions that support nested HTTP routes served through function URL and CloudFront

Nested API routes with Node.js AWS Lambda Function URL, Middy HTTP router and AWS CDK

![service](/images/headshot.png "Andrzej photo")

<dd> By Andrzej D. Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-03-26 </dd>

HashiCorp announced the general availability of Terraform CDK back in August 2022, and since then we've seen the arrival of several enhancements and new pre-built providers-many available through the [Construct Hub](https://constructs.dev "Construct Hub"). The beauty of CDKTF is that you can generate the code bindings for virtually any existing Terraform provider by simply using the cdktf cli and you can use the existing Terraform registry to look up a provider's resource and argument reference.

The source code for this series can be found here: https://github.com/smallfriesdigital/cdktf-mongodbatlas-gcp.

Let's dive head first into initializng a new cdktf project within our working dir that uses the GCP provider:

```bash
cdktf init --template=typescript --local --providers="google@~>4.0"
```

Next let's add the pre-built MongoDB Atlas provider:

```bash
cdktf provider add mongodb/mongodbatlas
```

OK, so now let's update _MyStack_ in **main.ts** with the following CDKTF TypeScript code:

```javascript
import { Construct } from "constructs";
import { App, TerraformStack, TerraformVariable } from "cdktf";
import { MongodbatlasProvider } from "@cdktf/provider-mongodbatlas/lib/provider";
import { Project } from "@cdktf/provider-mongodbatlas/lib/project";
import { Cluster } from "@cdktf/provider-mongodbatlas/lib/cluster";

class MyStack extends TerraformStack {
 constructor(scope: Construct, id: string) {
 super(scope, id);

 // define secure environment variables (won't end up in cdk.tf.json)
 const publicKey = new TerraformVariable(this, "publicKey", {
 type: "string",
 description: "MongoDB Atlas Org Public Key",
 sensitive: true,
 });

 const privateKey = new TerraformVariable(this, "privateKey", {
 type: "string",
 description: "MongoDB Atlas Org Private Key",
 sensitive: true,
 });

 const orgId = new TerraformVariable(this, "orgId", {
 type: "string",
 description: "MongoDB Atlas Org ID",
 sensitive: true,
 });

 // satisfy all the Atlas requirements before instantiating new cluster
 new MongodbatlasProvider(this, "Atlas", {
 publicKey: publicKey.value, // secret set via environment variable TF_VAR_publicKey
 privateKey: privateKey.value, // secret set via environment variable TF_VAR_privateKey
 });

 const atlasProject = new Project(this, "newProject", {
 name: "CDKTFProject1",
 orgId: orgId.value, // set via environment variable TF_VAR_orgId
 });

 // create cluster resource
 new Cluster(this, "newCluster1", {
 projectId: atlasProject.id,
 name: "atlasClusterCDK",
 clusterType: "REPLICASET",
 cloudBackup: false,
 mongoDbMajorVersion: "5.0",
 providerName: "TENANT",
 backingProviderName: "GCP",
 providerInstanceSizeName: "M0",
 providerRegionName: "CENTRAL_US",

 replicationSpecs: [
 {
 numShards: 1,
 regionsConfig: [
 {
 electableNodes: 3,
 priority: 7,
 readOnlyNodes: 0,
 regionName: "CENTRAL_US",
 },
 ],
 },
 ],
 });
 }
}

const app = new App();
new MyStack(app, "cdktf-gcp-mongodbatlas");
app.synth();
```

In this case we're using the free tier **_M0 Sandbox_** cluster, which is only recommended for development or testing purposes and doesn't support backups. Also keep in mind we are referencing the **_Atlas Region_** associated with the respective **_Google Cloud Region_**, not the GCP region name directly.
 You can read more about that here: (https://www.mongodb.com/docs/atlas/reference/google-gcp/#std-label-google-gcp)

> **CDKTF Best Practices for handling secrets:** use the TerraformVariable construct, Terraform uses the values in TerraformVariable directly at execution time, so CDKTF does not write them to the synthesized cdktf.json file. To pass a Terraform variable through environment variables, name the environment variable **TF_VAR_NAME** - 'NAME' being a placeholder for your variable name.

##### Environment variables that need to be set in the execution environment:

- TF_VAR_publicKey
- TF_VAR_privateKey
- TF_VAR_orgId

You can now feel free to run **cdktf plan** and **cdktf deploy** in order to get the base setup going, or instead choose to do it at the end once we wrap up all the other resource additions.

Let's go back and update the existing Cluster resource by assigning it to a constant in **main.ts**, then adding the admin database user to that cluster.

```javascript
// create cluster resource
const atlasCluster = new Cluster(this, "newCluster1", {
 projectId: atlasProject.id,
 name: "atlasClusterCDK",
 clusterType: "REPLICASET",
 cloudBackup: false,
 mongoDbMajorVersion: "5.0",
 providerName: "TENANT",
 backingProviderName: "GCP",
 providerInstanceSizeName: "M0",
 providerRegionName: "CENTRAL_US",

 replicationSpecs: [
 {
 numShards: 1,
 regionsConfig: [
 {
 electableNodes: 3,
 priority: 7,
 readOnlyNodes: 0,
 regionName: "CENTRAL_US",
 },
 ],
 },
 ],
});

const adminPassword = new TerraformVariable(this, "adminPassword", {
 type: "string",
 description: "MongoDB Atlas Cluster DB Admin",
 sensitive: true,
});

// add admin user to cluster
new DatabaseUser(this, "adminUser", {
 username: "cdktf-adminuser",
 password: adminPassword.value, // secret set via environment variable TF_VAR_adminPassword
 projectId: atlasProject.id,
 authDatabaseName: "admin",
 roles: [
 {
 roleName: "readAnyDatabase",
 databaseName: "admin",
 },
 ],
 scopes: [
 {
 name: atlasCluster.name,
 type: "CLUSTER",
 },
 ],
});
```

##### Environment variables that need to be set in the execution environment:

- TF_VAR_adminPassword

Finally, let's add the remaining network access piece to our stack in **main.ts**:

```javascript
const userNetwork = new TerraformVariable(this, "userNetwork", {
 type: "string",
 description: "MongoDB Atlas Project IP access",
 sensitive: false,
});

new ProjectIpAccessList(this, "projectnetworkAccess", {
 projectId: atlasProject.id,
 cidrBlock: userNetwork.value, // secret set via environment variable TF_VAR_userNetwork
});
```

Last but not least, define the one remaining env variable with your network CIDR.

##### Environment variables that need to be set in the execution environment:

- TF_VAR_userNetwork

```bash
cdktf plan
cdktf deploy
```

And voila! We are now ready to start developing against our MongoDB Atlas cluster from our machine. Bon coding.

An example of how to leverage Cloud Development Kit for Terraform with TypeScript to deploy a MongoDB Atlas cluster on GCP

Latest news

Nested API routes with Node.js AWS Lambda Function URL, Middy HTTP router and AWS CDK

Deploy a MongoDB Atlas cluster on GCP with CDKTF using TypeScript