DEV Community: Lakindu Hewawasam

How To Build a Node.js Express App in Under 5 Minutes?

Lakindu Hewawasam — Mon, 04 Dec 2023 18:07:22 +0000

As we move into 2024, the ideology behind faster development times has never been more critical. But, when building a Node.js Express app, that hasn't always been the case. In my experience, it usually takes a long time to bootstrap an Express API. This includes:

Creating a boilerplate NPM project using npm init.
Installing the required libraries - Express, Nodemon, Body Parser, and TypeScript to configure your Express Server
Setting up ESLint and creating the perfect ruleset for the project
Setting up Module Federation - If you want to share code between your Node.js and Express.js microservices.

This means you're spending more time on things that aren't adding value to your software. You'd be better off building a feature, but instead, you're configuring a linter or a build command.

How Can We Build Faster Express Apps?

The short answer is to treat your service as a component

It would help if you had a toolkit that lets you build your Express.js API as components where each component is designed, built, tested, and versioned in its isolated environment without you doing any configuration. Doing so allows you to start by building features without focusing on any operational needs.

To do this, you'd need to break your app down into two areas:

The actual app
The services

Your app and service could be treated as two components, where your service component holds the feature, while the app component provides a runtime to execute your service. By creating an independence of this nature, you can improve your development cycle time by testing your services without spinning up the app.

And one such tool that I've found that supports this component-driven approach is Bit.

Figure: Bit.dev

Bit is a next-generation build system for developing composable software. It let's you build your components in an isolated environment and uses services like Ripple CI to propagate changes up your component tree. For example, consider the diagram depicted below:

Figure: A sample component-driven API

Let's say that everything we've defined above is a component. And let's say that you change the logic on GetBlogById to return an error if Blog is not found.

If you make this change, it should automatically reflect the change in your BlogBackend route, right?

Well, this is what Bit does. It keeps track of the dependencies that your component uses, and if it detects a change, it propagates it up the tree, creating a Ripple effect, thus deploying the entire tree again to ensure that you're running on the latest change.

Sounds interesting. This is how I build my apps daily, and I thought I'd share my experience with it.

Building an Express.js App with Bit

Step 01: Pre-requisites

To build an Express.js app in under 5 minutes, you’ll need to install the Bit CLI using the command:

npx @teambit/bvm install

Next, you’ll need to verify that the CLI has been installed successfully by running the command:

bit --version

If you’ve installed Bit correctly, you should see the screenshot below.

Figure: Installing Bit Correctly

Next, you'll need to create an account on Bit Cloud. After you've created your account, go ahead and create a scope with the name blog:

Figure: Creating a scope on Bit Cloud

A Scope is a remote server in which your components live. Think of it like a GitHub repository, but it's not language-oriented. You can store anything in a scope and let people contribute to it.

bit.dev

Step 02: Creating the Express.js App

Next, in a new directory, initialize a Bit workspace using the command:

bit init

By doing so, you'll create a space for local development. You'll see a file - workspace.jsonc. Open that file and update the defaultScope parameter with the following - <<YOUR-USERNAME>>.<<SCOPE-NAME>>. After you do so, it should look like the snippet I've attached below:

"defaultScope": "dummyorg.blog",

Replace this with your username, and scope we created in Step 01.

Notice that your workspace isn't tied to a programming runtime. So, you can create an Express API and immediately create a React/ Angular/ React Native/ Vue.js component to consume the API as well.

Next, let's create an Express App. This can be done in one command:

bit create express-app blog-api && bit install --add-missing-deps

If you've done this correctly, you'll see the output:

Figure: Creating the Express.js app

Next, you'll see a directory as below:

Figure: Exploring the project directory

Go ahead and open up your app root - blog-api.app-root.ts. You'll see the following code:

Figure: The code generated in the app root

The code above is enough to launch your app as a bare Express server. It initializes an app, registers routers, and then listens to a port that's resolved in the getPort function. To start this Express App, let's run the following commands:

bit use blog-api && bit run blog-api

After you've done so, your Express.js app should spin up:

Figure: Spinning up the Express App

Next, you can open the sample endpoint - localhost:3000/. This should launch your Express app and show the output:

Figure: The sample app

Okay, but, this doesn't truly speak about component-driven development. To see this in action, run bit start. You should see a development server spin up:

Figure: Viewing the Workspace

You can click on the blog-api and view it as its component:

Figure: Viewing the Express App component

Step 03: Adding Routes to the API

