前後からGraphhQLに分離して、シートリップはNodeでどうやって実現しますか?\n
5913 ワード
Nodejsは2009年に開発されてから、今まで9年が経ちました.最新の安定版はすでに10.13になりました.世に出てから、Nodejsは先端エンジニアに好かれています.
シートリップの内部で、Nodejsも応用が広く、開発ツールからウェブアプリケーションまで、クライアントからサービスエンドまで、その姿を見ることができます.私達も最初からNode.jsで前後端の構造を完成して、最近GraphhQLを使ってマイクロサービスをして、航空券の部門はNode.jsの応用の探求模索の上で歩くほど広いです.
一、前後端分離
航空券事業部の先端に開発されたweb 1.0時代には、前後のコードが連結されており、典型的なサービス端末MVCアーキテクチャを採用しています.
このような開発モードでは、いくつかの問題と痛みがあります.
1)前後のコードが結合されていて、維持コストが大きいです.フロントエンドの学生はサービス開発言語に慣れていません.サービスエンドの学生もフロントエンドのインタラクションに慣れていません.
2)展示ロジックと業務ロジックが混在していて、前後のエンド開発クラスメートの職責が明確ではなく、一部の需要先はこのロジックがview層にあると言っています.バックエンドは変更すべきです.バックエンドは互換性のある処理をします.
3)プロジェクトの拡張性は低く、メンテナンス性は悪く、反復速度は遅い.
従来のMVCモードでは、view層に積載されている内容が多すぎるため、view層というブロックとフロントエンドの結合が多すぎて、全体の開発効率が低下しています.
これを剥がして、前後の力を集中させて自分の領域に注目してもらえますか?答えは肯定的です.クライアントとサービスを分離し、サーバーはデータの集約を担当しています.標準的なrestfulインターフェースを提供し、フロントエンドはデータのレンダリングを担当しています.
航空券H 5実践の前後端分離過程において、フロントエンドのアプリケーション層にPM 2＋Node.js(8.9.4)+Express(4.0)フレームを採用し、シートリップ基礎フレームctriputtilに基づいて、リディアの呼び出し、ABTestの取得、Qconfigの統合などのいくつかの常用機能のパッケージを改善しました.
なぜNodejsを選んだのですか?
1)NodejsはV 8エンジンを採用しています.JAvascriptコードを実行しています.フロントエンドの学生にとって、学習コストが低いです.
2)Nodejsはイベント駆動で、非閉塞性I/Oであり、フロントエンドのようなIO密集型への応用に非常に適している.
3)コミュニティの活性度が高く、大量の倉庫が使われます.
4)NPM生態圏の内容が豊富である;
5)クライアントコードとアプリケーションは、テンプレートと部分論理を共有し、ブラウザとサービスエンドコードの共用に適しています.
クライアント層では、vue.jsを選択し、会社のlizard.liteフレームに依存して、wbebpackを構築ツールとして採用し、UTを結合することによって開発品質を向上させます.
vueの使用にはVuexを用いて状態管理を行い、Vue Routerを用いてルーティング管理を行い、Lizard.liteを用いてモデル層管理を行う(データ取得、変換、キャッシュ、ログ記録、環境切替など).基礎データ情報に対してはLocastoreを用いてローカル耐久化記憶を行い、状態データに対してはSessionstoneを用いて管理し、その状態を確保することは次のsessionで有効である.
自動化コードの集積については、ESlintTSlintを採用していくつかの基本的な文法検査を行います.同時にmochaを使ってユニットテストを行います.
全体改造後のアーキテクチャは以下の特性を備えている.
モジュール化:ES 6 import+System.import+vue単一ファイルコンポーネント;
ルート制御:vue-router+async component;
サーバー通信:同じ構成のbusiniess model(Lizard Lite.Abs Model);
状態管理:vuex store;
コードの品質:standarjs+eslint+mocha+chai.
構築リリース:webpack dev server+npm scripts+html-minifer/uglify js/clean css;
全体の航空券H 5予約プロセスは単一ページ＋SSRモードで開発され、APP-LIKE式の体験を得ました.
直接Landingページに対して、APPSHELLを採用してデスクトップのスケルトンをロードし、ヘッドスクリーンのテレビロード速度を向上させ、非Landingページに対してSPAモードを採用し、後続ページのローディング速度の流暢度を向上させ、サーチエンジンの爬虫に対して、自動的に認識して、クライアントとサービスエンドコードの多重化を行う.
各ページのリソースローディングを低減するために、ページリソースファイルを分割し、後続のページリソースのプリローディングを行い、同時に大きなデータを利用してユーザー行動の予測とインターフェースデータのプリプロセッサを行い、ページ速度のローディング時間を大幅に向上させる.
二、Node.jsとretsful API
Node.jsを採用して前後端分離を完成した後、フロント全体のアーキテクチャは三つのブロックに分けられます.一つはブラウザレンダリングを主とするクライアントで、二つはNode.jsを主とするアプリケーションで、三つはフロントのデータアグリゲーション層で、フロントのデータアグリゲーション層はJAVAを主な開発言語として、バックグラウンドの下のインターフェースにドッキングします.
2016年以来、航空券フロント開発チームは敏捷な開発を推進し、scrumのモードを採用して敏捷な管理を行い、比較的に多い敏捷なチームを作りました.一部の敏捷なチームは比較的小さいので、人数は比較的少ないです.サービスエンドの資源は爆発してしまいます.改版類プロジェクトに遭遇すると、先端資源は爆発しますが、前後の技術スタックが統一されていないため、チーム内の開発資源はお互いに協調しにくいです.
チームの効果を最大限に発揮させるにはどうすればいいかという問題をずっと考えています.そこで、私達はscrumチームで技術スタックの統一を試みて、フロントのデータ重合層をNode.jsで実現します.
全体のNode層のアーキテクチャはH 5アプリケーション層と同様であり、PM 2＋Node.js(8.9.4)+Express(4.0)+CtripUtilを採用しており、標準的なrestful APIを提供するために、サービス入り口で自動化された登録方式を行い、クライアントアクセスが便利である.
Node層の内部でバックグラウンドインターフェースの呼び出しに対して、深いパッケージを作りました.使いやすく、同時に会社のcat/clogなどの汎用ログシステムにアクセスします.
サービスエンドの改造と技術スタックの統一を経て、チーム全体の効果も向上し、Node.jsで実現したインターフェースはオンライン後で性能が安定し、全体の消耗時間は50 ms以内である.
三、Retsful API-\u 0026 gt;GraphhQL
前のNode.jsを使って標準的なresttful APIの開発の試みを経て、Node.jsが実現するインターフェースのオンラインがますます多くなりました.フロント全体のアーキテクチャは以下の通りです.
いくつかのバージョンの反復を経験した後、いくつかの新しい問題を発見した.
1)異なるバージョンのクライアントの要求は異なり、同じインターフェースは異なるバージョンに対して異なる処理を行う必要がある.
2)異なるクライアントは契約の要求に対しても違っています.例えば、PCは画面サイズの関係で、インタフェースデザインでユーザーに与える情報はAPPより多く、PCとAPPは表示される情報に違いがあります.
3)APPにもバージョンの違いがあります.例えば7.15のバージョンと7.16のバージョン、7.16にいくつかの新しい機能が追加されています.新しいfetchが追加されています.もし一括して先端に配ったら、古いバージョンについても資源の浪費です.
4)クライアントは、いくつかの時に複数のインターフェースのまとめデータを呼び出して一緒に表示する必要があります.場合によってはまた別に呼び出します.サービスにとっては、動的に拡張可能なアーキテクチャが特に重要です.
5)フロントエンドはモデル層で使う構造とサービスエンド構造に違いがあるかもしれません.これらの違いをどうやって磨いたらいいですか?
この時、GraphhQLは私達の視野に入りました.GraphhQLは新しいAPI標準であり、より効率的で柔軟なデータクエリ方式を提供し、2015年にFacebookに正式にオープンしました.
その本質的にはAPIベースの照会言語であり、restful APIのパッケージ化であり、より使いやすいサービスを構築することを目的として、GraphQLを通じて、クライアントは必要なデータを簡単に入手することができる.
例えば、以下のこの例では、IDが1の都市情報を取得し、帰ってきたschema保護ID、name、Codeであればよく、nameはschemaを再定義する.
1)データの取得:GraphhQLは必要に応じて取得でき、呼び出し側がschemaを指定して異なる報文を返すことによって、Restful APIは次の送信と同じ構造である.
2)種類のシステム、強い検査:GraphhQLはType Systemを使用してAPIを定義し、公開のタイプはすべてSDLモードで作成し、前後の契約構造を統一して使用しやすいです.
3)URLの入り口:Resetの異なる要求の入り口は違っています.要求のURLに区分が必要です.GraphQLは入り口です.呼び出しのrequestで区別します.
4)呼び出し方式:Resetは複数の異なるインターフェースデータを取得する場合、複数の呼び出しを同時に行う必要があり、GraphQLはクエリーを統合して、ネットワークオーバーヘッドを低減することができる.
そこで私たちはチーム内でのパイロットGraphQLを開始し、技術アーキテクチャ上でPM 2+Node.js+Express-GraphhQLを採用し、Express-GraphhQLをコア中間部品として選択し、クライアントの要求入り口を統一します.
四、まとめ
Node.jsは航空券チームが早期の前後からGraphhQLに分離した実践において、フロントエンドグループの各モジュールに深く適用されました.今は航空券の先端アプリケーション層はすべてNode.jsで実現されました.
20近くのインターフェースはNode.jsを採用して開発しています.そのうちの大半はGraphhQLを通じて実現しています.一日平均の流量は200 Wぐらいで、全体Nodeのサービスが安定しています.今後もNode.jsの使用シーンを広げて、より大きな価値を発揮していきます.
もっと多くの内容は先端の頂上に注目してください.
シートリップの内部で、Nodejsも応用が広く、開発ツールからウェブアプリケーションまで、クライアントからサービスエンドまで、その姿を見ることができます.私達も最初からNode.jsで前後端の構造を完成して、最近GraphhQLを使ってマイクロサービスをして、航空券の部門はNode.jsの応用の探求模索の上で歩くほど広いです.
一、前後端分離
航空券事業部の先端に開発されたweb 1.0時代には、前後のコードが連結されており、典型的なサービス端末MVCアーキテクチャを採用しています.
このような開発モードでは、いくつかの問題と痛みがあります.
1)前後のコードが結合されていて、維持コストが大きいです.フロントエンドの学生はサービス開発言語に慣れていません.サービスエンドの学生もフロントエンドのインタラクションに慣れていません.
2)展示ロジックと業務ロジックが混在していて、前後のエンド開発クラスメートの職責が明確ではなく、一部の需要先はこのロジックがview層にあると言っています.バックエンドは変更すべきです.バックエンドは互換性のある処理をします.
3)プロジェクトの拡張性は低く、メンテナンス性は悪く、反復速度は遅い.
従来のMVCモードでは、view層に積載されている内容が多すぎるため、view層というブロックとフロントエンドの結合が多すぎて、全体の開発効率が低下しています.
これを剥がして、前後の力を集中させて自分の領域に注目してもらえますか?答えは肯定的です.クライアントとサービスを分離し、サーバーはデータの集約を担当しています.標準的なrestfulインターフェースを提供し、フロントエンドはデータのレンダリングを担当しています.
航空券H 5実践の前後端分離過程において、フロントエンドのアプリケーション層にPM 2＋Node.js(8.9.4)+Express(4.0)フレームを採用し、シートリップ基礎フレームctriputtilに基づいて、リディアの呼び出し、ABTestの取得、Qconfigの統合などのいくつかの常用機能のパッケージを改善しました.
なぜNodejsを選んだのですか?
1)NodejsはV 8エンジンを採用しています.JAvascriptコードを実行しています.フロントエンドの学生にとって、学習コストが低いです.
2)Nodejsはイベント駆動で、非閉塞性I/Oであり、フロントエンドのようなIO密集型への応用に非常に適している.
3)コミュニティの活性度が高く、大量の倉庫が使われます.
4)NPM生態圏の内容が豊富である;
5)クライアントコードとアプリケーションは、テンプレートと部分論理を共有し、ブラウザとサービスエンドコードの共用に適しています.
クライアント層では、vue.jsを選択し、会社のlizard.liteフレームに依存して、wbebpackを構築ツールとして採用し、UTを結合することによって開発品質を向上させます.
vueの使用にはVuexを用いて状態管理を行い、Vue Routerを用いてルーティング管理を行い、Lizard.liteを用いてモデル層管理を行う(データ取得、変換、キャッシュ、ログ記録、環境切替など).基礎データ情報に対してはLocastoreを用いてローカル耐久化記憶を行い、状態データに対してはSessionstoneを用いて管理し、その状態を確保することは次のsessionで有効である.
自動化コードの集積については、ESlintTSlintを採用していくつかの基本的な文法検査を行います.同時にmochaを使ってユニットテストを行います.
全体改造後のアーキテクチャは以下の特性を備えている.
モジュール化:ES 6 import+System.import+vue単一ファイルコンポーネント;
ルート制御:vue-router+async component;
サーバー通信:同じ構成のbusiniess model(Lizard Lite.Abs Model);
状態管理:vuex store;
コードの品質:standarjs+eslint+mocha+chai.
構築リリース:webpack dev server+npm scripts+html-minifer/uglify js/clean css;
全体の航空券H 5予約プロセスは単一ページ＋SSRモードで開発され、APP-LIKE式の体験を得ました.
直接Landingページに対して、APPSHELLを採用してデスクトップのスケルトンをロードし、ヘッドスクリーンのテレビロード速度を向上させ、非Landingページに対してSPAモードを採用し、後続ページのローディング速度の流暢度を向上させ、サーチエンジンの爬虫に対して、自動的に認識して、クライアントとサービスエンドコードの多重化を行う.
各ページのリソースローディングを低減するために、ページリソースファイルを分割し、後続のページリソースのプリローディングを行い、同時に大きなデータを利用してユーザー行動の予測とインターフェースデータのプリプロセッサを行い、ページ速度のローディング時間を大幅に向上させる.
二、Node.jsとretsful API
Node.jsを採用して前後端分離を完成した後、フロント全体のアーキテクチャは三つのブロックに分けられます.一つはブラウザレンダリングを主とするクライアントで、二つはNode.jsを主とするアプリケーションで、三つはフロントのデータアグリゲーション層で、フロントのデータアグリゲーション層はJAVAを主な開発言語として、バックグラウンドの下のインターフェースにドッキングします.
2016年以来、航空券フロント開発チームは敏捷な開発を推進し、scrumのモードを採用して敏捷な管理を行い、比較的に多い敏捷なチームを作りました.一部の敏捷なチームは比較的小さいので、人数は比較的少ないです.サービスエンドの資源は爆発してしまいます.改版類プロジェクトに遭遇すると、先端資源は爆発しますが、前後の技術スタックが統一されていないため、チーム内の開発資源はお互いに協調しにくいです.
チームの効果を最大限に発揮させるにはどうすればいいかという問題をずっと考えています.そこで、私達はscrumチームで技術スタックの統一を試みて、フロントのデータ重合層をNode.jsで実現します.
全体のNode層のアーキテクチャはH 5アプリケーション層と同様であり、PM 2＋Node.js(8.9.4)+Express(4.0)+CtripUtilを採用しており、標準的なrestful APIを提供するために、サービス入り口で自動化された登録方式を行い、クライアントアクセスが便利である.
Node層の内部でバックグラウンドインターフェースの呼び出しに対して、深いパッケージを作りました.使いやすく、同時に会社のcat/clogなどの汎用ログシステムにアクセスします.
サービスエンドの改造と技術スタックの統一を経て、チーム全体の効果も向上し、Node.jsで実現したインターフェースはオンライン後で性能が安定し、全体の消耗時間は50 ms以内である.
三、Retsful API-\u 0026 gt;GraphhQL
前のNode.jsを使って標準的なresttful APIの開発の試みを経て、Node.jsが実現するインターフェースのオンラインがますます多くなりました.フロント全体のアーキテクチャは以下の通りです.
いくつかのバージョンの反復を経験した後、いくつかの新しい問題を発見した.
1)異なるバージョンのクライアントの要求は異なり、同じインターフェースは異なるバージョンに対して異なる処理を行う必要がある.
2)異なるクライアントは契約の要求に対しても違っています.例えば、PCは画面サイズの関係で、インタフェースデザインでユーザーに与える情報はAPPより多く、PCとAPPは表示される情報に違いがあります.
3)APPにもバージョンの違いがあります.例えば7.15のバージョンと7.16のバージョン、7.16にいくつかの新しい機能が追加されています.新しいfetchが追加されています.もし一括して先端に配ったら、古いバージョンについても資源の浪費です.
4)クライアントは、いくつかの時に複数のインターフェースのまとめデータを呼び出して一緒に表示する必要があります.場合によってはまた別に呼び出します.サービスにとっては、動的に拡張可能なアーキテクチャが特に重要です.
5)フロントエンドはモデル層で使う構造とサービスエンド構造に違いがあるかもしれません.これらの違いをどうやって磨いたらいいですか?
この時、GraphhQLは私達の視野に入りました.GraphhQLは新しいAPI標準であり、より効率的で柔軟なデータクエリ方式を提供し、2015年にFacebookに正式にオープンしました.
その本質的にはAPIベースの照会言語であり、restful APIのパッケージ化であり、より使いやすいサービスを構築することを目的として、GraphQLを通じて、クライアントは必要なデータを簡単に入手することができる.
例えば、以下のこの例では、IDが1の都市情報を取得し、帰ってきたschema保護ID、name、Codeであればよく、nameはschemaを再定義する.
Request:{ city: getCityInfo(id: 1) { ID name: Name Code }}Response:{ \u0026quot;data\u0026quot;: { \u0026quot;city\u0026quot;: { \u0026quot;ID\u0026quot;: 1, \u0026quot;name\u0026quot;: \u0026quot; \u0026quot;, \u0026quot;Code\u0026quot;: \u0026quot;BJS\u0026quot; } }Schema：module.exports = new GraphQLObjectType({ 'name': 'CityInfo', 'description': ' ', 'fields': { 'Code': { 'description': ' ', 'type': GraphQLString }, 'ID': { 'description': ' ID', 'type': GraphQLInt }, 'Name': { 'description': ' ', 'type': GraphQLString } }})1)データの取得:GraphhQLは必要に応じて取得でき、呼び出し側がschemaを指定して異なる報文を返すことによって、Restful APIは次の送信と同じ構造である.
2)種類のシステム、強い検査:GraphhQLはType Systemを使用してAPIを定義し、公開のタイプはすべてSDLモードで作成し、前後の契約構造を統一して使用しやすいです.
3)URLの入り口:Resetの異なる要求の入り口は違っています.要求のURLに区分が必要です.GraphQLは入り口です.呼び出しのrequestで区別します.
4)呼び出し方式:Resetは複数の異なるインターフェースデータを取得する場合、複数の呼び出しを同時に行う必要があり、GraphQLはクエリーを統合して、ネットワークオーバーヘッドを低減することができる.
そこで私たちはチーム内でのパイロットGraphQLを開始し、技術アーキテクチャ上でPM 2+Node.js+Express-GraphhQLを採用し、Express-GraphhQLをコア中間部品として選択し、クライアントの要求入り口を統一します.
四、まとめ
Node.jsは航空券チームが早期の前後からGraphhQLに分離した実践において、フロントエンドグループの各モジュールに深く適用されました.今は航空券の先端アプリケーション層はすべてNode.jsで実現されました.
20近くのインターフェースはNode.jsを採用して開発しています.そのうちの大半はGraphhQLを通じて実現しています.一日平均の流量は200 Wぐらいで、全体Nodeのサービスが安定しています.今後もNode.jsの使用シーンを広げて、より大きな価値を発揮していきます.
もっと多くの内容は先端の頂上に注目してください.