Node.js プロジェクトを開始するときに従う主な手順

この記事では、Node.js アプリケーションを開発するときに私が従ういくつかの手順に重点を置きたいと思います。これらの手順は、ビジネス ニーズをカバーし、長期的な成長に向けた柔軟性と拡張性を備えた信頼性の高いアプリを提供するのに役立ちます。

問題を解決できるアプローチやテクノロジーを始める前に、どの問題を解決するのかを理解する必要があります。だからこそ、考慮すべき重要なことはビジネスの背景です。
プロジェクトが本番後にどのように成長するか、また後でビジネスに何が必要になるかは予測できません。あなたができることは、会社が MVP に何を必要としているかを話し合い、後の変更や移行に備えてスケーラブルな方法でプロジェクトを開発することです。

MVP のコンセプトと目標を決めたら、エンジニアリング レベルに進み、アプリケーションのスケーラビリティと信頼性を確保するのに役立つアプローチとテクノロジーを検討しましょう。

フレームワーク

実装するアーキテクチャ (モノリス、サーバーレス、マイクロサービス) を選択することから始めることをお勧めします。現時点では最も一般的なアーキテクチャ アプローチがありますが、これに限定されるわけではありません。
アーキテクチャに基づいてフレームワークを選択できます。 Node.js エコシステムには多くのフレームワークが存在するため、ここでは注意してください。
私の選択肢は次のとおりです:

• Express.js は、後で置き換えられる小規模なプロジェクトやプロトタイプに最適です。

• Nest.js はいくつかのアーキテクチャをカバーしており、何を使用するかを決定する際に考慮するデフォルトのフレームワークです。これは、ドメインに分割され、後で個別のマイクロサービスに変換されるモノリスに最適です。

• マイクロサービスを考慮する場合は、Molecular が適しています。それでも、インフラストラクチャと全体的な開発プロセスが複雑なため、プロジェクトの開始時にマイクロサービスを作成することはあまり好きではありません。これは、モノリスを中心にマイクロサービスを構築したり、モノリスから MS に移行したりするための優れたフレームワークです。

• 次へ.js。はい、私も何を使うかを決めるときに考慮します。プロジェクトに取り組むエンジニアがあなただけである場合、またはエンジニア全員がフルスタック開発者である場合に最適です。 Vercel を使用すると、多くのメリットが得られ、迅速に行動できるようになります。ただし、複雑さのため、後でバックエンドを別のコードベースに移行する必要がある可能性があります。

• サーバーレスは素晴らしいものであり、おそらくサーバーレス アーキテクチャを処理するための唯一のソリューションです。プロトタイピングや小さな API にとっては素晴らしい機能です。それでも、追加サービスとして、またはサーバーレスが適している狭いアプリケーション部分を処理するために、モノリスまたは MS アーキテクチャと一緒に使用することを好みます。

タイプスクリプト

ほぼすべてのプロジェクトとアーキテクチャに適しています。ただし、さまざまな記事でその利点と欠点が詳しく説明されているため、ここで終わりたくありません。

データストレージ

もちろん、ビジネス ニーズに基づいて SQL データベースまたは NoSQL データベースを選択する必要があります。あるいは、両方のタイプのストレージが必要な場合もあります。私は、これまでに取り組み、豊富な経験を積んだ複数のデータベースから選択することがよくあります。

• 私のデフォルトの選択は PostgreSQL です。最高のオプティマイザーを備えた完璧なリレーショナル ストレージです。ほとんどのニーズをカバーできます。

• 私はよく MongoDB、特にサーバーレス バージョンを検討します。これはリレーショナル モデルの利点を活用した堅牢なデータベースであり、ほとんどのストレージでは提供されない多くの機能を備えた強力な NoSQL データベースです。

• リレーショナルの利点を持たない強力な NoSQL ソリューションが必要な場合は、DynamoDB を検討してください。私も頻繁に使用しますが、主にプロジェクトの狭い部分を処理するために使用します。このデータベースは特別な設計になっているため、使用する前に学習する必要があるので注意してください。たくさんのテーブルを作成して、それを MongoDB として、あるいはリレーショナル DB として使用しようとする人のようにならないでください。この場合、製品が成長したときに大きな問題が発生します。

また、私が頻繁に使用する ElasticSearch や Redis などの非永続ストレージについても触れたいと思います。 ElasticSearch はプロジェクトの開始時には適切ではありませんが、後で複雑なインデックスや検索を処理する必要があるときにそれを考慮して使用することができます。 Redis または別のメモリ データベースは使いやすく、実装が簡単です。プロジェクトの開始時でもキャッシュが必要になることが多いので、あると便利です。

Data access layer

Here, I use different approaches depending on the product side. I like starting with ORM and migrating to query builder or raw SQL in narrow parts. For NoSQL databases, I wouldn’t say I like ODM’s and prefer using drivers. For example, I don’t particularly appreciate using Mongoose and choose Node.js driver instead of this. I think it’s more flexible and simple than ODM, and it doesn’t require you to use the relational model.

For relational databases, there are many different libraries you can use here, but if you use an SQL database, you can consider TypeORM.

Development workflow

The last thing I want to mention is the development workflow. I like to keep it as simple as possible and use easy-to-implement tools to help automate workflows, moving to more flexible and complex solutions if needed. Here are my recommendations for tools you can consider:

• Github actions. It’s an excellent CI/CD tool you can configure quickly and easily.

• Dependabot is a fantastic tool for keeping packages in the latest versions and searching for vulnerabilities.

• Terraform. I use it to manage infrastructure. It simplifies many things if at least a few people work on a project. As the project grows, it becomes massive, and maybe for better state management, you will need tools like Terragrunt to keep infrastructure-related code simple. If you use AWS as a cloud provider, you can also use AWS CDK. It’s a nice tool with Typescript support, but it’s available only for AWS, and if you need something from a different cloud infrastructure, the code will be much more complex than Terraform. That’s why I prefer the Terraform even for AWS.

以上がNode.js プロジェクトを開始するときに従う主な手順の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。