Next, let's add routes to our API. Let's do this by creating two new components:

GetBlogs
GetBlogById

But first, it's important to note that both of our Routes will use the same Entity - "Blog", and will have a single data source. So, let's first set up a Blog entity and a mock data set.

To do so, let's create the entity component first using the command:

bit create node entities/blog

You should see the output shown below:

Figure: Creating the Blog Entity Component

Next, let's define the entity component by adding the following code to the blog.ts file:

/**
 * An entity class that represents a Blog
 */
export class Blog {
  /**
   * the id of the blog post
   */
  private _id: string

  /**
   * the title of the blog
   */
  private _title: string

  /**
   * the plot of the blog (summarized version of the content)
   */
  private _plot: string

  /**
   * the day the blog was published - in milliseconds
   */
  private _publishedDate: number

  constructor(id: string, title: string, plot: string, publishedDate: number) {
    this._id = id;
    this._title = title;
    this._plot = plot;
    this._publishedDate = publishedDate;
  }

  getId() {
    return this._id;
  }

  getTitle() {
    return this._title;
  }

  getPlot() {
    return this._plot;
  }

  getPublishedDate() {
    return this._publishedDate;
  }
}

Now that we have an entity component, we can share this across all other components we create. This includes the sample data along with the other API Route components.

So, next, let's create the Sample Data component using the command:

bit create node mocks/sample-data

Next, open the file sample-data.ts and include the code:

import { Blog } from '@dummyorg/blog.entities.blog';

const data: Blog[] = [
  new Blog("001", "Sample Title 01", "Sample Plot 01", Date.now()),
  new Blog("002", "Sample Title 02", "Sample Plot 02", Date.now()),
  new Blog("003", "Sample Title 03", "Sample Plot 03", Date.now()),
  new Blog("004", "Sample Title 04", "Sample Plot 04", Date.now()),
  new Blog("005", "Sample Title 05", "Sample Plot 05", Date.now()),
]

export function sampleData(): Blog[] {
  return data;
}

As you can see, we're using the entity component that we created before.

The cool thing about this is that it will automatically check and update all of its usage whenever we change the entity component.

So, if we introduce a new field in the constructor for the Blog, the sample-data will fail its build in the Ripple CI as the component cannot handle the new change introduced into the Blog entity.

Next, if we head back to the development server and open the sample-data component, you should be able to see the component in action:

Figure: The Sample Data Component

Next, let's set up the two routes using the command:

bit create node routes/get-blogs routes/get-blog-by-id

This will create two Node components that will act as the two routes in our Express.js API:

Figure: Creating the Components

Next, you can define the implementations in the components as shown below:

// get-blogs.ts

import { Request, Response } from 'express';
import { sampleData } from "@dummyorg/blog.mocks.sample-data";

const blogs = sampleData();

export function getBlogs() {
  return blogs;
}

export function getBlogsRoute() {
  return {
    method: 'get',
    route: '/blogs',
    middlewares: [
      async (req: Request, res: Response) => {
        const results = await getBlogs();
        return res.json(results);
      },
    ],
  };
}



// get-blog-by-id.ts

import { Request, Response } from 'express';
import { sampleData } from "@dummyorg/blog.mocks.sample-data";

const blogs = sampleData();

export function getBlogById(id: string) {
  const blogById = blogs.find((blog) => blog.getId() === id);
  if (!blogById) {
    throw new Error('Blog not found')
  }
  return blogById;
}

export function getBlogByIdRoute() {
  return {
    method: 'get',
    route: '/blogs/:id',
    middlewares: [
      async (req: Request, res: Response) => {
        const { params } = req
        const results = await getBlogById(params.id);
        return res.json(results);
      },
    ],
  };
}

As you can see, we've not only implemented the business logic, but we've also exported two new "route" functions. These route functions create a middleware for each route and execute the business logic. We will leverage these middleware route functions in our API server to hook the routes to the app.

Next, head over to your development server to view the two components:

Figure: Get Blogs Component

Figure: Get Blog By ID Component

Step 04: Integrating the Routes to the API

Now that we've built our API routes let's hook the routes to the API. To do so, head back to your API Component and open the api-root file, and update the registerRoutes function with the code shown below:

import { getBlogByIdRoute } from '@dummyorg/blog.routes.get-blog-by-id';
import { getBlogsRoute } from '@dummyorg/blog.routes.get-blogs';

