シームレスなクライアントサーバー

クライアントサーバープロジェクトでは、コードベースをクライアントとサーバーの2つの部分（場合によってはそれ以上）に明確に分離する必要があります。 多くの場合、そのような各部分は、独自の開発者チームによってサポートされる独立した独立したプロジェクトの形式で実行されます。



この記事では、コードのバックエンドとフロントエンドへの標準的な厳密な分離を批判的に検討します。 また、クライアントとサーバーの間に明確な境界線がないコードの代替案を検討してください。

標準アプローチの短所

プロジェクトを標準的に2つの部分に分割することの主な欠点は、クライアントとサーバー間のビジネスロジックが侵食されることです。 ブラウザでフォーム内のデータを編集し、クライアントコードで検証し、祖父の村（サーバー）に送信します。 サーバーは別のプロジェクトです。 そこで、受信したデータの正確さを確認する（つまり、クライアントの機能を複製する）、追加の操作を行う（データベースに保存する、電子メールを送信するなど）必要があります。



したがって、ブラウザーのフォームからサーバーのデータベースまでの情報のパス全体を追跡するには、2つの異なるシステムを詳しく調べる必要があります。 役割がチームに分かれており、バックエンドとフロントエンドに異なる専門家が責任を負う場合、それらの同期に関連して追加の組織上の問題が発生します。

夢を見てみましょう

1つのモデルで、クライアント上のフォームからサーバー上のデータベースへのデータパス全体を記述できるとします。 コードでは、次のようになります（コードは機能していません）：

class MyDataModel { //         verifyData(data) { //   .... return true; } //       client saveData(data) { if(this.verifyData(data)) this.writeDataToDb(data) else consol.log('error') } //  .     server writeDataToDb(data) { if(this.verifyData(data)) this.db.insert(data) else consol.log('error') } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、モデルのビジネスロジック全体が目の前にあります。 そのようなコードの保守は簡単です。 1つのモデルにクライアント/サーバーメソッドを組み合わせると、次のような利点があります。

1. ビジネスロジックは1箇所に集中しており、クライアントとサーバー間で共有する必要はありません。
2. プロジェクト開発の過程で、サーバーからクライアントへ、またはクライアントからサーバーへ機能を簡単に移行できます。
3. バックエンドとフロントエンドで同じメソッドを複製する必要はありません。
4. プロジェクトのビジネスロジック全体に対する単一のテストセット。
5. プロジェクトの責任の水平線を垂直線に置き換えます。

最後のポイントをより詳細に明らかにします。 このようなスキームの形式の通常のクライアントサーバーアプリケーションを想像してください。







Vasyaはフロントエンド、Fedya-バックエンドを担当します。 責任の線は水平に走っています。 この方式には、垂直構造の欠点があります。スケーリングが難しく、耐障害性が低いです。 プロジェクトが拡大している場合、VasyaとFedyaのどちらを強化するかという、かなり難しい選択をする必要があります。 または、Fedyaが病気になったり、辞めたりした場合、Vasyaは彼を置き換えることはできません。



ここで提案するアプローチにより、責任範囲を90度拡張し、垂直アーキテクチャを水平に変えることができます。







このようなアーキテクチャは、スケーリングがはるかに容易で、フォールトトレラントです。 VasyaとFedyaは交換可能になります。



理論的には見栄えが良いので、クライアントとサーバーの個別の存在をもたらすすべてを失うことなく、これらすべてを実践に移してみましょう。

問題の声明

製品に統合されたクライアントサーバーは絶対に必要ありません。 それどころか、そのような決定はあらゆる観点から非常に有害です。 タスクは、開発プロセスでは、バックエンドとフロントエンドのデータモデルの単一のコードベースを持つことですが、出力は独立したクライアントとサーバーになります。 この場合、標準的なアプローチのすべての利点が得られ、上記のプロジェクトの開発とサポートの利便性が得られます。

解決策

私はかなり長い間、1つのファイルにクライアントとサーバーを統合する実験を行ってきました。 最近までの主な問題は、標準JSでは、クライアントとサーバーのサードパーティモジュールの接続があまりにも異なっていたことでした。node.jsのrequire（...）、クライアントのすべてのAJAXマジック。 ESモジュールの登場により、すべてが変化しました。 最新のブラウザでは、「インポート」が長い間サポートされています。 Node.jsはこの点で若干遅れており、ESモジュールは「--experimental-modules」フラグを有効にした場合のみサポートされます。 近い将来、node.jsでモジュールがそのまま動作することが期待されています。 さらに、何かが大きく変わることはまずありません。 ブラウザでは、この機能はデフォルトで長い間機能しています。 ESモジュールをクライアントだけでなくサーバー側でも使用できるようになったと思います（この件について反論がある場合は、コメントを書いてください）。



ソリューションスキームは次のようになります。







プロジェクトには3つの主要なカタログが含まれています。



保護 -バックエンド。

パブリック -フロントエンド。

共有 -共有クライアントサーバーモデル。



別のオブザーバープロセスが共有ディレクトリ内のファイルを監視し、変更があると、クライアント用とサーバー用（保護/共有およびパブリック/共有ディレクトリ内）に変更ファイルのバージョンを個別に作成します。

実装

シンプルなリアルタイムメッセンジャーの例を考えてみましょう。 新しいnode.js（バージョン11.0.0があります）およびRedis（インストールについてはここでは説明しません）が必要です。



例のクローンを作成します。

