DEV Community: Henrique Weiand

Running NestJS in a Lambda function with LocalStack and Serverless Framework

Henrique Weiand — Sun, 23 Feb 2025 17:41:05 +0000

Hey there, tech enthusiasts! Ever found yourself needing a quick and efficient way to whip up QR codes for your projects? Well, in today's blog post, we will cover an awesome solution that brings together NestJS and AWS Lambda, all while keeping things super smooth with the Serverless Framework and LocalStack.

In this post, we’ll dive into on nestjs-lambda-qrcode-generator-with-local-stack project that tackles real-world challenges by turning NestJS applications into Lambda functions. We’ll also see how the Serverless Framework makes deploying these functions a breeze and how LocalStack lets you test everything locally without breaking a sweat.

Whether you’re a seasoned developer or just starting out, this guide will show you how to create a scalable, serverless QR code generator that’s ready for any project you throw at it. Let’s get started!

Local Stack and Serverless ⚔

It's important to give some context before going deeper into the two technologies that are applied to the project

LocalStack is a powerful tool that emulates AWS services on your local machine, enabling developers to test and develop cloud applications without the need to deploy them to the actual AWS environment. This local emulation accelerates development cycles and reduces costs associated with cloud deployments.
The Serverless Framework is a popular open-source framework that simplifies the deployment and management of serverless applications across various cloud providers, including AWS. It streamlines the process of defining and deploying serverless functions, making it easier for developers to build scalable applications.

By integrating LocalStack with the Serverless Framework, developers can deploy and test their serverless applications locally, ensuring that everything works as expected before moving to the cloud. This combination provides a seamless workflow for building, testing, and deploying serverless applications efficiently.

Running a NestJS project on lambda 🚀

Running a NestJS application on AWS Lambda allows you to build serverless applications that automatically scale and reduce infrastructure management. By using tools like @vendia/serverless-express, you can adapt your NestJS app to function within the Lambda environment, handling cases like HTTP requests, cron-jobs, processing tasks internally by demand, and so on. This setup enables you to focus on developing features without worrying about server maintenance, as AWS manages the underlying infrastructure for you.

NOW A BIG BUT! Running a NestJS application on a lambda function has its disadvantages, and the biggest is the cold start. As big as your application gets with the usage of libraries, connections, async/await executions, or just because the project is complex and big, it can take more time for the lambda to start responding to a request or any execution. It depends on the context, so it is recommended to pay attention to the requirements to design a better solution.

I recommend you access the official NestJS documentation (https://docs.nestjs.com/faq/serverless), and spend a few minutes reading from the top to bottom. There are some important points about how to make the standalone application and also benchmarks with different approaches. A simple example is how you define your application:

// #2 Nest (with @nestjs/platform-express)
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule, { logger: ['error'] });
  await app.listen(process.env.PORT ?? 3000);
}
bootstrap();

// #3 Nest as a Standalone application (no HTTP server)
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { AppService } from './app.service';

async function bootstrap() {
  const app = await NestFactory.createApplicationContext(AppModule, {
    logger: ['error'],
  });
  console.log(app.get(AppService).getHello());
}
bootstrap();

See that we have an application without an HTTP server that will respond faster.

For every solution, there will always be pros and cons, so think about the architecture before starting coding like crazy!

Getting into the project 🎯

https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator-with-local-stack

If you ask me how I come up with ideas for projects, I keep an eye on the websites with job opportunities, like Upwork, not because I want to get a job, but eventually, I find good ideas for projects (simple ones of course) that I can use as a context to practice, and this project was one of that cases.

Context

This is quite a simple project, the job description required a Lambda function that was able to receive a GET request and through the query params, a URL that should be used to build the QRCode. The QRCode should be storeged into an S3 bucket with a public link.

I did this idea two times, the first one I didn't wrote anything about, but, the first version was working only with Serverless, and the new one is working with both Serverless Framework and LocalStack, which makes everything much more real. This is the link of the first version → https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator

Ok, as I quickly explained before, we generate different types of NestJS instances, and with those requirements, I knew I needed an HTTP server, so that's why I am applying NestFactory.create

https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator-with-local-stack/blob/master/src/serverless.ts

By the way, you will see two starting points, I mean, both serverless.ts and main.ts, and each one of them is creating a NestJS instance. The reason is that I wanted to be able to test it outside the Serverless and Local Stack, like a normal NestJS app, so the main.ts is executed as a normal NestJS application, while the serverless.ts is used for the Serverless Framework.

The starting point for the Serverless framework is the serverless.yml, which holds the recipe of the application, for example, the application needs to run in a lambda function, this method needs to be able to receive POST or GET requests, and it uses S3 and the AWS IAM roles should be XPTO… got it?

https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator-with-local-stack/blob/master/serverless.yaml

It is important to mention the initial method called by the lambda when executing. In this case, it is serverless.handler which matches with https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator-with-local-stack/blob/master/src/serverless.ts

At this point I know you want to see the Lamda function running, but, I suggest making the application work first, so you can reduce the doubts that you might have when running the Lamda and seeing unexpected issues happen.

Code structure 🧠

There's no right or wrong in terms of how to organize the application modules and files, so, create your application as you want, mine ended up like this

The controller holds one route and receives a query parameter which will be the URL

https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator-with-local-stack/blob/master/src/qr/qrcode.controller.ts

And then QRCodeService only receives the URL and generates the QRCode, and then, the qrCodeBuffer is passed down to the s3Service for the upload.

The s3Service has a few details, for example, when it's running for production it is not getting the ENV files because the lambda will use the roles applied for the service itself.

https://github.com/henriqueweiand/nestjs-lambda-qrcode-generator-with-local-stack/blob/master/src/qr/s3.service.ts

Running the project with and without Local Stack 🦾

Instead of writing more, I decided to make a video with the 3 possible ways to run the application, they are:

Running a normal NestJS application;
Running NestJS Application with Serverless Framework + serverless-offline + serverless-s3-local;
Running NestJS Application with Serverless Framework + Local Stack;

Conclusion 👨🏼‍🔧

In this journey, we’ve explored how to build a scalable, serverless QR code generator using NestJS, AWS Lambda, the Serverless Framework, and LocalStack. By integrating these technologies, you can efficiently develop, test, and deploy applications that meet real-world needs without the hassle of managing server infrastructure. Remember to consider the specific requirements of your project, such as the necessity of an HTTP server, and be mindful of potential challenges like cold starts in Lambda functions. For more insights and detailed guidance, refer to the official NestJS documentation on serverless applications. Embrace these tools to streamline your development process and deliver robust solutions with ease.

Takeaways

Pay attention to the necessities of your application, for instance, using HTTP or not;
Add logs, it helps to debug the Lambda on the providers, even console.info, error, …
Use as less libraries as possible;
Keep the project simple, don't put lots of responsibility for each lambda;
A Monorepo approach can help to share a common code while different lamdas;
Be aware of the final size of your project, the providers have limits - https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution;
Read the official documentation to get the most of different approaches to reduce the size and perform the project https://docs.nestjs.com/faq/serverless

Implementing Kubernetes Jobs with NestJS and nest-commander: A Practical Guide (Ex. implementation with Ticketmaster)

Henrique Weiand — Tue, 18 Feb 2025 20:30:37 +0000

Hey there! Ever found yourself knee-deep in building NestJS applications and thought, “Man, I wish I could bring this awesome structure to my command-line tools”? Well, you’re in luck! The nest-commander package does just that, letting you craft CLI applications with the same NestJS flair you know and love.

But wait, there’s more! Imagine taking these slick CLI apps and running them as jobs in a Kubernetes environment. Sounds like a dream, right? That’s where the nestjs-job-commander repository comes into play. It’s a nifty example showing how to set up a job processing system using NestJS and nest-commander, all within Kubernetes.

