我最近必须学习 nestjs，为一个用它编写的项目做好准备。请注意，不是 nextjs，而是 nestjs。和你们中的一些人一样，我听说过它，但从未有机会实际使用它。它已经流行了一段时间了，今年早些时候赶上了 nodejs 后端开发的鼻祖——expressjs。这是他们的官方推文：
话虽如此，npm 的纯下载量存在很大差异 — Express 在撰写本文时每周下载量高达 32,397,019 次，Next 为 7,263,688 次，Nest 为 3,579,676 次。现在Nest确实在某种程度上与Express有联系，这将在文章中提到。
我想强调的是，NestJS 拥有出色的文档（充满了猫作为奖励，但仅限于桌面......），它提供了足够的信息来帮助您入门并解释其所有基本和高级内容用例。永远是一个很好的起点！
如果你像我一样，在学习了N种框架和语言之后，学习新框架和语言的最简单方法就是将其与你所知道的东西进行比较和匹配。因此，我认为 NestJS 和更流行/传统/成熟的 JS 框架之间的比较可能有助于理解一些概念。
Express.js 非常适合轻量级、灵活的 API 或限制最少的小型项目。
Next.js 非常适合基于 React 的应用，其中 SEO 和服务器端渲染至关重要。
NestJS 擅长大规模企业级应用程序，重点关注模块化和可维护性。它也是迄今为止最有主见的。其中很多意见都来自一些更有经验的 （避免说老开发人员） 熟悉的其他语言 - 控制反转、依赖注入 - Java + Spring、.NET Core、Angular（主要灵感来自 NestJS)、PHP + Laravel 或 Symfony 等
让我们从一些基本的简单示例开始，然后逐步进行。
最后是 NextJS -> next dev
在 NestJS 中，通过使用 NestFactory 创建应用程序并指定主应用程序模块来引导服务器。以 AppModule 为核心，结构更加有条理。
ExpressJS 更简单，通过调用express()直接创建服务器。
Next.js 不需要手动设置服务器，除非您使用自定义服务器 - 它的内置服务器会处理幕后的所有事情。
您的大部分工作都在其中。
NestJS 使用 @Controller 和 @Get 装饰器将路由映射到控制器方法，通过模块化路由提供更多结构。习惯 NestJS 的装饰器和注释。它们是该语言的关键部分（例如与 Java + Spring 相同）。
ExpressJS 允许您使用 app.get() 自由定义路由，这提供了灵活性，但内置结构较少。
在 Next.js 中，路由是基于文件的，pages 目录中的文件名会自动映射到路由，这让您变得简单，但对路由定义的控制较少。
ExpressJS 依赖 req.query 来访问查询参数，提供了一种更加手动的方法。
Next.js 使用 useRouter 钩子来检索组件内的查询参数，从而与 React 约定更加一致。
NestJS 使用 @Query() 装饰器轻松提取控制器方法中的查询参数。
在 ExpressJS 中，路径参数是使用 :paramName 在路由本身中定义的。例如，app.get('/users/:id') 将 id 定义为动态参数。然后，您可以使用 req.params.paramName 访问此参数，该参数很灵活，但结构不如 NestJS。
在 Next.js 中，路径参数是使用 动态路由 处理的。要在 Next.js 中定义路径参数，请在 Pages 目录中创建一个带方括号的文件，例如 [id].js。文件名 ([id]) 用于创建动态匹配作为 id 传递的任何值的路由。然后，您可以使用 useRouter() 挂钩来访问组件内的参数。这种方法简单且对 React 友好，但不如 NestJS 方法那么明确。
在 NestJS 中，路径参数是使用 @param() 装饰器结合 @Get(':id') 装饰器来定义的。 @Get(':id')指定id是动态的，@param('id')用于提取控制器中的参数。 NestJS 中的路径参数是显式定义的，并与控制器方法相关联，使其高度结构化。
了解了很多基础知识后，让我们开始一些更有趣的事情。中间件用于多种用途——检查权限、验证、日志记录等等。虽然在 Express 中它只是中间件，但在 NestJS 中，有几个不同的东西正在做类似的工作。
Next.js 没有像 NestJS 和 Express 那样的内置中间件支持。中间件功能通常在自定义服务器（如 Express）中实现。
请注意 Express 和 Nest 的结构非常相似。是时候分享 Nest 实际上在幕后使用 Express 或 Fastify 的事实了。
在 ExpressJS 中，中间件更加灵活，可以使用 app.use() 全局应用，也可以通过将中间件函数作为路由定义中的第二个参数传递来将范围限制到特定路由。 Express 更加不固执，让开发人员可以自由地构建中间件。
NestJS 提供了一种高度结构化和模块化的方式来处理中间件，将其集成到其依赖注入系统中，这对于需要可重用中间件逻辑的大型应用程序来说是理想的选择。
与其他两个框架相比，这是 NestJS 中最固执己见的部分之一。
NestJS 严重依赖依赖注入 (DI)，这是其架构的核心部分。您可以使用 @Injectable 装饰器注入服务。同时，Express 和 Next 都不支持开箱即用，因此通常情况下，您需要手动传递依赖项。
依赖注入是NestJS使用的核心设计模式之一。它通过以下方式融入其中：
NestJS 使用 IoC 容器来管理依赖项生命周期，在需要时自动注入依赖项。这将创建和管理依赖项的责任从开发人员转移到了框架，简化了设置，并减少了连接服务、控制器和其他组件时的手动工作。
通过 DI，NestJS 在整个应用程序中强制执行一致的模式，确保所有依赖项都以相同的方式处理。这使得架构具有可预测性并减少混乱。
随着应用程序的增长，NestJS 中的 IoC 容器可以有效地处理越来越多的依赖项，确保平滑扩展。这可以防止手动管理复杂服务依赖项带来的混乱，使代码库更易于维护并减少出错的可能性。
NestJS 中的 DI 通过分离服务及其依赖项来鼓励松散耦合，从而更容易修改或替换系统的某些部分，而不会破坏整个应用程序。这种解耦还可以更轻松地测试和模拟服务。
虽然所有这些要点对于大型应用程序来说都非常有用，但 DI 模式对于小型项目来说可能会很复杂，尤其是在您不习惯的情况下。
NestJS 使用 IoC 容器自动进行依赖项管理，而 ExpressJS 和 Next.js 则依赖于依赖项的手动实例化。请注意我们只是说 userService 或 userRepository 属于特定类型。之后，所有额外的处理都由 NestJS 负责。我们不必考虑何时生成这些组件、它们有多少实例，或者其他任何事情。当然，我们确实可以控制这些。
这使得最后一个示例更具可扩展性、模块化且更易于测试。
这种方法的明显缺点是——学习曲线增加。对于所有固执己见的框架都是如此，而且对于小型应用程序来说，这可能感觉有点矫枉过正。
当我们谈论 NestJS 和其他两个框架之间的差异时，我认为是时候提及 Guards 了。 Guards 是管理权限的核心功能。它们提供了一种干净、可扩展的方式来根据用户角色或任何其他条件控制访问。防护具有高度可重用性，可以应用于特定路由或跨应用程序全局。
Express 和 Next 依赖于中间件或对会话进行手动检查，这使得小型应用程序变得更容易，但随着应用程序规模的扩大，其复杂性也会增加。
与 Guards 的工作方式类似，管道是 NestJS 的特定功能。在这个示例中，他们的主要目标是在将数据传递到控制器之前操纵或转换数据。
虽然可以通过中间件在 ExpressJS 和 NextJS 中实现相同的效果，但使用 Pipes 可以提供更好的错误处理和更轻松的大规模维护。
更不用说您可以自由地创建自己的自定义管道。
请注意，虽然注释/装饰器一开始可能很奇怪，但取决于您来自哪里，代码越大，有些东西实际上更容易维护和阅读。个人观点，虽然 NestJS 中的示例长了几行，但每行都短得多并且更容易理解。
此外，它再次强调了如何使用 NestJS 使事物更易于大规模维护。
您可以查看 NestJS 的官方文档以查看此示例的更长版本以及附加说明。它涉及的解释比我在本文中的目标要长，所以我只是链接它。
感谢您坚持到最后！我的目标是在这些最受认可的框架和 NestJS 之间举几个例子。这是我将在 NestJS 上撰写的一个简短系列的第一篇文章，并尝试将其概念与更常见的框架联系起来，以此来说明并使其更容易记住和理解。
如果您已经看到这里，我谢谢您，希望它对您有用！这是一张很酷的猫图片作为感谢！