function registerRoutes(app: Application.Application) {
  const mockRoute = getMockRoute();
  // introduce new routes
  const routes = [mockRoute, getBlogByIdRoute(), getBlogsRoute()];
  routes.forEach(route => {
    app[route.method](route.route, route.middlewares);
  })
}

Next, all you have to do is launch the app by running the command:

bit run blog-api

Next, hit each endpoint to see the response:

Route - localhost:3000/blogs

Route - localhost:3000/blogs/001

And, there we have it! Our API is up and running, and it didn't even take 5 minutes!

Step 05: Sharing the API

Next, let's share the API for everyone to view and contribute using the command:

bit tag && bit export

This will automatically ship the components to the scope we created earlier and will kick off a Ripple Build.

Figure: The Ripple Build

As you can see, Ripple CI knows the entire component tree and how each component is used.

Step 06: Automated Builds with Ripple CI

Ripple CI not only builds your components but also tracks differences in the tree in which your component is being used and builds the tree to support the changes.

For example, let's update the get-blogs.ts route to return the following:

export function getBlogsRoute() {
  return {
    method: 'get',
    route: '/blogs',
    middlewares: [
      async (req: Request, res: Response) => {
        const results = await getBlogs();
        return res.json({ results }); // Return JSON now.
      },
    ],
  };
}

We've update the res.json line to return a JSON object of results. Let's sync this change to the cloud using the command:

bit tag && bit export

Next, head over to Ripple CI to see the build:

Figure: Ripple Build for Diff

As you can see, Ripple identified that get-blogs had changed, and as a result, it built the application as well. This ensures that our app is always up to date.

Furthermore, you can extend the deployment to ship your app off to servers for hosting automatically!

Wrapping up

Well, that was interesting. It's not every day that we build Express apps in under 5 minutes!

If you like what you see, check out the full implementation, which includes unit-testing and component composition development - all in my Bit Cloud Scope.

I hope you found this article helpful.

Thank you for reading.

Learn More

How To Update Multiple NPM Packages Effectively? | Lakindu Hewawasam | Bits and Pieces | Bits and Pieces

Use Bit to ensure that your NPM packages are always up-to-date

blog.bitsrc.io

Building a PDF Generator using AWS Lambda

Lakindu Hewawasam — Sat, 08 Oct 2022 09:05:21 +0000

Using AWS Lambda, Amazon SQS, Amazon API Gateway, Amazon S3, AWS Lambda Layers and Pulumi to Build a Scalable PDF Generation Service

Almost all modern web applications use PDFs. For example, an application may utilize PDFs to send an email of an invoice for payment confirmation, a report or even a custom-typed document. For example, SignRequest uses PDFs to email a copy of a signed PDF document when all participants sign it. Likewise, there will come a time when you need to implement a PDF generator on your application as well.

Therefore, as a serverless developer, it’s important to ensure that you can design scalable and resilient PDF generation solutions for applications.

The Easy Way Out: Front-End Generation

When tasked with PDF generation, a go-to option would be to generate the PDF on the client side with the available data. For example, if you’re using React, you might have used @react-pdf/renderer to compile a PDF and download it directly in the web browser. Though it creates a fast and efficient process, it does have its set of negatives. For example:

There is no authenticity: Since the PDF is being generated on the client side, the software product has no say in what gets compiled in the PDF. A user can easily tamper with the HTML content beforehand and compile the PDF in the client application before sending it to the backend.

There is no traceability: You aren’t able to keep track of the location and the device that was used to create the PDF.

There is no security: You cannot sign a document on the client side without exposing your private key. However, if you choose to sign your document on the client side, you will be putting your keys at risk of exposure.

It does not scale: If your user is using a low-end device (or even Internet Explorer), your libraries may not be able to generate the PDF efficiently.

Designing PDFs using the client-side approach is suitable for large-scale, demanding applications due to the discussed negatives.

The Best Way Out - Server-Side Generation

The recommended approach for PDF generation is to use the server side. This ensures that a client can obtain a copy of the PDF in a highly secure manner.

Additionally, serverless computing helps you design and develop solutions that are highly available, resilient and cost-efficient.

A Resilient, Scalable PDF Generation Architecture for Serverless

Therefore, let us take a look at the serverless architecture for the solution that we will be building for the PDF service.

The architectural diagram shown above utilizes the AWS Serverless ecosystem to build a PDF generation service. It has:

An API Gateway - For clients to request a PDF.
An SQS Queue - The API Gateway will be integrated with a Lambda function that pushes data to an SQS Queue. This helps decouple the AWS Lambda function that generates the PDF, allowing the function to independently scale and not run out of possible concurrency limits. It allows the implementation of the Queue-Based Load Levelling Design Pattern.
An S3 Storage Bucket - To store the generated PDF
SES - To email the signed URL to the client.
DLQ - A Dead Letter Queue to handle error messages. The SQS Queue will push the failed messages to a DLQ if the Lambda processing a message fails a defined number of times.

Implementing the PDF Generation Service

There are several ways this infrastructure can be provisioned. It could be:

Using the SDK
Using the GUI
Using Infrastructure as Code

We will be using the IaC approach with Pulumi. Pulumi is an IaC tool that enables developers to provision infrastructure using their favourable programming language. It directly deploys infrastructure using the typed language, rather than transpiling back to CloudFormation, which makes your deployments a bit faster.

Therefore, this implementation will be using Pulumi.

Creating a Pulumi Project

Initially, a new Pulumi project will be initialized using the Pulumi CLI. Ensure you've installed the CLI and have configured an IAM User with an Access Key in your AWS Profile.

Run the command shown below to create a new Pulumi project with TypeScript in a default dev stacks in your preferred AWS Region (mine is US East 01).

pulumi new aws-typescript

Figure - Creating a new Pulumi Project

Afterwards, you should see the output shown below.

Figure - Creating the Pulumi Project successfully

Hereafter, we can start provisioning the required infrastructure.

Defining the Infrastructure

The source code will be structured into directories where each directory holds a specific service. Hence, the project will have four directories:

ses
sqs
lambda
api

Provisoning the SQS Queues

Firstly, the two SQS queues will be provisioned. One queue will act as a DLQ while the other queue will integrate with the API Gateway.

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

const deadLetterQueue = new aws.sqs.Queue("deadLetterQueue", {
  name: "deadLetterQueue",
  visibilityTimeoutSeconds: 120, // 2 minutes visibility timeout

  messageRetentionSeconds: 1209600, // remove messages in DLQ after 14 days
});

const pdfProcessingQueue = new aws.sqs.Queue("pdfProcessingQueue", {
  name: "pdfProcessingQueue",
  // 1 minute visibility timeout for processing// within 1 minute -> create PDF, upload to S3, send a message, delete message from queue// else it will be visible again and can cause double processing, 

  visibilityTimeoutSeconds: 60,
  messageRetentionSeconds: 86400, // remove messages in queue after 24 hours

  fifoQueue: false,

  delaySeconds: 10, // delay message for 10 seconds to avoid possible lambda limits.

  // redrive policy to push to DLQ after message fails three times

  redrivePolicy: deadLetterQueue.arn.apply((arn) => JSON.stringify({
    deadLetterTargetArn: arn,
    maxReceiveCount: 3,
  }))
});

 export const Queues = {
  deadLetterQueue,
  pdfProcessingQueue,
};

The snippet shown above highlights the two SQS Queues set up. I've made certain design decisions when designing the queues

All messages in DLQ will be removed after 14 days
All messages in PDF Processing Queue will be removed after 1 day, while each message will have a visibility timeout of 1 minute (assuming that the entire process will occur in under a minute)
Additionally, each message has a delay message for 10 seconds to allow the Lambda function to process each Queue record without exceeding possible limits.

Adding a Lambda Function to Poll The PDF Processing Queue

Once the PDF Processing Queue recieves a message, it needs to be processed. To do so, a Lambda function must poll the queue to fetch records to process. Setting up a Lambda function that polls the SQS queue is as simple as its shown below (since Pulumi takes care of the underlying IAM Policies).

However, since this Lambda function generates a PDF of a file, it needs two things:

A Chromium Engine: Needed to create an HTML Page, paint the PDF
SDK to control the chromium browser: Needed to control the rendering engine to create the HTML page, paint the PDF and to fetch the compiled PDF stream.

A browser rendering engine such as chromium is quite large in size. In fact, there is one library available for AWS in specific called chrome-aws-lambda that provides a Chromium Rendering Engine + Puppeteer to control the browser. This allows users to seamlessly generate PDFs inside a Lambda function.

However, this library is around 65MB which is typically quite heavy for a single Lambda function. Therefore, we can utilize a Lambda Layer to package this library as a seperate resource and ultimately use it in any Lambda function that we need, by simply including the layer.

Therefore, first download the library and package it using the command below. This will package it in the format needed for the Lambda Layer.