In this article, we’ll explore the details of this setup, breaking down the implementation so you can try it out yourself. Let’s get started!

https://github.com/henriqueweiand/nestjs-job-commander

Technologies used 🛠️

NestJS: A progressive Node.js framework for building efficient and scalable server-side applications.
nest-commander: A NestJS module that facilitates the creation of CLI applications with a structure similar to typical NestJS applications. Find out more about it https://docs.nestjs.com/recipes/nest-commander
TypeORM: An ORM for TypeScript and JavaScript that supports various databases. Find out more about it https://docs.nestjs.com/recipes/sql-typeorm
Kubernetes (k8s): An open-source system for automating deployment, scaling, and management of containerized applications.
Monorepo: A repository structure that holds multiple projects, allowing for shared code and unified project management. Find out more about it https://docs.nestjs.com/cli/monorepo

Repository Structure 🗺️

The repository is organized as a monorepo, containing multiple projects and shared libraries. Key components include:

apps/cli-enricher: The CLI application is built with NestJS and nest-commander.
libs: Shared libraries utilized by the CLI application.
k8s: Kubernetes configuration files for deploying the job.
Dockerfile: Defines the Docker image for the CLI application.
.env: Environment variables configuration file.

In this repository, we will get into just one CLI, but you can have as many as you need.

CLI Enricher

Similar to a traditional NestJS application, an application with NestJS Commander is set up quite simply. In the main.ts we define the bootstrap method

https://github.com/henriqueweiand/nestjs-job-commander/blob/master/apps/cli-enricher/src/main.ts

Then, we need to create the AppModule, which will require the base modules like ENV Module, Database connection, and also the module for your CLI, in this case, I just have one, but, if you have more, don't forget to add them here!

https://github.com/henriqueweiand/nestjs-job-commander/blob/master/apps/cli-enricher/src/app.module.ts

The AppModule needs to export the main command, that's why there's an export. Opening the CliCommand, you will notice a base structure for a general CLI command, and the reason it is quite basic is that this project is not using the root command, it is using subCommands. There's no big reason for that, I decided to use it as a subcommand instead of a root, but I will detail more about it later.

https://github.com/henriqueweiand/nestjs-job-commander/blob/master/apps/cli-enricher/src/cli-command.ts

I'm going to explain more about how to use the root command at the end of the article, for now, let's stick to the app context.

Yet inside the CliCommand, we need to define the subCommands, and then it is necessary to add the command file of that.

https://github.com/henriqueweiand/nestjs-job-commander/blob/master/apps/cli-enricher/src/cli-command.ts

This is the core of our CLI Enricher. In this file, we define the command name

@SubCommand({ name: 'ticketmaster-event-refresh' })

TicketMasterEventRefreshCommand holds the logic of our CLI Job. The job gets the events from the Ticket Master API, verifies whether the event exists or not, and stores it. Again, the logic is not the focus of the post, but how to manage Nest Commander inside the Kubernetes.

https://github.com/henriqueweiand/nestjs-job-commander/blob/master/apps/cli-enricher/src/ticketmaster-event-refresh/ticketmaster_event_refresh.command.ts

By using subCommands, in the end, we will execute it like this

-- cli ticketmaster-event-refresh

Running the job - outside k8s

In case you need to test the application before putting it inside the k8s, which I strongly recommend. You can do that by running the command

nest start --watch -- cli ticketmaster-event-refresh

⚠️ Make sure you have everything that your application needs to run ready, for example, the database instance and the tables.

This project has a how-to-run section in the README file to help you to run this example locally without any issues.

Running the job - inside k8s

So far, we have a NestJS application with NestJS Commander, and we know that the application works! The next step is putting the app inside a Pod in the k8s, and for that, we will need to create two things!

The docker image;
Kubeclt file for the cronjob;

For the docker image, we only need to run

docker build -t ticketmaster-event-refresh-job .

The command will build the Dockerfile available at the root level, and this Dockerfile doesn't have anything different from any other NestJS application with docker, but, feel free to take a look.

Next, change the .env file and add the following envs

CLI-ENRICHER.HOST=host.docker.internal
NODE_ENV=production

Since we are going to run the app inside the cluster, we need to set the correct host to make it able to reach the database. The NODE_ENV with the production value is required because of the logic for the EnvModule.

Now, create a config map inside your cluster. Run the command

kubectl create configmap env-config --from-env-file=.env

This command will create a config map and add the .env variables inside it. We will need the .env to run the application inside the cluster.

The last step is running the kubeclt command. Go to the k8s folder and execute

kubectl apply -f cronjob.yaml

In case you want to know, the cronjob.yaml is a spec file to create a job inside the k8s.

https://github.com/henriqueweiand/nestjs-job-commander/blob/master/k8s/cronjob.yaml

The job is being set to run each minute, and it follows the same sequence of commands as we tested outside the k8s previously.

command:
  - node
  - dist/apps/cli-enricher/main.js
  - cli
  - ticketmaster-event-refresh

I recorded a video to help you to run everything in case is needed!

Conclusion

And there you have it! With NestJS Commander and Kubernetes, you can seamlessly build and deploy CLI applications using the familiar NestJS structure. This setup allows you to manage jobs efficiently, whether running them locally or within a Kubernetes cluster.

By leveraging subCommands, Docker, and Kubernetes CronJobs, we’ve created a system that can scale and automate job execution while maintaining flexibility. If you’re working on task automation, scheduled jobs, or batch processing, this approach can help you streamline your workflow.

I mentioned earlier that I’d dive deeper into root commands and parameter handling—don’t worry, that’s coming in a future post! Stay tuned, and in the meantime, feel free to check out the nestjs-job-commander repository and try it yourself.

Got questions or feedback? Drop a comment or reach out—I’d love to hear your thoughts! 🚀

NestJS Vienna Meetup: Multi-Tenancy & Module Management

Henrique Weiand — Sat, 08 Feb 2025 16:07:23 +0000

The NestJS community recently gathered in Vienna for an insightful meetup featuring talks on multi-tenancy patterns and module management in NestJS. As the ecosystem continues to evolve, meetups like these play a crucial role in knowledge sharing and community growth. If you missed the event, don’t worry—I'll break down the key takeaways and connect them to a deep dive I previously wrote on multi-tenancy with NestJS and TypeORM.

Insights from NestJS Vienna

Multi-Tenancy in NestJS – Dustin Chabrowski

Dustin Chabrowski delivered a talk on multi-tenancy patterns in NestJS, a crucial architecture for SaaS applications and enterprise solutions. He explored different approaches, including database-per-tenant, schema-per-tenant, and shared-database strategies. These approaches help businesses scale their applications while maintaining data isolation and performance.

For those unfamiliar, multi-tenancy is a system where a single application serves multiple tenants (clients), each with its own data segregation strategy. Choosing the right model depends on the complexity of your application, compliance requirements, and expected scalability.

In my previous blog post, NestJS, TypeORM, and Multi-Tenancy, I discussed how to implement multi-tenancy using TypeORM, covering practical solutions like dynamic database connections, middleware, and request-based context resolution. If you’re looking to implement this in your NestJS app, check it out!

Pragmatic Module Management – Maciej Sikorski

Another highlight was Maciej Sikorski’s talk on module management in NestJS. He shared strategies for keeping module dependencies under control, which is often an overlooked yet vital aspect of building scalable applications. Managing modules effectively ensures better maintainability, reduced circular dependencies, and improved testability.

Why This Matters for the NestJS Community

Both of these topics—multi-tenancy and module management—are fundamental to designing scalable and maintainable NestJS applications. Multi-tenancy enables robust SaaS architectures, while proper module management keeps applications clean and structured. By combining these insights, developers can create well-architected solutions that scale efficiently.

Resources

If you missed the meetup, you can still catch up on the talks:

