フロントエンド アプリケーション開発に Node.js を使用するにはどうすればよいですか?次の記事では、プレゼンテーション層アプリケーションの開発を含む、プレゼンテーション層 Node.js アプリケーションを効率的に開発する方法を紹介します。今日私が共有したソリューションは単純なシナリオ向けであり、フロントエンド開発者がコーディング経験がなくても、Node.js に関する背景知識や専門知識を習得することなく、いくつかの単純なサーバーサイド開発タスクを完了できるようにすることを目的としています。
私の多くの中小企業はこの状況に直面しています。大企業の開発者は自分の専門職に集中することを好み、ORM、サーバー、運用とメンテナンスなどの専門知識を習得する必要があります。 , ただし、小規模な会社では、開発タスクを直接開始して完了することができます。したがって、私の計画では、私がスタートアップで試したツールの組み合わせを紹介し、それらを簡単に共有したいと思います。
ここに示されている内容が、実際に私が今日話したいすべてです。 [関連チュートリアルの推奨事項: nodejs ビデオ チュートリアル 、プログラミング教育 ]
最下層は Nest.js 開発フレームワークです。実際、すべてのフレームワークが備えている最も基本的な機能のみを提供するため、どのフレームワークを使用するかは問題ではありません。 Nest.js はネットワーク層とアプリケーション層をカプセル化したもので海外での利用が多く、Spring Boot と開発方法が似ているため Java に詳しい人にとっては馴染み深いものです。
上位層では、Prisma という特殊な ORM、比較的純粋な ORM、およびモデル層の ORM を使用します。今日の私の計画全体は、Prisma を通じてすべての開発プロセスを接続し、複数のツールを相互に接続することです。基本的に、基盤となるデータ層から最上位の制御層、そして API ドキュメント全体に至るアプリケーション開発ソリューションを完成させるには、ごくわずかなコードを記述するだけで済みます。
私が最近注目しているのは、この 漸進的強化 スキームで、多くの外国人コミュニティースキームがこれに焦点を当てています。言い換えれば、今日私が話していることも含め、これらのソリューションはすべてプラグイン可能であり、他の開発作業に影響を与えることなく、それらを使用するかどうかを選択したり、一部のみを使用したりすることができます。したがって、会社がまだ比較的小規模で、この部分の仕事をフロントエンドに任せたい場合は、単にこれらのツールを使用させるだけで済みます。しかし、会社やチームが成長するにつれて、ORM、データベース、キャッシュなどを理解するプロの Node.js 開発者が必要になる場合があります。現時点では、上位レベルのツールをアンインストールしたり、Nest.js を使用したり、Nest.js を他のフレームワークに置き換えたりすることもできます。これは柔軟なアイデアであり、上位層のツールは結合度が低く、置き換え可能です。
今日紹介する 3 つのコア ツールは、Nest.js、Prisma、GraphQL です。 3つともとても重要です。
まずは、Prisma について簡単に紹介します 公式サイトの Prisma の紹介には「次世代 Node.js」とあります。および TypeScript ORM」と述べ、型を強力にサポートしていることを強調しました。
Prisma の使用に関しては、実際には ORM ツールですが、その焦点はモデルやクラスなどを自分で定義できるようにすることではなく、使用を開始するときに最初に記述ファイルを定義することにあります。この説明ファイルと GraphQL に精通している学生は、GraphQL には 2 つの開発方法があることを知っているはずです。1 つはアーキテクチャ ファースト、もう 1 つはコード ファーストです。 Prisma は完全なソリューションとして、海外では GraphQL と密接に関連していますが、それらの間の結合は特に厳密ではなく、比較的緩和されています。
したがって、Prisma の開発では、最初に記述ファイルを定義する必要があります。このファイルには、
#
したがって、Prisma を使用すると、その使用法が少し奇妙であることに気付くかもしれません。通常、他のライブラリを使用する場合は、ノード モデルで ORM のコードを直接参照するだけで済みます。ただし、Prisma のノード モデルのコードは実行時に動的に生成されるため、ダウンロード時にはまだ存在しません。ですので、Prismaを使う場合は、先ほど右のコードに書いた「this.prisma.tag」のようなモデルを実際に定義するわけではなく、通常のオブジェクトとして使うことができます。
もちろん、Prisma には他にも多くの機能がありますが、ここではその一部を列挙しました。
Prisma は、一連のデータ修正ツールを提供します。実際、多くの ORM がすでにこの機能を使用しています。しかし、一部の中小企業や小規模製品では、このツールを使用すると実際に非常に便利です。ただし、一部の大規模チームでは、このデータ修正ツールの使用が困難な場合があります。ただし、この点に関しては、この分野における Prisma の機能は実際には比較的成熟しています。
モデル内の情報を変更する必要がある場合、修正されたステートメントを生成して予測を行うのに役立ちます。たとえば、以前にフィールドを削除し、このフィールドに情報があり、必須である場合などです。これを不要に変更すると、システムは非常に複雑な修正ステートメントを生成し、予測を行ってユーザーに選択をさせます。
したがって、いくつかの小規模なシナリオでは、このデータ修正ツールは非常に便利です。最後に、修正されたレコードが生成され、この修正されたレコードを Git に同期できます。運用環境でこのツール セットを使用する必要があるかどうかについては、ここでは詳しく説明しません。
ノーコード、ノーコード、すべては先延ばし次第です。 Zaozao とチャットし、ローコードで遊んで、バス リンクに乗りましょう: www.zaozao.run/conf/c63
次はについてです。 Nest. js フレームワークの簡単な紹介。このフレームワークは実際には他の多くのフレームワークと非常に似ており、さまざまな開発ツールをカスケードするための階層化やグローバル フックなどのメカニズムを実装しています。 Nest.js で記述するロジックの量を最小限に抑えたいと考えています。
したがって、最終的に、完全な追加、削除、変更、クエリ操作が、複雑な操作も含めて、基本的にコードなしで Nest.js 側に実装されていることがわかります。そこで、このフレームワークがどのようなものかを簡単に説明します。
Nest.js フレームワークには、実際にはコントローラー、プロバイダー、モジュラーという 3 つの中心的な概念があります。
最も低くて最も重要なものはモジュラーです。これは、すべてのモジュールを完全なビジネス ロジックに編成するために使用される一般的な入り口です。各モジュラーには完全な層があり、入り口はコントローラーであり、すべてのリクエストは最初にコントローラー層に入ります。プロバイダーはサービス層であり、主に通常作成されるサービス層ロジックと同様のいくつかの機能を提供します。
ご覧のとおり、ここではモデル層については明示的に言及されていません。モデル層にはいくつかの定義がありますが、今日は基本的にモデル層を占める Prisma を使用します。したがって、Nest.js の開発プロセスは実際には通常の開発プロセスです。つまり、アプリケーションを作成するときに、コントローラー、サービスを作成し、DTO と VO を定義する必要があります。
Prisma を入手したら、Prisma を使用して ORM ライブラリを生成できます。また、DTO および VO コードの生成にも役立つため、コントローラーとサービスだけに集中する必要があります。さらに、Nest.js は、追加、削除、変更、クエリを実行するためのスキャフォールディングも提供します。このコマンドを実行すると、以下のようなファイル構造が生成されるので、あとはコントローラーとサービスを入力するだけです。
コントローラーを生成し、CRUD ツールであるコードを手動で記述するだけということは誰にとっても簡単なことのように思えますが、実際にはこれらは非常に基本的なものであり、役に立ちません。ロジックとコードを生成します。したがって、パラメータの型を自分で定義し、サービス層を呼び出す必要があります。もちろん、このコントローラー層のコードは比較的単純で、多くのことを行う必要はなく、ロジックはすべてサービス層にあります。ここでは、基本的なページングや条件付きフィルタリング技術、結合クエリなどの追加、削除、変更、確認のロジックを記述する必要があります。
フロントエンドがサーバーサイド開発者になることは望んでいません。サーバーサイドのフロントエンドを書くことの意義は何ですか?特に小規模なチームの場合、なぜこれを行うのでしょうか?実際、このフレームワークの本来の目的は、フロントエンドをサーバーサイド開発者に変えることではないと思いますし、そうすることはバックエンド開発者から疑問視されるかもしれません。 .js?根本的に何か変わったのでしょうか？あまり。
それでは、なぜフロントエンドがサーバーサイド開発を行う必要があるのでしょうか?実際、私の当初の目的は効率を向上させることであり、通常のインターフェイスの小さな変更に直面して、フロントエンド設計者、フロントエンド開発者、サーバー開発者が変更の完了に参加する必要を避け、それによって効率の損失を軽減しました。フロントエンドがサーバー側のコードにできるだけ触れないようにすると同時に、フロントエンドの絶え間ない変化に適応するためにインターフェイスを柔軟に調整できることを願っています。したがって、find、where、select、count などのコードをみんなに書いてほしくありません。これらの概念に慣れていないフロントエンドにとっては、問題を書きやすく、コストもかかりたくないからです。彼らがこれらのことをどのように書いているかを監視してください。
実際の開発プロセスでは、フロントエンド コードは、サーバーによって以前に開発されたインターフェイスにもアクセスする必要があります。これらのインターフェイスをフロントエンド コードのデータ アクセスとより適切に統合するには、Swagger の形式 (つまり、Open API の標準形式) を Graphql データに変換できる swagger-to-graphql ツールを使用する必要があります。フロントエンド コードが直接アクセスできるようにモデル化する サーバー側インターフェイス。このライブラリの使用は非常に簡単で、Swagger ドキュメントを渡し、プロバイダーを定義し、Swagger データを渡すだけで、使用する透過的な GraphQL インターフェイスが自動的に生成されます。 GraphQL ビューでは、サーバーによって定義されたインターフェイスと使用可能なすべてのクエリ パラメーターを確認できます。
第 63 回モーニング チャット カンファレンス - ローコード、ノーコード、ローコードを楽しみましょう。バスに乗ります: www.zaozao.run/conf/c63
私が共有したのは上記のすべてです。最も基本的な 3 つのこと、つまり Nest について紹介しました。 .js、Prisma、GraphQL、および私が使用するいくつかのツール。
Prisma フレームワークがどのようにして Service にコードを 1 行も書かない状態を実現するのかについて詳しく説明していませんでしたが、これは、実現が難しい GraphQL の Resolver に Prisma 自体が適応できるためです。通常の ORM ライブラリを使用します。さらに、今日共有するコンテンツは、私の GitHub リポジトリ (github.com/0xYootou/Ne…) にあります。このトピックに興味がある場合は、認証、エラー処理、戻り結果のカプセル化や、小規模なアプリケーションの開発に非常に便利な Nest.js に関するいくつかの事項を含む私のウェアハウスを見つけることができます。
ノード関連の知識の詳細については、nodejs チュートリアル を参照してください。
以上がプレゼンテーション層の Node.js アプリケーションを効率的に開発する方法について説明する記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