git clone --depth=1 https://github.com/alixaxel/chrome-aws-lambda.git && \
cd chrome-aws-lambda && \
make chrome_aws_lambda.zip

The chrome_aws_lambda.zip will be the file that we will be uploading to our layer. It creates a folder structure like nodejs/node_modules that is the recommended directory structure to allow Lambda functions to let users automatically import the library at execution time.

Hereafter, provision the lambda layer as below.

const pdfLayer = new aws.lambda.LayerVersion("pdfLayer", {
    layerName: "pdfLayer",
    code: new pulumi.asset.AssetArchive({
        ".": new pulumi.asset.FileArchive("./lambda/layer/chrome_aws_lambda.zip"),
    }),
    compatibleRuntimes: [aws.lambda.Runtime.NodeJS16dX],
});

Hereafter, we can create a Lambda Function that uses the defined layer and integrate it with SQS as shown below.

// in lambda directory
export const pdfProcessingLambda = new aws.lambda.CallbackFunction("pdfProcessingLambda", {
    callback: async (event: aws.sqs.QueueEvent) => { },
    memorySize: 3072, // use 3gb memory
    runtime: aws.lambda.Runtime.NodeJS16dX,
    timeout: 30,
    layers: [pdfLayer.arn] // bind layer
});

// in sqs directory
pdfProcessingQueue.onEvent("pdfProcessingQueueEvent", pdfProcessingLambda);

Adding the PDF Generator Logic

In the snippet shown above, we've provisioned a Lambda function named "pdfProcessingLambda". We can add its implementation that helps compiled the pdf. This is shown below.

const generatePdf = async (content: string): Promise<Buffer> => {
  const chromium = require('chrome-aws-lambda');
  let browser: any = undefined;
  try {
    // launch a headless chrome instanceconst executablePath = await chromium.executablePath;
    browser = await chromium.puppeteer.launch({
      args: chromium.args,
      executablePath,
      headless: chromium.headless,
      defaultViewport: chromium.defaultViewport,
    });

    // create a new page

const page = await browser.newPage();const html = `<h1> Hi! Here is a copy of your PDF Content that you requested!</h1> <br/> <hr/> <p> ${content} </p>`; 
// set the content of the page

await page.setContent(html);

    // generate the pdf as a buffer and return it

return (await page.pdf({ format: "A4" })) as Buffer;
  } catch (err) {
    console.error(err);
    throw err;
  } finally {
    if (browser !== undefined) {
      // close the browser
await browser.close();
    }
  }
};

A function (shown above) will accept content passed from the client and utilize chromium to generate the PDF via puppeteer. It initially launches an instance of chrome, sets the page content and returns a Buffer as an A4 (which holds the PDF).

The Lambda function code will be updated to utilize this function.

export const pdfProcessingLambda = new aws.lambda.CallbackFunction("pdfProcessingLambda", {
  callback: async (event: aws.sqs.QueueEvent) => {
    const processedEventPromises = event.Records.map(async (record) => {
      const { messageId, body, receiptHandle } = record;
      const { content, email } = JSON.parse(body) as {
        email: string;
        content: string;
      };

      // generate pdfconst pdf = await generatePdf(content);

      const pdfName = `${messageId}.pdf`;

      // upload pdf to s3

      const s3 = new aws.sdk.S3({ region: "eu-central-1" });
      await s3.putObject({
        Bucket: pdfBucket.bucket.get(),
        Key: `pdf/${pdfName}`,
        Body: pdf,
        ContentType: "application/pdf",
      }).promise();

      // generate signed url from s3 for public reads.

      const signedUrl = await s3.getSignedUrlPromise("getObject", {
        Bucket: pdfBucket.bucket.get(),
        Key: `pdf/${pdfName}`,
        Expires: 60 * 60 * 24 * 7, // 7 days
      });

      // send email with signed url

     const ses = new aws.sdk.SES({ region: "us-east-1" });

      await ses.sendEmail({
        Source: senderEmail,
        Destination: { ToAddresses: [email], },
        Message: {
          Body: { Html: { Charset: "UTF-8", Data: `Your pdf is ready. <a href="${signedUrl}">Download</a>`, }, },
          Subject: { Data: "Your pdf is ready", Charset: "UTF-8" },
        },
      }).promise();

      // delete message from queue

      await sqs.deleteMessage({ QueueUrl: Queues.pdfProcessingQueue.url.get(), ReceiptHandle: receiptHandle }).promise();
      console.log(`Deleted message ${messageId} from queue`);
    });
    await Promise.all(processedEventPromises);
  },
  memorySize: 3072,
  runtime: aws.lambda.Runtime.NodeJS14dX,
  timeout: 30,
  layers: [pdfLayer.arn],
  policies: [ManagedPolicies.AmazonSESFullAccess, ManagedPolicies.AmazonS3FullAccess, ManagedPolicies.AmazonSQSFullAccess, ManagedPolicies.AWSLambdaBasicExecutionRole, ManagedPolicies.CloudWatchFullAccess],
});