🎥 Video Recording

📄 Slides

What are your thoughts on multi-tenancy in NestJS? Have you implemented it in your projects? Let’s discuss in the comments!

Real-time chat with NestJS and Socket.io

Henrique Weiand — Fri, 24 Jan 2025 17:59:48 +0000

Real-time communication is an intriguing topic, and I wanted to share my thoughts on it. I came across one of my old blog posts about micro frontends, where I developed an interface for a micro frontend chat feature that was shared across two other pages. In that project, I focused solely on the front end and interface without addressing the backend or ensuring everything functioned properly. So, what did I do next? I implemented the backend using NestJS with Socket.io to facilitate chat functionality among the different pages utilizing the micro frontend chat.

This is the old micro frontend project Building a system as lego with react and micro frontends

⚠️ Before we continue, I wanna let you know that this will be an important year for the blog, I am planning to start publishing more frequent blog posts and even videos! My advice for you is to subscribe to the page and don't miss any new publications or updates!

Target 🎯

I'm building a simple system without much complexity in terms of modules and services to handle the pure and basic functionality of sending and receiving messages among the users connected to the chat.

Backend project
https://github.com/henriqueweiand/nestjs-real-time-chat

Frontend project
https://github.com/henriqueweiand/nextjs-real-time-chat-with-micro-frontends

Starting point

I first created a project by using the NestJS CLI. With the project ready, I make a module with the command:

nest generate module chat

By the way, you can create the module manually if you want. Then, I created one more file called chat-gateway.ts with the content
https://github.com/henriqueweiand/nestjs-real-time-chat/blob/master/src/chat/chat-gateway.ts

For the chat project, I have a few functionalities in mind:

Notify when a user connects;
Notify when a user disconnects;
Broadcast the messages;

Let's go through some of the methods defined inside the chat-gateway to detail how the gateway is addressing the features.

ChatGateway is decorated with the WebSocketGateway, which words as equal to a provider, which means we also have to add it as a provider inside the chat.module. WebSocketGateway has properties that can be set as needed, and in our case, I allowed the cors to work with any page and I also changed the port (because I wanted to, but it is not necessary).

ChatGateway is implementing two interfaces, and those interfaces will allow us to implement two methods:

handleConnection
handleDisconnect

The name of the function is pretty self-explanation, right? One deals with new connections to the socket and the other for the disconnections.

The official documentation about WebSocketGateway is available https://docs.nestjs.com/websockets/gateways

handleConnection

As described in the official documentation: https://docs.nestjs.com/websockets/gateways#lifecycle-hooks the handleConnection receives an argument that is the library-specific client socket instance.

In this example, I am emitting a message to the event user-joined. Every client that is connected and listening to this event will know that somebody else joined. By the way, broadcast emits to everybody but the user who is joining, which is perfect for what we need!

handleDisconnect

This method also receives the client instance as a parameter, and for this example, the difference is that we are using the WebSocketServer instance to emit a message to everybody connected that someone left on the user-leftevent.

Dealing with all messages

The method handleNewMessage is decorated with SubscribeMessage and defines the main event for all the messages. The name of the function could be anything else, ok? Just to let you know. Same here as we did for the disconnect event, we are emitting the message received to everybody.

Frontend

The frontend project as I said previously, is the same as I implemented and described in this postBuilding a system as lego with react and micro frontends, so please take a look at the other blog post to get more details about the frontend project. I will just explain where I applied the changes to make the real-time part work.

Adding Socket.io to the frontend

This project runs three micro frontends, but there's one that is the chat component and the one that we have to apply the changes. All the changes were applied to this file
https://github.com/henriqueweiand/nextjs-real-time-chat-with-micro-frontends/blob/master/apps/chat/src/components/Chat/index.tsx

The changes made were:

socket.io-client library;
Initiated the connecting with the port that we defined on the Backend project;
Added the listening to all events defined on the backend
- user-joined
- user-left
- message
- newMessage
Minor changes to remove the old “bot replies”

It's quite easy to read the component and understand what is happening there.

Conclusion

This blog post was directly to the point and without much complexity. I didn't make an abstraction or anything else; I just created the Chat module and added all that I needed, so I recommend you review the module and gateway according to all your necessities.

I'm planning to continue this post soon with more details related to other features that are possible to apply to NestJS and Sockets.io

How to Integrate Multiple Payment Gateways in NestJS (With Stripe Example)

Henrique Weiand — Thu, 23 Jan 2025 12:52:22 +0000

One of the most common use cases that every project has is integrating and offering ways for the customers to pay for your software, which is quite important, isn't it?

This post will cover some interesting strategies for making it on the backend with NestJS. A simple level of abstraction will allow your project to integrate with multiple payment gateways and even allow the customer to pay with more than one method! Pretty cool, right?

⚠️ Before we continue, I wanna let you know that this will be an important year for the blog, I am planning to start publishing more frequent blog posts and even videos! My advice for you is to subscribe to the page and don't miss any new publications or updates!

Backend repository

https://github.com/henriqueweiand/nestjs-payment-gateway-integration

Frontend repository

https://github.com/henriqueweiand/nextjs-payment-gateway-integration

Defining the solution

This solution will implement a few layers to make the payment abstraction clear and reusable. It will perform payments with one or more Payment Gateways, in special with Stripe for the implemented example. I won't focus so much on the details, and more on how the solution works! It's important to mention, that this solution is not the perfect one and of course, it can be implemented in many different ways. There will be possible improvements to the solution that I will be commenting on the way.

Solution flow

The request flow starts at the Controller and goes through a few Modules and services.

A big picture of the solution is:

We are going to go deep down over a few of them to understand the solution starting by the Checkout.

Checkout

This module is responsible for receiving the input from the controller or any other service that ended up implementing it, and it deals with some important steps.

https://github.com/henriqueweiand/nestjs-payment-gateway-integration/blob/master/libs/components/checkout/src/checkout.service.ts

The only expose method in this service is processPayments, which performs:

It creates the checkout entity/record in the database. It's important because I want to have a common ID for one or many payments that will be processed;
It processes each one of the payment inputs individually;
It gets all successful and failed payments for that checkout;
It performs the refunds for those successful payments if any payment fails;
It updates the checkout status;

Before understanding the methods that process each one of the payments and the processors, it's important to know that the input that we received on the method processPayments has one attribute that payments which receives an array of SpecificPaymentInputs which allows us to receive multiple formats of inputs. This is an important detail because if any new gateway is integrated, SpecificPaymentInputs needs to be updated!

https://github.com/henriqueweiand/nestjs-payment-gateway-integration/blob/master/libs/components/checkout/src/checkout.interfaces.ts

Taking StripePaymentInput as an example, we have a class that implements an abstraction.

https://github.com/henriqueweiand/nestjs-payment-gateway-integration/blob/master/libs/components/checkout/src/stripe/dto/stripe-payment.input.ts

This abstraction requires the class to have two important fields that will be used before by the payment processor to identify the correct processor, they are processorType and paymentType, which are enum values also related to the payment gateways supported. In this initial example, I will implement Stripe and a fake/custom voucher integration.

OK! Let's return to the checkout.service and look at the private method _processOnePayment. This method is responsible for calling the PaymentProcessor which we will detail in a bit. Apart from the payment processor, we're just creating an object that holds the main information of the checkout.

Payment processor

The payment processor is the core logic behind external integrations like Stripe and the internal abstractions that deal with the processing itself. You'll notice that the PaymentProcessorsModule includes the providers for each one of the implementations which is the class that follows the abstracted PaymentProcessor. The module also includes the external modules for the logic of the integrations, for example, the Stripe methods to pay, refund, and so on.

Our starting point is the _processOnePayment where we call getProcessor method

this.paymentProcessorsService.getProcessor(paymentType, processorType);