 git clone https://github.com/Kolbaskin/both-example cd ./both-example npm i
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブザーバープロセス（図のオブザーバー）をインストールして実行します。

 npm i both-js -g both ./index.mjs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが正常である場合、オブザーバーはWebサーバーを起動し、共有および保護されたディレクトリ内のファイルの変更の監視を開始します。 共有が変更されると、クライアントとサーバーのデータモデルの対応するバージョンが作成されます。 保護が変更されると、ウォッチャーは自動的にWebサーバーを再起動します。



リンクをクリックすると、ブラウザでメッセンジャーのパフォーマンスを確認できます



http://localhost:3000/index.html?token=123&user=Vasya







（トークンとユーザーは任意です）。 複数のユーザーをエミュレートするには、異なるトークンとユーザーを指定して、別のブラウザーで同じページを開きます。



今、少しコード。

Webサーバー

保護された/ server.mjs

 import express from 'express'; import bodyParser from 'body-parser'; // -     //  -  import wsServer from './lib/wsServer.mjs'; const app = express(); //   - wsServer(app); //  mime  mjs express.static.mime.define({'application/javascript': ['js','mjs']}); app.use( bodyParser.json() ); app.use(bodyParser.urlencoded({ extended: true })); //      public app.use(express.static('public')); const server = app.listen(3000, () => { console.log('server is running at %s', server.address().port); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは通常のエクスプレスサーバーであり、ここでは何も興味深いことはありません。 node.jsのESモジュールには、mjs拡張が必要です。 一貫性を保つために、クライアントにもこの拡張機能を使用します。

お客様

public / index.html

 <!DOCTYPE html> <html lang="en"> <head> ... <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> <script src="/main.mjs" type="module"></script> </head> <body> ... <ul id="users"> <li v-for="user in users"> {{ user.name }} ({{user.id}}) </li> </ul> <div id="messages"> <div> <input type="text" v-model="msg" /> <button v-on:click="sendMessage()"></button> </div> <ul> <li v-for="message in messages">[{{ message.date }}] <strong>{{ message.text }}</strong></li> </ul> </div> </body> </html>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、クライアントでVueを使用していますが、本質は変わりません。 Vueの代わりに、データモデルを別のクラス（ノックアウト、角度）に分離できるものがあります。



public / main.mjs

 //      - import ws from "/lib/Ws.mjs"; //       import Messages from "./shared/messages/model/dataModel.mjs"; //    import Users from "./shared/users/model/dataModel.mjs"; //  - (     ) window.WS = new ws({ token: new URLSearchParams(document.location.search).get("token"), user: new URLSearchParams(document.location.search).get("user") }); //       new Messages({ el: '#messages' }) //       new Users({ el: '#users' })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

main.mjsは、データモデルを対応するビューに関連付けるスクリプトです。 コードを簡素化するために、アクティブユーザーとメッセージフィードのリストのサンプル表現がindex.htmlに直接組み込まれています

データモデル

共有/メッセージ/モデル/ dataModel.mjs

 //    //          , //    import Base from '@root/lib/Base.mjs'; export default class dataModel extends Base { //!#client constructor(attr) { attr.data = { msg: '', messages: [] } super(attr); //     this.on('newmessage', (data) => { this.messages.push(data) }) } //!#client async sendMessage(e) { //    await this.$sendMessage(this.msg); this.msg = ''; } //!#server async $sendMessage(text) { //   newmessage     this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのいくつかのメソッドは、メッセージをリアルタイムで送受信するすべての機能を実装します。 ディレクティブ！#Clientおよび！#Serverは、オブザーバープロセスにどの部分（クライアントまたはサーバー）のどのメソッドを対象とするかを指示します。 メソッドを定義する前にこれらのディレクティブがない場合、そのようなメソッドはクライアントとサーバーの両方で利用できます。 ディレクティブの前のコメントスラッシュはオプションであり、標準IDEが構文エラーを宣誓しないようにするためにのみ存在します。



パスの最初の行は＆ルート検索を使用します。 クライアントとサーバーのバージョンを生成する場合、＆rootはそれぞれ、パブリックおよび保護ディレクトリへの相対パスに置き換えられます。



もう1つの重要な点：クライアントメソッドからは、名前が「$」で始まるサーバーメソッドのみを呼び出すことができます。

