Previously: In the last month, I started to make a sweepstakes based on the nest.js server, so I would like to share with you. Content: This article is annotated based on the examples from the official website, which only covers the introduction to the use and concept of Nest.js. Aim: Simply string together several common nest.js concepts for people who have never had contact with them. Related documents: English document-link, Chinese document-link ** ** Nest. js is the node.js framework I’ve worked with the most, although I’ve also used express.js and koa.js briefly… BUT I don’t want to go into too much about the differences and connections between them. Maybe I’ll share it in a separate article (if I need to do more research). This article will be introduced according to the following logic:

• A simple request
• A slightly more complex request
• The concept of “doing” has to be mentioned
• A truly complete set of requests

It is recommended to see the original text because there are some key identifiers (these are filtered out). The original address: www.yuque.com/u548790/tec…

An overview of the

When we use Nex.js, we don’t need to worry too much about what the underlying logic is. But if we want to use a lower-level framework, such as Express.js, with Nest.js, we can also do it declaratively.

A simple request

Let’s start with the first simple request.(Please look carefully at the picture and its annotation)



The above is a note I wrote using an example from the official website. In Nex.js we can use a large number of decorators already wrapped, or we can wrap our own decorators. The main purpose of decorators is to make code clearer. They are syntactic sugar for specific classes.

When we define a set of controllers, the routing mechanism of Nest.js automatically helps us map. The corresponding request is straight up and down, very clear: POST: cats -> No other path -> request create method -> return the corresponding value (purple arrow on the left of the image above) GET: Cats -> no other path -> request findAll method -> return the corresponding value (yellow arrow on the left) if you want to GET information about the cat vivi, just at @get (‘vivi’). In order to make the function and code more explicit, we usually put the code of similar function/body together, this is cats related operations, routes together, all in the cats.controller.ts folder. To be specific, create a new kitten, delete a kitten, change the name of a kitten, query all kittens, all kitty-related requests we put in our cats.controller.ts file.

It is possible to get request parameters, set other paths for Cats/XXX, dynamic routing, and set other HTTP requests, all of which are basically implemented through the built-in decorator. Here is a complete simple example (just skim it).

The concept of “doing” has to be mentioned separately

We only defined a set of routes and its implementation method above, which is equivalent to building a windmill in a windless area. Without wind, it cannot move, so the concept of Module must be put forward separately.



In the Module, we can define the Controller and its corresponding Provider. We can also export the Provider and import the required public Provider of other modules to use. The premise is that all entries must be defined in the Module before they can be used normally.





(Modules can also be divided into public modules, common modules, and modules can also be defined in different forms. Above is the Cats Module defined by the decorator @module.)