This service and method hold a switch case logic that will map and return the proper processor for the payment informed (SpecificPaymentInputs). The returned class is the payment processor implementation for the specific payment gateway. Overall, the sequence of steps is something like this:

https://github.com/henriqueweiand/nestjs-payment-gateway-integration/blob/master/libs/components/checkout/src/payment-processors/payment-processors.service.ts

Stripe payment processor

Each processor has to implement two methods: _pay and _refund. By the way, I'm not implementing the _refund part in this project, but, it's important to have in case a payment fails and you have to refund the customer automatically. The definition of the methods above is set inside the abstracted class PaymentProcessor

protected abstract _pay(paymentData: PaymentData, paymentInput: Input): Promise<PaymentTransactionResult>;
protected abstract _refund(paymentLog: PaymentLog): Promise<PaymentTransactionFailedResult>;

These methods aren't exposed, they are the main logic of the integration and they will be used later by an exposed method.

Inside each processor we defined the logic with the external library, for example, the Stripe processor is calling the method stripeService.createPaymentIntent to create the payment, and the same would work for the _refund method. To give you a better idea of the execution flow, let's take a look at the pay method inside the abstracted class PaymentProcessor.

https://github.com/henriqueweiand/nestjs-payment-gateway-integration/blob/master/libs/components/checkout/src/payment-processors/processors/payment.processor.ts

Two things are happening here:

it's creating the payment log.
it's calling the _pay method implemented by the specific integration.

The payment log represents things like:

What we receiving as input;
What the response was;
Metadata of the payment/checkout;
Status of the payment;

This is important information for multiple things, for example, we can debug deeply if necessary to understand why a payment failed by looking at the input, response, and metadata; we can retry; we can easily know the payment methods used and their status.

A big-picture view of the flow described above is

OK! So far, we covered all the payment flow from the controller to the payment integration with the payment gateway! The remaining part is the refund, which happens when one or more payments fail with the payment gateway. Let's return to the service https://github.com/henriqueweiand/nestjs-payment-gateway-integration/blob/master/libs/components/checkout/src/checkout.service.ts

Inside the method processPayments, after we process every payment informed, after the line

const results = await Promise.all(paymentInputs.map(paymentInput => this._processOnePayment(checkout, paymentInput)));

We are filtering out the results to find the payment logs that were failed and completed, if we have any payments that failed, then we need to run the refund for all those that were completed. As I mentioned before, I implemented the refund partially, there's only the structure, but the main logic with Stripe, for example, is missing on purpose, I didn't want to go that further on the topic, but the documentation for Stripe's refund is available on https://docs.stripe.com/api/refunds/create

Some extra notes about the implementation

Instead of processing it during the request as we are doing with Promise.all inside the checkout.service, one option would be putting it in a queue and processing on depend. You can also respond after the processing with some kind of socket connected to the front end which is waiting for the response, or any other strategy you want.
I didn't create a service only for the repository for example the checkout service is doing it and some other things, it would be nice to have a repository class and reduce the responsibility of some of the services.
Don't take all the implementation too seriously, it's a base example of how to abstract modules and services to have an easy way to integrate with different payment gateways quickly and easily.

Other packages inside libs

You'll notice some libs inside the libs folder that are:

env
logger
persistence

I didn't explain them in this article because they are not the focus, but they are modules to deal with the env, logger, and persistence (TypeORM, migrations). They are useful modules that I use from time to time on my blog posts.

Running frontend and backend project

This article includes both frontend and backend projects with the Stripe integration to show the project working. In the example you can inform the Stripe card and a voucher, simulating everything that we implemented in this article.

If you want to run the projects, please follow the instructions for each one.

That's all for today! Don't forget to subscribe to follow the following post that is about to be released!

NestJS TypeORM and Multi-Tenancy

Henrique Weiand — Sat, 14 Dec 2024 12:57:41 +0000

Not so different from any other ordinary type of project, multi-tenancy is a software architecture that has been in place for quite a while, and as with any other approach, there are pros and cons. In this article, I plan to walk you through a simple solution I implemented to tackle basic architecture inside the universe of the NestJS framework with TypeORM.

Context

I've been studying and trying new approaches whenever something pops up and I wonder how to do that technically, or when I found something cool! I've written a few articles with this idea in mind, and this one is no different! I was talking to my brother the other day and he is planning to migrate a project that runs with PHP to node and he asked me if I knew an example of multi-tenancy with NestJS. Despite being in the technology for a while, I worked on something with C++ in the past but not with Node or NestJS. In the end, it wasn't a problem, I took it as my new study subject and tried it!

The final code is available on the link below on GitHub

https://github.com/henriqueweiand/nestjs-typeorm-multi-tenancy

I don’t describe the details in this article, just the overview and how the application works according to the target, which is:

NestJS project;
Multiple databases, one for each customer;
Use TypeORM to deal with the database connection;

Multi-tenancy

Let me start by saying that multi-tenancy has different types, some of them are:

A single application, single database;
A single application, multiple database;
Multiple applications, multiple databases;

You can find more details about the concept online. (What is multi-tenancy (multi-tenant architecture)).

In case you want to know, this project uses a single application and multiple databases. 🎯

Developing

Before I started, I researched NestJS packages, existing libraries, public projects, and articles and I found a few interesting contents, for example:

https://dev.to/logeek/nestjs-and-typeorm-efficient-schema-level-multi-tenancy-with-auto-generated-migrations-a-dx-approach-jla

https://github.com/mguay22/nestjs-multitenancy

None of them matched exactly what I needed, which motivated me to continue and implement it, and in the end, I got some shared knowledge from all the materials and included them into my project version.

The project has two main folders that are essential for the idea.

/src/libs/database
/src/libs/tenancy

Database

Starting with the database, it is important to note that the service implements OnModuleInit, which executes a logic when the app starts and the service is instantiated. What I implemented consists of the following sequence:

App starts;
The app initiates a default DB connection;
This instance gets the data from a default database and table tenant which holds the database information for all the customers;
This connection verifies if each database from the data is created and if so, it runs the migrations over the customer's database, otherwise, it creates a new database and also runs the migrations over it.
An exclusive Data source is created for each one of the databases and stored in memory;
Close the default connection (this connection is different from the other databases);

💡 The low point of this approach is that the app won't verify if new databases were created unless the app is restarted. I didn't want to focus on this, so I left this improvement open on the project. Feel free to help with 😉

All this logic is happening inside the database.service.ts in case you want to check it out.

https://github.com/henriqueweiand/nestjs-typeorm-multi-tenancy/blob/main/src/libs/database/database.service.ts

Tenancy

Despite being a simple module if you take a look, it's a crucial part of the project and it put everything together!

This module uses the library nestjs-cls, which is "A continuation-local storage module compatible with NestJS' dependency injection based on AsyncLocalStorage". You also can use the node implementation with async_hooks if you want. The module gets the tenant-id from the request and adds it to the local storage which makes the info available through the request lifecycle.

Continuation-local storage allows to store state and propagate it throughout callbacks and promise chains. It allows storing data throughout the lifetime of a web request or any other asynchronous duration. It is similar to thread-local storage in other languages.

https://github.com/henriqueweiand/nestjs-typeorm-multi-tenancy/blob/main/src/libs/tenancy/tenancy.module.ts

Finally, with all that in place, one method inside the database.service.ts, will help us to connect the repositories later to the right database.

/**
 * Get the data source for the current tenant
 */
getDataSource() {
  const tenantId = this.cls.get(TENANT_KEY);

  return this.tenantConnections.get(tenantId);
}

it will get the tenant-id from the local storage as explained before and also the connection from the variable in memory

💡Speaking of memory, another possible improvement for the future is, making this memory part available in a cache layer or somewhere else, otherwise, if you scale the application the connection won't be shared, but each application will have its own. It is not a big deal, but it is a nice to have.