 ... //    async sendMessage(e) { await this.$sendMessage(this.msg); <-    this.msg = ''; } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはセキュリティ上の理由で行われます。外部からは、このために特別に設計された方法にしか頼ることができません。



オブザーバーがクライアントとサーバー用に生成したデータモデルのバージョンを見てみましょう。



クライアント （パブリック/共有/メッセージ/モデル/ dataModel.mjs）

 import Base from '/lib/Base.mjs'; export default class dataModel extends Base { __getFilePath__() {return "messages/model/dataModel.mjs"} // constructor(attr) { attr.data = { msg: '', messages: [] } super(attr); //     this.on('newmessage', (data) => { this.messages.push(data) }) } // async sendMessage(e) { //    await this.$sendMessage(this.msg); this.msg = ''; } // ... async $sendMessage() {return await this.__runSharedFunction("$sendMessage",arguments)} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアント側では、モデルはVueクラスの子孫です（Base.mjs経由）。 したがって、通常のVueデータモデルと同様に使用できます。 オブザーバーは__getFilePath__メソッドをモデルのクライアントバージョンに追加しました。これはクラスファイルへのパスを返し、$ sendMessageサーバーメソッドコードを、本質的にrpcメカニズム（__runSharedFunctionは親クラスで定義されます）を介してサーバーで必要なメソッドを呼び出す構成体に置き換えました。



サーバー （保護/共有/メッセージ/モデル/dataModel.mjs）

 import Base from '../../lib/Base.mjs'; export default class dataModel extends Base { __getFilePath__() {return "messages/model/dataModel.mjs"} ...       ... // async $sendMessage(text) { //   newmessage     this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーバージョンでは、__ getFilePath__メソッドも追加され、ディレクティブでマークされたクライアントメソッドは削除されます！#Client



生成されたモデルの両方のバージョンでは、削除された行はすべて空の行に置き換えられます。 これは、デバッガーのエラーメッセージがモデルのソースコード内の問題のある行を簡単に見つけることができるようにするためです。

クライアントとサーバーの相互作用

クライアントでサーバーメソッドを呼び出す必要がある場合は、それを行うだけです。

呼び出しが同じモデル内にある場合、すべてが簡単です：

 ... !#client async sendMessage(e) { await this.$sendMessage(this.msg); this.msg = ''; } !#server async $sendMessage(msg) { // -    } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別のモデルを「プル」できます。

 import dataModel from "/shared/messages/model/dataModel.mjs"; var msg = new dataModel(); msg.$sendMessage('blah-blah-blah');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

逆方向、すなわち サーバーでクライアントメソッドを呼び出しても機能しません。 技術的には、これは実行可能ですが、実用的な観点からは意味がありません。 サーバーは1つですが、多くのクライアントがあります。 クライアント上のサーバーでアクションを開始する必要がある場合、イベントメカニズムを使用します。

 //    ... //!#client constructor(attr) { .... //       "newmessage" this.on('newmessage', (data) => { this.messages.push(data) }) } //!#server async $sendMessage(text) { //     newmessage     this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

fireEventメソッドは3つのパラメーターを取ります：イベントの名前、イベントの宛先、およびデータ。 受信者はいくつかの方法で設定できます。キーワード「all」-イベントはすべてのユーザーまたは配列に送信され、イベントの宛先となるクライアントのセッショントークンがリストされます。



イベントはデータモデルクラスの特定のインスタンスに関連付けられておらず、ハンドラーは、fireEventが呼び出されたクラスのすべてのインスタンスで起動します。

水平バックエンドのスケーリング

提案された実装におけるクライアント/サーバーモデルのモノリシック性は、一見、サーバー部分の水平スケーリングの可能性に大きな制限を課すはずです。 しかし、これはそうではありません。技術的には、サーバーはクライアントに依存していません。 「パブリック」ディレクトリをどこにでもコピーして、そのコンテンツを他のWebサーバー（nginx、apacheなど）経由で提供できます。



サーバーパーツは、新しいバックエンドインスタンスを起動することで簡単に拡張できます。 RedisとKueキューシステムは、個々のインスタンスと対話するために使用されます。

1つのバックエンドに対するAPIと異なるクライアント

実際のプロジェクトでは、多様なサーバークライアントが1つのサーバーAPI（Webサイト、モバイルアプリケーション、サードパーティサービス）を使用できます。 提案されたソリューションでは、これはすべて追加のダンスなしで利用できます。 サーバーメソッドの呼び出しの裏には、古き良きRPCがあります。 Webサーバー自体は、クラシックエクスプレスアプリケーションです。 同じデータモデルの必要なメソッドを呼び出すルートにラッパーを追加するだけで十分です。

ポスト台本

この記事で提案されているアプローチは、クライアントサーバーアプリケーションの革命的な変更を主張するものではありません。 開発プロセスにほんの少しの快適さを追加するだけで、1か所で組み立てられたビジネスロジックに集中できます。



このプロジェクトは実験的であり、あなたの意見では、この実験を継続する価値があるかどうかをコメントに書いてください。