サーバー上のExt JS

Ext JSライブラリに関しては、専門家から非常に多くの否定的意見を聞く必要があります：重い、高価な、バグだらけ。 原則として、ほとんどの問題はそれを調理できないことに関連しています。 Sencha Cmdとすべてのcssを使用して正しく組み立てられたプロジェクトは、1Mbリージョンでの生産の重量を量ります。これは同じAngularに匹敵します。 はい、グリッチはそれほど多くありません...



Senchaの発案がこれとは異なる方法で関連している可能性がありますが、その原則的な反対者でさえ、深刻なイントラネットプロジェクトを構築するための最適なソリューションを見つけることは難しいと認めています。



私の意見では、Ext JSで最も価値があるのはUIコンポーネントのコレクションではなく、優れたOOPアーキテクチャです。 近年のJSの急速な発展を考慮しても、7年前にExt JSで実装された必要なものの多くは、ネイティブクラス（名前空間、ミックスイン、静的プロパティ、親メソッドの便利な呼び出し）にまだありません。 これが、数年前にバックエンドでExt JSクラスの立ち上げを実験するきっかけとなりました。 最初の同様の実験については、すでにHabréに投稿しました。 この記事では、古いアイデアの新しい実装といくつかの新しいアイデアについて説明します。



始める前に、次の質問に注意してください。あなたはどう思いますか、どこで実行され、以下のコードスニペットは何をしますか？

Ext.define('Module.message.model.Message', { .... /* scope:server */ ,async newMessage() { ......... this.fireEvent('newmessage', data); ...... } ... })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードはサーバーで実行され、サーバーに接続されているすべてのクライアントマシンの「Module.message.model.Message」クラスのすべてのインスタンスで「newmessage」イベントを発生させます。



サーバー側Ext JSを使用する可能性を示すために、簡単なチャットプロジェクトを分析します。 ユーザーがニックネームを入力したときにログインすることはありません。 一般的なメッセージまたはプライベートメッセージを投稿できます。 チャットはリアルタイムで機能するはずです。 希望する人は、ビジネスでこの経済すべてをすぐに試すことができます。

設置

開始するには、nodejs 9+とredis-serverが必要です（既にインストールされていることが前提です）。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーを起動します。

 node server
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザーで、 localhostページを開きます：3000 / www / auth /

ニックネームを入力してEnterキーを押します。



このプロジェクトはデモであるため、古いブラウザー（ES8デザインがあります）のサポートはありません。新しいChromeまたはFFを使用してください。

サーバー

順番に行きましょう。



サーバーコード（server.js）

 //   http-  express //   Ext JS     express const express = require('express'); const staticSrv = require('extjs-express-static'); const app = express(); const bodyParser = require('body-parser'); //    global = { config: require('config') } //     Ext JS require('extjs-on-backend')({ //     express app, //         wsClient: 'Base.wsClient' }); //    Ext.Loader.setPath('Api', 'protected/rest'); Ext.Loader.setPath('Base', 'protected/base'); Ext.Loader.setPath('Www', 'protected/www'); //   http   app.use( bodyParser.json() ); app.use(bodyParser.urlencoded({ extended: true })); //     Ext JS  app.use('/api/auth', Ext.create('Api.auth.Main')); app.use('/www/auth', Ext.create('Www.login.controller.Login')); //    app.use(staticSrv(__dirname + '/static')); //   const server = app.listen(3000, () => { console.log('server is running at %s', server.address().port); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、ここではすべてがExpress上のサーバーの標準です。 興味深いのは、対応するルートを提供するExt JSクラスを含めることです。

 app.use('/api/auth', Ext.create('Api.auth.Main')); app.use('/www/auth', Ext.create('Www.login.controller.Login'));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

REST APIの実装