Connecting a repository to the database

Different from the normal way of using TypeORM, I mean, by using the forFeature method, etc, in this case, you need to do something a bit different.

https://github.com/henriqueweiand/nestjs-typeorm-multi-tenancy/blob/main/src/components/users/users.service.ts

With the DatabaseModule module added to your Module, you can import the Database service and call

this.userRepository = this.databaseService.getDataSource().getRepository(User);

This line will return an instance of the correct database according to the tenant-id from the header and the User repository to use as needed.

And that's all my friends! We did it!!!

Bonus: Generating migrations

This project is set up in a way that you can use the TypeORM generate command! After making any change in the entities, you can run yarn typeorm:generate, and it will generate the migrations for you. You won't need to run with another command, because the application will run for you once it starts because of the migrationsRun: true

In the readme file, you can find a section about how to run the application

https://github.com/henriqueweiand/nestjs-typeorm-multi-tenancy/blob/main/README.md

Conclusion

In this article, we explored a practical implementation of multi-tenancy using NestJS and TypeORM. The solution demonstrates how to handle multiple databases for different customers while maintaining a clean and organized codebase.

The key achievements of this implementation include:

Successfully setting up a NestJS project with multiple database support
Creating a system that manages database connections for each customer
Implementing database migrations and proper connection handling

While this implementation provides a solid foundation, there are opportunities for improvement, such as:

Adding real-time database verification without requiring app restart
Implementing a caching layer for better connection management across scaled applications

Overall, this approach offers a practical solution for implementing multi-tenancy in NestJS applications while maintaining flexibility and scalability.

Mastering NestJS: Building Scalable Systems with Abstractions, ex: different databases

Henrique Weiand — Fri, 15 Mar 2024 20:43:26 +0000

Hello, developers! Welcome to the second part of our NestJS + Clean Architecture + DDD series. In this post, we’ll delve into abstractions and explore how they can be used to create scalable systems that are agnostic to any technology. We’ll use Mongo and Postgres databases as examples to demonstrate this. The goal is to provide strategies that can elevate your application to the next level.

I’ve received much feedback and numerous valuable comments. Thanks to everyone for your support in advance.❤️
Mastering NestJS: Unleashing the Power of Clean Architecture and DDD in E-commerce Development —…

How to implement an abstraction

Before diving into the code, let’s discuss the concept and its application. We’ll consider two examples: Stripe integration and database usage. These examples are relevant as an e-commerce entity may have multiple payment integrations and may wish to change or alternate between them in the future. Similarly, the technical team may decide to switch the database from non-relational to relational, or vice versa. Abstractions help us structure the code, ensuring changes are not overly complex or challenging.

Database case

Inside a project with Clean architecture, the database (data persistency) is located in the most external layer, so we have to consider this Persistence as something that can’t influence the domain or any other layer, it must be something independent that is there to save, get and manage the data from the database.

Our Persistence module is located in infra/persistence. As I explained, this project has two different databases (for a better exemplification), so this is a simple module, which receives parameters according to the interface, that will be used inside the register method.

interface DatabaseOptions {
    type: 'prisma' | 'mongoose';
    global?: boolean;
}

(full code)

This is basically a wrapper class that has both modules, if you want to use Postgres or Mongo. The register will return a DynamicModule which can be used as a normal module. You can check it out in app.module.ts

So far, nothing new, or almost nothing new… We will see some similarities when opening MongooseModule and PrismaModule

The providers are the same! I mean, they provide attributes for each one of the objects inside providers. Let's take a look at one as example

import { Order } from "@app/domain/ecommerce/order";

export abstract class OrderRepository {
    abstract findMany(): Promise<Order[]>;
    abstract findById(id: string): Promise<Order>;
    abstract create(data: Order): Promise<Order>;
    abstract update(id: string, data: Order): Promise<Order>;
}

Here we introduce an abstract class that standardizes data from any database type. We also use the Domain definition, which defines a class and its properties.

The attribute useClass in each module represents the class that implements this abstraction, adhering to input and output definitions.

This is one approach to creating a scalable, agnostic, and flexible persistence solution. For instance, each module will contain library elements related to the ORM, located only on the external layer of our graph. Subsequent use cases will utilize the exported repositories without needing to distinguish between databases, focusing solely on the data. Quite magical! 🧙‍♀️

I am not going to cover the code inside the Persistence module, because it is only the implementations of the entities and the responses by the respositories. Using the domain declarations inside the mappers of course.

I am going to cover more details of the database implementations soon in another post. Keep an eye on the community → https://medium.com/nestjs-ninja

Envs, HTTP, Payment, and any other

The infra folder has other external layers and you can check out them here

Persistence and Payment have a similar structure where I tried to explain the core of the usage.

Connecting the layers

In the previous post we went through an explanation of the layers being connected, so please take a look before diving deep into this new section (Previous post).

The high-level explanation of the flow is

Controller → Use case → Entities

Breaking a little bit, it would be like this

And looking at the use-case part we can see the data usage, logic, and many things happening, for example

import { Order } from '@app/domain/ecommerce/order';
import { Injectable } from '@nestjs/common';
import { OrderRepository } from '../ports/order.repositoy';
import { OrderProduct } from '@app/domain/ecommerce/order-product';

interface CreateOrderUseCaseCommand {
  user: string,
  orderProduct: Pick<OrderProduct, 'product' | 'price'>[]
}

@Injectable()
export class CreateOrderUseCase {
  constructor(
    private orderRepository: OrderRepository,
  ) { }

  async execute({
    user,
    orderProduct
  }: CreateOrderUseCaseCommand): Promise<Order> {
    let total = 0;
    const order = new Order({
      user,
    })

    const createdOrderProduct = orderProduct.map((product) => {
      total += product.price;

      return new OrderProduct({
        product: product.product,
        price: product.price,
      });
    });

    order.total = total;
    order.orderProduct = createdOrderProduct;

    const createdOrder = await this.orderRepository.create(order)
    const response = await this.orderRepository.findById(createdOrder.id);

    return response;
  }
}

(full code)

In this use-case, we are creating an order, so we have the input and inside the constructor, we are declaring the repository. Before we call the repository methods, we prepare the information according to the Domain and the abstraction. There’s also some logic that calculates the total price of the order.

Here, we have a clear usage of the classes that represent the Domain, which also defines the way that the abstractions understand the interactions. Since our Domain is the main point of the whole application, it helps us to keep the data transition in harmony and flexible to be used and changed when necessary.

Conclusion

We’ve completed another section of the article. Regardless of whether you’re using DDD, Clean Architecture, or any other approach, NestJS’s ability to abstract is a powerful tool. It can help us build well-structured, flexible modules with a low level of coupling. I hope this main idea has come across clearly in this part.

https://medium.com/nestjs-ninja is a free and open community. If you have a post you’d like to link to the community, please let me know! Let’s contribute to the ecosystem together. You’re welcome to share not just case studies, but also real experiences that can provide value to all readers.

Mastering NestJS: Unleashing the Power of Clean Architecture and DDD in E-commerce Development — part 1

Henrique Weiand — Sat, 09 Mar 2024 19:44:30 +0000

Hello, dev! Let’s start one more sequence of exciting technical posts related to the NestJS ecosystem, and in this sequence, I am going to review and exercise with you concepts like:

The idea is to only go through some parts of the application, ok? I recommend this post for those who have some knowledge about NestJS already and want to see & apply a different architectural approach to have applications with as little coupling as possible.

There’s another post that I wrote in the past, that also applied this approach of less coupling. If you want to take a look the link is
Creating Smart Questions with NestJS and OpenAI

What is going to be the project?

This is a simple project that represents part of an e-commerce ecosystem. We are going to design a solution with four basic entities, they are

Plus, we will integrate this solution with the Stripe payment platform and a Cache layer for the GET endpoints to respond faster! 🏃🏻‍♂️💨

