chrome-aws-lambda VS serverless-webpack

Lambda would be my choice for this. You could even stay within the free tier depending how often you run this process. You can orchestrate puppeteer UI flows in lambda using this package https://github.com/alixaxel/chrome-aws-lambda My team does this and it works great.

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

When requesting the API route, the Next.js serverless function will actually spin up a web browser on the server (a headless instance of Chromium, using chrome-aws-lambda). Next, a webpage will be generated with HTML we can define ourselves. This HTML will be used to construct the image. That means that as a developer we can generate images using HTML and CSS, technologies we are already familiar with!

This plugin is used for all our AWS Lambda deployments, using a wide range of Node modules, some with more quirks than others. We use it together with Lambda Layer Sharp and Chrome AWS Lambda.

I was able to successfully to run chrome with puppeteer in AWS Lambda for a similar use case. I used an "optimized" version of chrome packaged as an AWS Lambda Layer.

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

Simplest method use ]Puppeteer](https://blog.risingstack.com/pdf-from-html-node-js-puppeteer/) with chrome-aws-lambda.

Since I was using serverless-webpack along with Prisma's serverless-webpack-prisma helper, this meant a bit of extra Webpack config setup to get it all using the same module syntax without the usual dreaded 'Unexpected token export' or import error from Node.

As you can see in the above handler.js file, we're getting CommonJS instead of modern JavaScript or TypeScript. To get these, you need webpack or some other bundler. serverless-webpack exists if you want full control over your ecosystem, but there is also serverless-bundle that gives you a set of reasonable defaults on webpack 4 out of the box. We opted into this option to get us started quickly.

cd app-backend/dynamodb yarn install To test the GraphQL endpoint locally on my machine, I’m using these three plugins for the Serverless Framework: Serverless Offline, Serverless Webpack and Serverless DynamoDB Local.

Serverless Webpack

The serverless framework supports an excellent workflow with the serverless-webpack plugin to package your functions individually with webpack. For AWS SAM, it's probably worth checking out the aws-sam-webpack-plugin, but I've found it far simpler to configure esbuild to perform the same task.