The PDF generated by the function will then be used in the Lambda function shown above and will upload it to S3 and return a signed URL for the client via an email so that the client can read the PDF.

NOTE: Ensure that the identities that you are using via SES have been created as verified identifies.

The snippet shown above utilizes an S3 bucket. This bucket will be used to store the PDFs and must be restricted from zublic access and can only be accessed via signed URL. Its implementation with the required resource based policies is shown below.

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

const provider = new aws.Provider("provider", { region: 'eu-central-1' });

export const pdfBucket = new aws.s3.Bucket("pdf-bucket-lak", {
    bucket: "pdf-bucket-lak",
    acl: 'private',
    policy: JSON.stringify({
        Version: "2012-10-17",
        Statement: [
            {
                Sid: 'AllowPutObjectForLambda',
                Effect: 'Allow',
                Principal: {
                    Service: 'lambda.amazonaws.com'
                },
                Action: 's3:PutObject',
                Resource: `arn:aws:s3:::pdf-bucket-lak/pdf/*`
            },
            {
                Sid: 'AllowGetObjectForLambda',
                Effect: 'Allow',
                Principal: {
                    Service: 'lambda.amazonaws.com'
                },
                Action: 's3:GetObject',
                Resource: `arn:aws:s3:::pdf-bucket-lak/pdf/*`
            },
        ],
    }),
}, { provider });

The bucket is being provisioned on AWS Global Infrastructure and has the resource based policies to only allow writes from a Lambda function, and denying all public reads.

Provisioning the API Gateway

An API Gateway which invokes a Lambda function that pushes data to an SQS Queue will be provisioned.

import * as awsx from "@pulumi/awsx";
import * as aws from "@pulumi/aws";
import { Queues } from "../sqs";

const sqs = new aws.sdk.SQS({ region: "us-east-1" });

export const apiGateway = new awsx.apigateway.API("api", {
  routes: [
    {
      path: "/pdf",
      method: "POST",
      eventHandler: async (event) => {
        // client passes email and content to add to pdf

        const { email, content } = JSON.parse(event.body || "{}");

        // construct message to send to SQS

        const sqsParams = {MessageBody: JSON.stringify({ email, content }),QueueUrl:  Queues.pdfProcessingQueue.url.get(),
        };

        // send message to SQS

        const resp = await sqs.sendMessage(sqsParams).promise();
        const { MessageId } = resp;

        // return message id to client for tracking purposes

       return { statusCode: 200, body: JSON.stringify({ MessageId }) };
      },
    },
  ],
  restApiArgs: {
    binaryMediaTypes: [],
  },
});

The snippet shown above highlights an API Gateway being provisioned with one endpoint /pdf that has a Lambda function that obtains the email and content sent by client and pushes it to the queue. Finally, it returns the message ID that the client can use to track the status of the message.

Deploying

Navigate to the index.ts file and import all added infrastructure so the Pulumi Deployment Service can deploy it.

import { Queues } from "./sqs";
import { apiGateway } from "./api";

export const dlqUrl = Queues.deadLetterQueue.url;
export const pdfProcessingQueueUrl = Queues.pdfProcessingQueue.url;
export const apiGatewayUrl = apiGateway.url;

Finally, you can deploy the infrastructure using the command pulumi up --stack dev -skip-preview --yes.

Upon successful deployment, the output shown below will be illustrated.

Figure - Deploying the infrastructure

Testing the Application

Hereafter, you can use the apiGatewayUrl to invoke the API as shown below and observe the architecture in action, and generating a PDF which will be emailed to you.

Figure: Executing the API Call

Figure: Receiving the email

Figure: Viewing the generated PDFs

Wrapping Up

And there we have it! We've successfully designed and implemented a secure, robust, resilient and scalable PDF generation service using AWS Serverless Computing!

The code implemented in this article is accessible in the GitHub repository.

I hope you that have found this article helpful!

Thank you for reading!