Start 🎬

For this project, I am going to use a few different technologies for two reasons:

I want to share how Clean Architecture can help a project not rely on the technology; For example, if you want to change the database, or payment provider… it is going to be very simple.
To have a clear project pattern applied;

The technologies are going to be:

NestJS
MongoDB
Postgres
SWC

I am starting this project, following the same steps that I have shown in this post (I just skipped the deploy step)
Implementing auth flow as fast as possible using NestJS

With the project created and the setup done, we can organize the folders and the main files. The final version is gonna be like this:

assets
├── prisma
└── src
    ├── application
    │   └── ecommerce
    │       ├── ports
    │       └── use-case
    ├── core
    │   └── entities
    ├── domain
    │   └── ecommerce
    └── infra
        ├── env
        ├── http
        │   └── dto
        ├── payment
        │   └── stripe
        └── persistence
            ├── cache
            │   └── interceptor
            ├── mongoose
            │   ├── entities
            │   ├── mapper
            │   └── repositories
            └── prisma
                ├── mapper
                └── repositories

To start with something visual, let’s start with the infra/http This HTTP, represents one of the external layers that compound the architecture, so, everything related to external technologies, for example, databases, presenters, and libraries, will be inside this folder.

To make things clear, we are following this diagram. (don’t worry about everything else yet)

As HTTP is a module, let’s create a module and its related files

http
├── app.controller.ts
├── checkout.controller.ts
├── dto
│   ├── create-order-product.dto.ts
│   ├── create-order.dto.ts
│   ├── create-product.dto.ts
│   └── create-user.dto.ts
├── http.module.ts
├── order.controller.ts
├── product.controller.ts
├── user.controller-e2e-spec.ts
└── user.controller.ts

This is the final version with everything inside, but you can start off with the http.module.ts and product.controller.ts.

The module is pretty simple, he initially is going to have the product.controller declared in it and speaking about the product.controller, you can create a simple GET method just to have something in it as well. (you can find the final version here).

With the HTTP module created, you can add it to the app.module and make things work.

Domain entities 🎨

As you might have seen, we have a folder called src/domain/ecoomerce, and in there we are declaring the classes that will represent the three entities that I mentioned in the beginning.

ecommerce
    ├── order-product.ts
    ├── order.ts
    ├── product.ts
    └── user.ts

Each one is a Class and has its properties, for example, products

In this case, I am declaring a Product class and this domain contains fields, they are:

id (optional, because at the moment of creating the record still doesn’t have value)
title
price

Other entities 🦿

The other entities are kind of similar to the Product, however, if we take a look at Order, we will see that this one has a relation to others like orderProduct.

import { Entity } from "@app/core/entities/entity";
import { OrderProduct } from "./order-product";

export interface OrderProps {
    id?: string;
    user: string
    total?: number
    status?: "paid" | "open" | "canceled"
    paymentId?: string,
    paymentMethod?: "stripe" | "paddle" | "paypal" | "other", // It is only working with stripe for now
    orderProduct?: OrderProduct[]
}

export class Order extends Entity<OrderProps> {
    constructor(props: OrderProps) {
        props.total = props.total ?? 0;
        props.status = props.status ?? "open";

        super(props);
    }