Api.auth.Mainクラスは、REST API（protected / rest / auth / Main.js）へのリクエストを処理します。

 Ext.define('Api.auth.Main', { extend: 'Api.Base', //   //     routes: [ { path: '/', get: 'login'}, { path: '/restore', post: 'restoreLogin' }, { path: '/registration', post: 'newuser'}, { path: '/users', get: 'allUsers'} ] //     : // {query: <...>, params: <...>, body: <...>} ,async login(data) { return {data:[{ id:1, subject: 111, sender:222, }]} } ,async restoreLogin() { ... } ,async newuser() { ... } ,async allUsers() { .... } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーでXTemplateを使用したHTMLページの生成

2番目のクラスWww.login.controller.Loginは、ログインフォーム（protected / www / login / controller / Login.js）を使用して通常のhtmlページを作成します。

 Ext.define('Www.login.controller.Login', { //      "" : // ,    .. extend: 'Www.Base' //    //   ,   .. ,baseTpl: 'view/inner' //     // ,   ,loginFormTpl: 'login/view/login' //  ,routes: [ { path: '/', get: 'loginForm', post: 'doLogin'} ] //  html   //       ,async loginForm () { return await this.tpl(this.loginFormTpl, { pageTitle: 'Login page', date: new Date() }); } ,async doLogin (params, res) { if(params.body.name && /^[a-z0-9]{2,10}$/i.test(params.body.name)) { this.redirect(`/index.html?name=${params.body.name}`, res); return; } return await this.tpl(this.loginFormTpl, { pageTitle: 'Login page', date: new Date() }); } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テンプレートは標準のXTemplate（protected / www / login / view / login.tpl）を使用します

 <h2>{pageTitle} (date: {[Ext.Date.format(values.date,'dmY')]})</h2> <form method="post"> <input name="name" placeholder="name"> <button type="submit">enter</button> </form>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のすべては完全な標準セットであり、細心の注意を払った読者が言うように、このため、Ext JSをサーバーに転送することでこの庭を保護する必要はありませんでした。 したがって、記事の第2部に進み、すべての目的を示します。

お客様

静的ディレクトリに通常のクライアントExt JSアプリケーションを作成しましょう。 この例では、cmdの使用を意図的に考慮せず、既に構築されているext-allおよび標準テーマを使用しました。 アセンブリの問題は別のトピックであり、おそらく別の投稿に専念します。



すべてはapp.jsで始まります

 //   Ext.Loader.setConfig({ enabled: true, paths: { "Core": "app/core", "Admin": "app/admin", "Module": "app/admin/modules", "Ext.ux": "ext/ux" } }); //    this.token = Ext.data.identifier.Uuid.createRandom()(); //      //    () //    (   ) Ext.WS = Ext.create('Core.WSocket', { token: this.token, user: new URLSearchParams(document.location.search).get("name") }); //   Ext.application({ name: 'Example', extend: 'Ext.app.Application', requires: ['Admin.*'], autoCreateViewport: 'Admin.view.Viewport' })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Webソケットの存在は重要なポイントです。それは、以下で説明するすべての魔法を実装できることです。



ページ上の要素のレイアウトは、Admin.view.Viewportクラス（static / app / view / Viewport.js）に含まれています。 面白いことは何もありません。



主な機能要素（ユーザーリスト、メッセージバー、送信フォーム）は、個別のモジュールとして実装されます。

ユーザーリスト

このリストの単純なアルゴリズムは次のとおりです。ページが開かれると、現在のユーザーがサーバーからロードされます。 新しいユーザーが接続すると、サーバーは「Module.users.model.UserModel」クラスで「add」イベントを生成し、切断されると、同じクラスで「remove」イベントが発生します。 問題は、サーバー側でイベントがトリガーされ、クライアントでそれを追跡できることです。



さあ、まず最初に。 クライアント側では、Store jugglesデータ（静的/アプリ/モジュール/ユーザー/ストア/ UsersStore.js）

 Ext.define('Module.users.store.UsersStore', { extend: 'Ext.data.Store' ,autoLoad: true ,total: 0 ,constructor() { //         this.dataModel = Ext.create('Module.users.model.UserModel'); //      this.dataModel.on({ add: (records) => { this.onDataAdd(records) }, remove: (records) => { this.onDataRemove(records) } }) this.callParent(arguments) } //   load ,async load() { //      const data = await this.dataModel.$read(); //   this.total = data.total; //    UI this.loadData(data.data); } ,getTotalCount() { return this.total; } //          ,onDataAdd(records) { this.add(records[0]); } //   --  ,onDataRemove(records) { this.remove(this.getById (records[0].id)) } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つの興味深い点があります。 まず、「const data = await this.dataModel。$ Read（）;」という行は、モデルのサーバー側メソッドを呼び出します。 Ajaxを使用したり、プロトコルをサポートしたりする必要はありません。サーバーメソッドをローカルとして呼び出すだけです。 同時に、安全性は犠牲になりません（詳細については以下を参照）。



次に、this.dataModel.on（...）の標準構造により、サーバーによって生成されるイベントを追跡できます。



モデルは、アプリケーションのクライアント部分とサーバー部分の間のブリッジです。 それは光の二元論のようなものです-フロントエンドとバックエンドの両方のプロパティを実装します。 モデルを注意深く見てみましょう。

 Ext.define('Module.users.model.UserModel', { extend: 'Core.data.DataModel' /* scope:client */ ,testClientMethod() { ... } ,testGlobalMethod() { ... } /* scope:server */ ,privateServerMethod() { .... } /* scope:server */ ,async $read(params) { //      redis const keys = await this.getMemKeys('client:*'); let data = [], name; for(let i = 0;i<keys.length;i++) { //         name = await this.getMemKey(keys[i]); if(name) { data.push({ id: keys[i].substr(7), name }) } } //    return { total: data.length, data } } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コメントに注意してください/ *スコープ：サーバー* /および/ *スコープ：クライアント* /-これらの構造は、メソッドのタイプを決定するサーバーのラベルです。



testClientMethod-このメソッドはクライアントでのみ実行され、クライアント側でのみ使用可能です。

testGlobalMethod-このメソッドはクライアントとサーバーで実行され、クライアントとサーバーの部分で使用できます。

privateServerMethod-メソッドはサーバー上で実行され、サーバー上でのみ呼び出すことができます。

$ readは、サーバー側でのみ実行される最も興味深いタイプのメソッドですが、クライアントとサーバーの両方で呼び出すことができます。 プレフィックス「$」は、サーバー側のメソッドをクライアント側で使用できるようにします。



Webソケットを使用して、クライアントの接続と切断を追跡できます。 Base.wsClientクラスのインスタンスがユーザー接続ごとに作成されます（protected / base / wsClient.js）

 Ext.define('Base.wsClient', { extend: 'Core.WsClient' //      ,usersModel: Ext.create('Module.users.model.UserModel') //       ,async onStart() { //   "add"    this.usersModel.fireEvent('add', 'all', [{id: this.token, name: this.req.query.user}]); //     redis await this.setMemKey(`client:${this.token}`, this.req.query.user || ''); //   ""      , //     await this.queueProcess(`client:${this.token}`, async (data, done) => { const res = await this.prepareClientEvents(data); done(res); }) } //      ,onClose() { //   "remove"    this.usersModel.fireEvent('remove', 'all', [{id: this.token, name: this.req.query.user}]) this.callParent(arguments); } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

fireEventメソッドには、標準のものとは異なり、追加のパラメーターがあり、イベントがトリガーされるクライアントに渡されます。 1つのクライアント識別子、識別子の配列、または文字列「all」を渡すことは許容されます。 後者の場合、イベントは接続されているすべてのクライアントでトリガーされます。 それ以外の場合、これは標準のfireEventです。

メッセージの送受信

フォームコントローラー（static / app / admin / modules / messages / view / FormController.js）は、メッセージの送信を担当します。

 Ext.define('Module.messages.view.FormController', { extend: 'Ext.app.ViewController' ,init(view) { this.view = view; //     this.model = Ext.create('Module.messages.model.Model'); //      this.msgEl = this.view.down('[name=message]'); //     this.usersGrid = Ext.getCmp('users-grid') //    "" this.control({ '[action=submit]' : {click: () => {this.newMessage() }} }) } //     ,newMessage() { let users = []; //     const sel = this.usersGrid.getSelection(); if(sel && sel.length) { sel.forEach((s) => { users.push(s.data.id) }) } //        if(users.length && users.indexOf(Ext.WS.token) == -1) users.push(Ext.WS.token); //       this.model.$newmessage({ to: users, user: Ext.WS.user, message: this.msgEl.getValue() }) //    this.msgEl.setValue(''); } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージはサーバー上のどこにも保存されず、「newmessage」イベントが発生します。 興味深いのは、「this.fireEvent（ 'newmessage'、data.to、msg）;」という呼び出しです。ここでは、クライアント識別子がメッセージの受信者として送信されます。 したがって、プライベートメッセージの配布が実装されます（静的/アプリ/管理者/モジュール/メッセージ/モデル/ Model.js）。

 Ext.define('Module.messages.model.Model', { extend: 'Core.data.DataModel' /* scope:server */ ,async $newmessage(data) { const msg = { user: data.user, message: data.message } if(data.to && Ext.isArray(data.to) && data.to.length) { this.fireEvent('newmessage', data.to, msg); } else { this.fireEvent('newmessage', 'all', msg); } return true; } })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーの場合と同様に、メッセージリストのデータはストアを駆動します（静的/アプリ/管理者/モジュール/メッセージ/ストア/ MessagesStore.js）

 Ext.define('Module.messages.store.MessagesStore', { extend: 'Ext.data.Store', fields: ['user', 'message'], constructor() { //       Ext.create('Module.messages.model.Model', { listeners: { newmessage: (mess) => { this.add(mess) } } }) this.callParent(arguments); } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、この例で興味深いのはこれだけです。

可能な質問

クライアントでのサーバーメソッドの可用性はもちろん良好ですが、セキュリティはどうですか？ 悪意のあるハッカーがサーバーコードを見て、バックエンドをクラックしようとすることができますか？



いいえ、彼は成功しません。 まず、すべてのサーバーメソッドは、クライアントブラウザーに送信されるときにクラスコードから削除されます。 このため、コメント/ディレクティブ/ * scope：... * /が意図されています。 第二に、最も公開されているサーバー側メソッドのコードは、クライアント側でリモート呼び出しメカニズムを実装する中間構造によって置き換えられます。



再びセキュリティについて。 クライアントでサーバーメソッドを呼び出すことができる場合、そのようなメソッドを呼び出すことはできますか？ そして、これがデータベースのクリーニング方法である場合は？



クライアントからは、名前に$プレフィックスが含まれるメソッドのみを呼び出すことができます。 このような方法の場合、チェックとアクセスのロジックを自分で決定します。 外部ユーザーは、$なしでサーバーメソッドにアクセスできず、それらも表示されません（前の回答を参照）



クライアントとサーバーが密接にリンクされているモノリシックなシステムを手に入れたようです。 水平スケーリングは可能ですか？



実際、システムはモノリシックに見えますが、そうではありません。 クライアントとサーバーは、異なるマシン上で「ライブ」できます。 クライアントは、サードパーティのWebサーバー（Nginx、Apacheなど）で実行できます。 クライアントとサーバーの分離の問題は、自動プロジェクトビルダーによって非常に簡単に解決されます（これについては別の投稿を書くことができます）。 内部サービスメッセージングメカニズムを実装するために、システムはキューを使用します（これにはRedisが必要です）。 したがって、新しいマシンを追加するだけで、サーバー部分を簡単に水平方向に拡張できます。



通常の開発アプローチでは、原則として、バックエンドはさまざまなクライアントアプリケーション（Webサイト、モバイルアプリケーション）と接続できる特定のAPIセットを提供します。 あなたの場合、Ext JSで書かれたクライアントだけがバックエンドで動作できることがわかりましたか？



サーバー、特にモジュールモデルでは、特定のビジネスロジックが実装されます。 REST API経由でアクセスできるようにするには、小さな「ラッパー」で十分です。 対応する例は、この記事の最初の部分に記載されています。

結論

ご覧のとおり、かなり複雑なアプリケーションを快適にコーディングするために、フロントエンドとバックエンドに1つのライブラリを用意することで十分対応できます。 これには大きな利点があります。



開発プロセスをスピードアップします。 各チームメンバーは、バックエンドとフロントエンドで作業できます。 「このAPIがサーバーに表示されるのを待っている」という理由でのダウンタイムは関係ありません。



少ないコード。 コードの同じセクションをクライアントとサーバーで使用できます（チェック、検証など）。



このようなシステムを維持することは、はるかに簡単で安価です。 2人の多様なプログラマの代わりに、システムは1人（または同じ2人ですが交換可能）をサポートできます。 同じ理由で、チームの離職に伴うリスクも低くなります。



すぐに使用可能なリアルタイムシステムを作成する機能。



バックエンドとフロントエンドに単一のテストシステムを使用します。