serverless-express VS Nest

After building out a GPT powered endpoint, I wanted a low cost way of hosting it. At the time, I came across the serverless-express project https://github.com/vendia/serverless-express/tree/mainline, but no actual starter kits that would allow me to deploy it.

It’s all handled using https://github.com/vendia/serverless-express

Amplify gives an option of using a template and linking the API Endpoint with the Lambda and a connected DynamoDB table. I selected the template, Serverless Espress, which provided a lot of code in the template, though the majority of it felt overly bloated for what was effectively CRUD functionality.

With that in mind, the goal of this library is to be as lightweight as possible. There are other libraries out there that can handle express -> serverless mutation. See Serverless Express for that. If you want to rewrite as little code as possible, that is your best solution. With that being said, if the sole purpose of express is middleware and is only hosting a one-endpoint GraphQL server, I recommend rewriting to utilize this library.

To get Express to run on AWS Lambda the Node http stack needs to be emulated, or a full-blown HTTP/TCP server needs to be started and proxied to. Each of these workarounds require a ton of code from libraries like serverless-express.

Express is a framework/software. Lambda is compute. You can run express in Lambda. Ive done this and it was great. Check out https://github.com/vendia/serverless-express. The cool thing is that it's portable - you can build for one compute environment, and move it to another if it doesnt suit

Yea its fine use https://github.com/vendia/serverless-express since you are using express

Serverless Express - library that makes our "plain" NestJS API play nicely with Serverless

Some people like the Unix philosophy of "Do one thing and do it well" for Lambdas, others would build a monolithic app using a single Lambda with built in "routes". Both designs have pros and cons.

When using the NestJS framework, sometimes you may need to change some default timeout. You can define them just like you'd do in a plain Node.js HTTP server like so:

Back: a graphQL server built with Nestjs

NestJS - opinionated more scalable, but harder to learn docs

Pragmatically, we can apply this to a Nest application by creating an Interface for our services, separating the Presenter layer (Controller) from the Use Case (Services):

It’s a text document that contains all the commands a user could call to assemble an image. Let’s check an example of a Dockerfile for a nodejs app in this case it will be a NestJS app and then explain each part.

describe('Create bookmarks', () => { const dto: CreateBookmarkDto = { title: 'NestJS', link: 'https://nestjs.com/', }; it('should create bookmark', () => { return pactum .spec() .post('/bookmarks') .withHeaders({ Authorization: 'Bearer $S{userAt}', }) .withBody(dto) .expectStatus(201) .stores('bookmarkId', 'id')//store the bookmark id in the variable bookmarkId .expectBodyContains(dto.title) .expectBodyContains(dto.link) }); });

In my usual NodeJS tech stack, which includes GraphQL, NestJS, SQL (predominantly PostgreSQL with MikroORM), I encountered these limitations. To overcome them, I've developed a new stack utilizing Rust, which still offers some ease of development:

The purpose of this article is to provide a step-by-step guide for implementing authentication system in a NestJS project using the Passport middleware module.

That's exactly where I am. My manager gave me these links, that cover a lot of those words the backend uses, so I can identify what they mean and how to use them. 1. For inspiration and concepts: https://github.com/Sairyss/domain-driven-hexagon 2. Suggested to read the documentation for nest.js. They apply such concepts I don't understand: https://nestjs.com/