    ...

(The final folder with all the entities → here)

The reason for those relations is simple, an order in this context has one or more products. One more detail that this entity knows can be seen in the construction method. If this Domain is declared without total and status defined, it will assume 0 as price and “open” as status. We could have more methods or conditions that we understand are correct for the domain if that is the case, okay?

Just to reinforce, when we talk about Domain, we are referring to the main layer of the diagram.

Connecting the layers 🥗

Following the diagram, we have to follow the sequence:

Controller → Use case → Entities

During usage, we can use anything from the external layer in order to execute the logic, and all of this is held in the use case, so we are going to connect the layers inside the HTTP + Use cases, especially because of the dependency injection that NestJS has.

Check out this final version of the http.module

As I said, we have the Controllers that are going to receive the use cases, and the use cases rely on the Payment module and Database module. One detail, The Database module is declared as global , and for that reason, it is not included here. The database module is declared in the app.module like this final version here.

💡 It is important to understand the dependency injection and the module strategy that NestJS applied to understand the most from this example.

To have a better understanding of all of these, let’s see the following files

This is the flow that the request follows when it is requested.

Conclusion 👨🏼‍🏫

We have covered a bunch of parts of this application and concepts so far, and as I said, it is a sequence of posts. For the next one, we are going to see and understand more about abstractions how to create a module, service, and functionality with as little coupling as possible. The idea is to apply this technique for the use cases and the repositories that later are going to persist the information in the database.

Empowering Language Learning with NestJS, NextJS, Vercel, and Neon.tech: A Tech-Infused Journey

Henrique Weiand — Fri, 08 Mar 2024 21:11:03 +0000

Empowering Language Learning with NestJS, NextJS, Vercel, and Neon.tech: A Tech-Infused Journey

Hi everybody, how’s it going?

Today’s post is going to be a bit different. I want to share the journey that I have been taking related to the process of learning a new language and how technology can be connected to it. I know that everyone here likes technology, and for that reason, I am going to talk about two projects that I have done that are open-source and come to give the word something back in terms of education. I don’t want to give any spoilers already, but that’s going to be the main point! Grab a coffee or a lovely cup of tea and enjoy the text!

As someone who isn’t a native English speaker and comes from Brazil, I’ve been on a journey to learn English for some time now. I’ve tried various things like apps, books, classes, podcasts, videos, and movies. Each of these resources has been helpful in its own way, and there are a few that I stick to every day. Learning a language isn’t easy, but one thing I’ve learned is the importance of sticking to what works for you and giving it time because learning is a process, right?

As I explored different ways to learn languages, I felt something inside me growing. It took me a while to understand, but eventually, I realized what it was. Being a developer, I saw how these tools helped me reach an important goal. That’s when I decided to give back to the world. So, I started creating open-source projects that mix technology and education. One of them is a flashcard app for learning languages with OpenAI.
Flash-cards app with OpenAI

Another was a question generator, also using OpenAI.
Creating Smart Questions with NestJS and OpenAI

And there’s one more that I haven’t written about yet, but it is online as a platform and also available to contribute or download for free. The website is quiz-english.com
Quiz-English: Learn English by doing quizzes

This one is a platform where there are many different quizzes about many different subjects, but the main point here is, as I am a heavy user of podcasts, every podcast that I listen to that is a public transcription, I can convert to a quiz using OpenAI, it helps me to exercise the retention of the information from the podcast.

If you’re on a similar journey to learn a new language or just passionate about education and technology, I encourage you to check out these projects. They might be the resources you’ve been looking for!

Projects and technologies

In my projects, I’ve employed a variety of technologies such as NestJS, NextJS, React-Native, Postgres, Mongo, and more. Each technology has its pros and cons, but in my experience, I’ve found that if you’re looking to quickly bring your idea to life, Vercel and NextJS are excellent choices. With Vercel, you can host both the backend and frontend closer together, and easily integrate with services like Postgres or Mongo — all without any cost! Quiz-English.com is a prime example of this approach. Here’s a rundown of the technologies powering the project:

Vercel (Host)
Github (Repository)
NextJS (Frontend and backend)
Neon.tech (Postgres database)
Cleark (Auth provider)

Plans

In the future, I aim to continue sharing my insights and experiences through technical blog posts on platforms like Medium and dev.to. My goal is to provide more real-world examples, use cases, and interesting topics that can benefit others in the tech community. Additionally, I’ve initiated a community centered around NestJS called NestJS Ninja, which you can find on Medium. Through this community, I hope to foster the growth of the JavaScript ecosystem and promote NestJS as a versatile framework.
NestJS Ninja

Conclusion

In conclusion, my journey in exploring language learning through technology has led me to develop projects like Quiz-English.com and embrace a variety of technologies like NextJS and Vercel. As I continue to share my experiences and insights through platforms like Medium and dev.to, I’m excited to contribute to the tech community and promote the growth of frameworks like NestJS through initiatives such as NestJS Ninja. I invite you to join me on this journey of learning, collaboration, and innovation. Together, let’s explore the endless possibilities that technology offers for education and beyond.

🔭 If you have any posts to contribute to the community, please let me know!

Mastering Error Tracking: A Beginner’s Guide to Sentry in Your NestJS Project

Henrique Weiand — Mon, 20 Nov 2023 11:49:52 +0000

Hello fellow coders!

The topic today is extremely important, it is something simple but can be a game change when we are running a service on production and suddenly, the users are having problems, errors, etc.

We are going to have a hands-on example of implementing an error track inside a NestJS project, we are going to use Sentry as a tool to help us see and be ahead of the problem before they are properly reported by the users.
Application Performance Monitoring & Error Tracking Software

Why should I use a tool like that inside my project?

There are many reasons, but the most important one is “to know the error with details in advance before they are reported”.

Imagine that you have lots of microservices or even a large code base, many times a difficult large codebase, and eventually, bugs happen! Some bugs, sometimes require the context or the parameters to be able to simulate. Sometimes you have so many errors that you don’t know which one is the priority, or in which frequency they happen. So many different cases right? That’s why I always put a tool like that into my projects.

Other options

You can find easily many tools that do almost the same as Sentry, some are cool, some are easy to set up, some don’t have a nice view or require more of you to set up… I always choose Sentry or New Relic, but mostly Sentry because they solve my problems very well.

Other options are

Datadog
New Relic
Elastic Observability
Dynatrace
AppDynamics

Setting the project up

For those who never read my articles, I am going to follow the basic setup from this post
Implementing auth flow as fast as possible using NestJS

Because I want to run this project with SWC and the correct tsconfig configuration. Don’t worry, you can find the whole codebase at the end of this post as well.

nest g application nestjs-sentry-configuration

Sentry account

Visit the website https://sentry.io/ and create your account.

Then, let’s create a new project and select Node.JS

Install the dependencies and copy the DSN value.

npm install --save @sentry/node @sentry/profiling-node

Now let’s go back to the NestJS project.

Creating an ExceptionFilter

I am going to create an Exception called sentry.filter.ts. If you want to learn more about Exceptions and how they are handling inside the NestJS, check out this link
Documentation | NestJS - A progressive Node.js framework

My exception file will be like this

import { Catch, ArgumentsHost } from '@nestjs/common';
import { BaseExceptionFilter } from '@nestjs/core';
import * as Sentry from '@sentry/node';

@Catch()
export class SentryFilter extends BaseExceptionFilter {
    catch(exception: unknown, host: ArgumentsHost) {
        Sentry.captureException(exception);
        super.catch(exception, host);
    }
}

This is an ordinary exception and we are also extending the BaseExceptionFilter, because I want to keep the original Exception response as soon as the error is tracked. I was doing it when I called.

super.catch(exception, host);

Is important to notice that our @Catch() is empty, it will make that this Exception handles every exception that can happen.

Adding an exception to the global scope

We need to add the Custom exception to the project, and we can do that by editing the main.ts

import { HttpAdapterHost, NestFactory } from '@nestjs/core';
import * as Sentry from '@sentry/node';
import { SentryFilter } from './sentry.filter';
import { AppModule } from './app.module';

async function bootstrap() {
  Sentry.init({
    dsn: process.env.SENTRY_DNS,
  });

  const app = await NestFactory.create(AppModule);
  const { httpAdapter } = app.get(HttpAdapterHost);
  app.useGlobalFilters(new SentryFilter(httpAdapter));

  await app.listen(3000);
}
bootstrap();

Please, don’t forget to put the SENTRY_DNS value! Otherwise, it won't work as we want.

And we are done!!

Testing the changes

First, let’s start the project

npm run start:dev

A simple example can be an error like

import { Injectable } from '@nestjs/common';

@Injectable()
export class AppService {
  getHello(): string {
    throw new Error('Ops, theres a problem!');
    return 'Hello World!';
  }
}

I am forcing an error, and after requesting the route of this method, I got this report

Here you can find for example:

User
Context
How many times this issue happens
When

Plus (optional)

If you want to implement it as a module and use dependency injecting etc to get more from the errors, and also to have it global, you can do it using the example below as a starting point.

“Binding interceptiors” https://docs.nestjs.com/interceptors#binding-interceptors

import { Module } from '@nestjs/common';
import { APP_INTERCEPTOR } from '@nestjs/core';

@Module({
  providers: [
    {
      provide: APP_INTERCEPTOR,
      useClass: LoggingInterceptor,
    },
  ],
})
export class AppModule {}

More examples of using different approaches

Sentry Integration With NestJS

https://github.com/ericjeker/nestjs-sentry-example

Conclusion

It’s been easy to add Sentry or any other Error tracker, and knowing how important it is for any project, I would suggest you add it right now 😄

Unlocking the Power of GraphQL for Beginners: A Step-by-Step Guide to Integrating GraphQL into Your Existing Project

Henrique Weiand — Fri, 17 Nov 2023 14:27:08 +0000

Hello fellow coders!

I’ve been noticing an increase in the number of companies requiring GraphQL experience for a job opportunity, and that triggers me to create another useful technical blog post in one interesting way, I want to implement GraphQL inside an existent project! Cool, right? My idea initially, is to implement something not so deep but that works at the same time.

I am going to use my project, which is an AI question generator, that you can find in the link below.
Creating Smart Questions with NestJS and OpenAI

Let’s set the scope of this project

It must cover the user module, by offering a GraphQL interface to handle the functionalities below
Create user
Get users
Get user
Update user
Delete user

Setting up the project to work with GraphQL

Let’s use the official documentation to follow the correct setup
Documentation | NestJS - A progressive Node.js framework

First, we have to install the dependencies

npm i @nestjs/graphql @nestjs/apollo @apollo/server graphql

Then is necessary to set up GraphQL and I’m going to do it by adding the module into the app.module.ts like this

import { EnvModule } from '@app/common';
import { Module } from '@nestjs/common';
import { DevtoolsModule } from '@nestjs/devtools-integration';
import { Modules } from './modules/module';
import { GraphQLModule } from '@nestjs/graphql';
import { ApolloDriver, ApolloDriverConfig } from '@nestjs/apollo';

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      playground: true,
      autoSchemaFile: true,
    }),
    DevtoolsModule.register({
      http: process.env.NODE_ENV !== 'production',
    }),
    EnvModule,
    Modules,
  ],
})
export class AppModule { }

if you keep playground as true, it will enable the visual playground to try the queries and mutations on the browser. We will use it later.

In my case, I also kept autoSchemaFile true and as I'm using the "code first approach”, the official documentation says

In the **code first **approach, you use decorators and TypeScript classes to generate the corresponding GraphQL schema.

Also, the doc mentioned the case of using true as a value

The autoSchemaFile property value is the path where your automatically generated schema will be created. Alternatively, the schema can be generated on-the-fly in memory. To enable this, set the autoSchemaFile property to true

Configuring the resolvers

Resolvers provide the instructions for turning a **GraphQL** operation (a query, mutation, or subscription) into data. They return the same shape of data we specify in our schema — either synchronously or as a promise that resolves to a result of that shape. Typically, you create a resolver map manually. The @nestjs/graphql package, on the other hand, generates a resolver map automatically using the metadata provided by decorators you use to annotate classes. To demonstrate the process of using the package features to create a GraphQL API, we'll create a simple authors API.

