In this article, I want to emphasize some steps I follow when developing Node.js applications. These steps help me deliver reliable apps that cover business needs and are flexible and scalable for long-term growth.
Before starting with approaches and technologies that can solve problems, you should understand which issues you will solve. That’s why the essential thing you should be thinking about is the business context.
You can’t predict how the project will grow after production and what the business will need later. What you can do is discuss what the company needs for the MVP and develop the project in a scalable manner to prepare for later changes and migrations.
After you have concepts and goals for the MVP, let’s move down to the engineering level and examine approaches and technologies that can help ensure the application's scalability and reliability.
Framework
It’s better to start by choosing the architecture you will implement — monolith, serverless, or microservices. There’s the most common architectural approach for now, but you are not limited here.
You can choose a framework based on the architecture. Be careful here because many frameworks exist in the Node.js ecosystem.
My choices are:
Express.js is excellent for small projects or prototypes, which will be replaced later.
Nest.js covers several architectures, which is a default framework I consider when deciding what to use. It’s excellent for the monolith, which will be divided into domains and later transformed into separate microservices.
Moleculer will be good if you consider microservices. Still, I’m not a big fan of creating microservices when the project starts due to the complexity of the infrastructure and overall development processes. It’s an excellent framework for building microservices around your monolith or migrating from monolith to MS.
Next.js. Yes, I also consider it when deciding what I should use. It’s perfect if you are the only engineer who will work on the project or if all engineers are full-stack developers. Along with Vercel, you will have many benefits and be able to move quickly. However, later, you will probably need to migrate the backend to a separate codebase due to complexity.
Serverless is fantastic and probably the only solution for handling serverless architecture. It’s incredible for prototyping or small APIs. Still, I prefer to use it along with monolith or MS architectures as additional services or to handle narrow application parts where serverless is suitable.
Typescript
It’s suitable for almost every project and architecture. However, I don’t want to stop here because different articles have extensively described its benefits and drawbacks.
Data storage
Of course, you must choose SQL or NoSQL databases based on your business needs, or maybe you need both types of storage. I frequently select from several databases I worked on and have extensive experience with.
My default choice is PostgreSQL. It’s perfect relational storage with one of the best optimizers. It can cover most of your needs.
Frequently, I consider MongoDB, especially the serverless version. It’s a robust database that benefits from the relational model and is a powerful NoSQL database with many features that most storages don’t provide.
If you need a powerful NoSQL solution without relational benefits, consider DynamoDB. I also use it frequently, but mostly to handle narrow parts of projects. Be careful with this database because it has a special design you must learn before use. Don’t be like people who create many tables and try to use them as MongoDB or even as relational DB. In this case, you will have big problems when the product grows.
Also, I want to mention non-persistent storages like ElasticSearch and Redis, which I frequently use. ElasticSearch is not good when the project starts, but you can take it into account and use it later when you need to handle complex indexes and searches. Redis or another memory database is friendly and easy to implement. We frequently need a cache even at the beginning of the project, so it’s nice to have it.
数据访问层
在这里，我根据产品方面使用不同的方法。我喜欢从 ORM 开始，然后迁移到查询构建器或狭窄部分的原始 SQL。对于 NoSQL 数据库，我不会说我喜欢 ODM，而是更喜欢使用驱动程序。例如，我不太喜欢使用 Mongoose 并选择 Node.js 驱动程序而不是这个。我觉得它比ODM更灵活、更简单，而且不需要你使用关系模型。
对于关系数据库，这里有很多不同的库可以使用，但如果你使用 SQL 数据库，可以考虑 TypeORM。
开发流程
我最后想提的是开发工作流程。我喜欢尽可能保持简单，并使用易于实施的工具来帮助自动化工作流程，如果需要，可以转向更灵活和更复杂的解决方案。以下是我对您可以考虑的工具的建议：
Github 操作。这是一款优秀的 CI/CD 工具，您可以快速轻松地进行配置。
Dependabot 是一个出色的工具，可以让软件包保持最新版本并搜索漏洞。
地形。我用它来管理基础设施。如果至少有几个人参与一个项目，就会简化很多事情。随着项目的发展，它变得庞大，也许为了更好的状态管理，您将需要像 Terragrunt 这样的工具来保持基础设施相关的代码简单。如果您使用 AWS 作为云提供商，还可以使用 AWS CDK。这是一个很好的工具，支持 Typescript，但它仅适用于 AWS，如果您需要来自不同云基础设施的东西，代码将比 Terraform 复杂得多。这就是为什么即使对于 AWS，我也更喜欢 Terraform。
以上是启动 Node.js 项目时遵循的主要步骤的详细内容。更多信息请关注PHP中文网其他相关文章！