In the code-first approach, we don't follow the typical process of creating our GraphQL schema by writing GraphQL SDL by hand. Instead, we use TypeScript decorators to generate the SDL from TypeScript class definitions. The @nestjs/graphql package reads the metadata defined through the decorators and automatically generates the schema for you.

Code on

Speaking about code, as we only need to apply GraphQL to the user module, I will start showing the files inside the folder /src/modules/user, just to show you some differences from the previous project. By the way, I will keep REST working at the same time.

The folder & file structure

./user
├── controllers
│   ├── controllers...
├── dto
│   ├── args
│   │   └── get-user.args.ts
│   ├── create-user.dto.ts
│   ├── input
│   │   ├── create-user.input.ts
│   │   ├── delete-user.input.ts
│   │   └── update-user.input.ts
│   ├── update-user.dto.ts
│   └── user.dto.ts
├── resolvers
│   └── user.resolver.ts
├── use-case
│   ├── use-cases...
├── user.model.ts
└── user.module.ts

We are going to work on basically with:

user.model.ts;
resolvers folder;
dto/args folder;
dto/input folder;

Our resolver will provide an interface between the user and the use cases, which we have with the controllers when we use REST, right? So you can see that we are injecting the use cases as dependencies just because we need to call them with the required input for those use cases that need.

import { Args, Mutation, Query, Resolver } from '@nestjs/graphql';
import { GetUserArgs } from '../dto/args/get-user.args';
import { CreateUserInput } from '../dto/input/create-user.input';
import { UpdateUserInput } from '../dto/input/update-user.input';
import { CreateUserUseCase } from '../use-case/create-user';
import { DeleteUserUseCase } from '../use-case/delete-user';
import { GetManyUsersUseCase } from '../use-case/get-many-users';
import { GetUserByIdUseCase } from '../use-case/get-user-by-id';
import { UpdateUserUseCase } from '../use-case/update-user';
import { User } from '../user.model';

@Resolver('User')
export class UserResolver {
    constructor(
        private getManyUsersUseCase: GetManyUsersUseCase,
        private createUserUseCase: CreateUserUseCase,
        private updateUserUseCase: UpdateUserUseCase,
        private getUserByIdUseCase: GetUserByIdUseCase,
        private deleteUserUseCase: DeleteUserUseCase
    ) { }

    @Query(() => User, { name: 'user', nullable: false })
    async getUser(@Args() getUserArgs: GetUserArgs) {
        return this.getUserByIdUseCase.execute(getUserArgs.id)
    }

    @Query(() => [User], { name: 'users', nullable: false })
    async getUsers() {
        return await this.getManyUsersUseCase.execute();
    }

    @Mutation(() => User)
    async createUser(
        @Args('createUserInput') createUserInput: CreateUserInput,
    ) {
        return await this.createUserUseCase.execute(createUserInput);
    }

    @Mutation(() => User)
    async updateUser(
        @Args('updateUserInput') updateUserInput: UpdateUserInput,
    ) {
        return await this.updateUserUseCase.execute(updateUserInput.id, updateUserInput);
    }

    @Mutation(() => User)
    async deleteUser(
        @Args('id') id: string
    ) {
        return await this.deleteUserUseCase.execute(id);
    }
}

(If you prefer the same code can be accessed here)

I am not going to detail this file yet, let’s do it later after having the complements of this file to work properly.

As you may notice looking at the resolvers, we changed the approach of using the DTO as body and get parameters to

Args
Inputs

Which is a more usual way of talking when we are working with GraphQL. They will represent the DTO as it is, and there we specify the props according to the necessity. This is very easy work to be honest, because as we have already the DTO for the REST protocol, we can copy and change just a few details. Loot at this example

Again, I am not going through each one of the inputs and args, so feel free to check all of them out.

Last but not least, user.model.ts

import { Field, ID, ObjectType } from '@nestjs/graphql';
import { User as UserDB } from '@prisma/client';

@ObjectType()
export class User {
    @Field(() => ID)
    id: UserDB[`id`];

    @Field(() => String)
    username: UserDB[`username`];

    @Field(() => String)
    password: UserDB[`password`];
}

(code)

This model is ObjectType which represents our User schema on Prisma, and in this file, we are mapping the fields properly.

Running the application

After understanding and setting everything up, it’s time to run, right?

npm run start:dev

and then you can access http://localhost:3000/graphql , where you can play with your query, mutations, etc.

Mutation

Query

Conclusion

The final code can be found in this like
GitHub - nestjsninja/nestjs-generate-questions-graphql

It was pretty simple, right? Now I hope you feel a bit more comfortable applying GraphQL to your project when it’s necessary.

References

The repository below is an old project in which I implemented the authentication and authorization modules using GraphQL. The funny part is that it is still up-to-date.
GitHub - henriqueweiand/nestjs-account-graphql: NestJS and GraphQL based project simulating an…

Some good references
Ultimate Guide: How To Use Prisma With NestJS [2022]
NestJS GraphQL/Prisma/PostgreSQL Set Up

Supercharge Your Testing Workflow: Creating Unit and E2E Tests 10x Faster with ChatGPT-3 Inside NestJS

Henrique Weiand — Wed, 08 Nov 2023 21:48:00 +0000

Hello fellow coders! I have a polemic topic to talk about today, it is “using AI to create the unit and e2e tests” and how it can improve the velocity of writing tests!!!

Before we dive into the topic, I want to be clear, that it is just one idea, and looking at the new worlds and new possibilities with AI I wonder if we don’t have to take advantage of these new technologies when we talk about tests!!!

I have to be honest with you all readers, for all the posts that I have been doing I am using AI to help me write the code faster, it doesn’t mean that I don’t know about the content, code, etc, it means that I am taking advantage of ChatGPT-3 and Phind to have things done faster, for example.

In this post, we have a few unit-tests
Applying Unit Tests on NestJS with Jest and GitHub Actions

In this post we have e2e-tests
Applying integration test on NestJS with Jest and GitHub Actions

For both, during my circle of development, I didn’t use TDD or other methods, I just wrote the services, classes, and modules and then I went to the tests, at this time I already had the base structure, so I opened Phind or ChatGPT-3 and I asked them to create a test to cover as much cases as possible using NestJS and its way of implementing tests, and in just a few seconds I have lots of tests ready! For a few of them I had to fix some small details, but overall, it was very good!

One important point here is, that sometimes this approach does not guarantee some specific or important cases that just you know, so for those cases I had to implement it myself.

Guys! It gives me back lots of time! So the question that I have is:

Should we rethink the way of implementing tests? TDD? Whatever other method still relevant? Or we can have one approach like that?

I’m not sure about you all, but at the place where I work, we are both focused on quality but mainly on time and productivity, so the time aspect weighs a lot.

Real example

I am going to use a real example that was implemented in our previous post
Creating Smart Questions with NestJS and OpenAI

Using the use-case “modules/question/use-case/create-question.ts”
Open AI buddy tool, in my case https://www.phind.com/
Ask ”I have the code below inside a NestJS project and I need to implement a unit-tests. Please write all possible cases to cover the class as much as possible. It must be written using the NestJS test module. CODE OF THE CREATE-QUESTION HERE”
Create the local test file and put the content over there

Fix the necessary lines;
Create new cases or change something (if necessary)
Run the tests npm run test

So amazing, isn’t it?

You can see that it created the mocks for those necessary cases etc! 🧙‍♂️

Some possible approches

Use the AI tools to help you to remember something that maybe is not clear or you just don’t remember;
For those who are starting, try to notice the way of the implementation that AI is providing you and then use this content as input to understand better how it works;
For those who are more senior, try to get some codes from the AI and do the adjusts only on those areas that you know that are important;

Conclusion

The world and technology have been changing so fast this 2023 and I can assure you that 2024 will be much harder in terms of innovation, so let’s get out of our comfort zone and review the process of implementing and maybe be even better in this new moment.