SSRとプログレッシブエンハンスメントを備えた同形RealWorldアプリケーションの開発。 パート1-はじめにとスタックの選択

2017年春、 Thinksterトレーニングプロジェクトの共同設立者であるEric Simons は 、 RealWorldプロジェクト 、 デモアプリケーションおよびその仕様を発表しました。 このプロジェクトは、通常の「todo」デモを超えて、さまざまなフレームワークとテクノロジーの機能のより応用された比較と研究、および問題を解決するための開発アプローチと方法の目標を宣言しました。

はじめに

RealWorldについて

著者は、プロジェクトのアイデアと意味を次のように説明しています。

だから1年ほど前に、私が抱えていた問題についてこの実装をしました：



新しいフレームワークのコア概念とイデオロギーを習得することは、不必要にイライラさせられます。



ドキュメントを読んで、コードペンで不自然な例を実行し、「todo」サンプルアプリをリッピングして再度組み立て、CLIをローカルにインストールして...レースに出発します！



あなたがそうでないことを除いて。 近くさえありません。 あなたが実際にあなた自身のアプリを構築しようとし始めたとき、それはマーフィーの法則があなたを襲ったときだからです。



-エリックサイモンズ

実際、 RealWorldはMediumまたはHabrなどのブログ社会プラットフォームのクローンであり、 「Conduit」と呼ばれます。これは、同じ仕様とレイアウトに従ってさまざまなフロントエンドおよびバックエンド（はい、フルスタック）テクノロジーを使用する愛好家によって開発されています。 プロジェクトに参加したい人はだれでも、GitHubのリポジトリに新しい問題を作成する必要があります。そこで、目的の技術スタックを記述し、プロジェクトのスターターキットをフォークして、開発を開始します。 さらに、開発者は、AngularJSでEricによって作成されたデモアプリケーションを使用して、実際の最終結果を確認する機会があります。



実際、それぞれの新しい実装の結果はまったく同じアプリケーションですが、他のテクノロジーまたはアプローチを使用して記述されている必要があります。 React / Redux 、 Elm 、 Angular2 、 React / MobX 、 Svelte / Sapperおよびその他のフレームワークのフォークは 、既に実装および公開されています。 途中で、 Vue 、 Emberなども。







バックエンドテクノロジーの中でも、プロジェクトはNode / Express、Laravel、Django、ASP.NET Core、Railsなどに実装されています。







2017年の終わりに、プロジェクトは、パフォーマンス（最初の意味のあるペイント）、バンドルのサイズ（gzip）、プロジェクトの実装に必要なコードの行数（loc）の3つの基準に従って、最も人気のある 9つのフロントエンド実装の比較を準備しました 。



現時点では、 RealWorldはWeb開発に最適なデモプロジェクトの1つです。 かなり実際のWebアプリケーションと最新の技術スタックの例を使用して、最も一般的な問題の解決策が含まれています。 このプロジェクトにはgithubに12,000以上の星があり、私の意見では、非常に有用で興味深いものです。 ただし、よくあることですが、Habréには彼に関する情報はほとんどありません。 ダイジェストで言及したことが2〜3個 。

私は何について話している

だから、なぜ私はこれをすべて書いているのですか？ ここ数年、私は実際にWebアプリケーションを作成する同型（言い換えれば、「ユニバーサル」）アプローチの伝道者です。 当社はまた、 「環境に依存しないアプリ」と呼ばれるアプローチを実践しています 。 変更せずに任意の環境（より正確には、環境のリスト）で動作できるアプリケーション。 これは私たちにとって特に重要です。なぜなら、同社はWebからさまざまなIoTまで、幅広いプラットフォームのリストを開発しているからです。



「伝道者」という言葉はあまりに大げさかもしれませんが、この間、私はかなりの数の議論や会議に参加し、この困難で物議を醸すトピックに関する自分のレポートを何 回 か読みました。 さらに、私は、Webスタックに基づくアプリケーションだけでなく、最新のWebアプリケーションの「アクセシビリティ」 、 「プログレッシブエンハンスメント」 、および「SEO」の問題を長く非常に心配しています。





レポートの一部として、Material Design Lite テンプレートの 1つに基づく小さなブログの形で同形デモアプリケーションを実装しました。 率直に言って、実際にはバックエンドのない小さなアプリケーションだとしましょう-その存在はJSON Placeholderなどの助けを借りてのみエミュレートされます 。



残念なことに、昨年の終わりにRealWorldプロジェクトについてしか知りませんでしたが、そのプロジェクトに参加する時間が足りませんでした。 時間が経つにつれて少し簡単になったので、次の特性を満たす（現在のアプリケーションではなく）RealWorldアプリケーションを実装しようと思います。

プロジェクト宣言：

1. RealWorldプロジェクトの仕様に準拠します。
2. サーバー作業を完全にサポート（SSRおよびその他すべて）。
3. 本格的なSPAとしてクライアントに取り組みます。
4. 検索エンジンによって索引付けされます。
5. クライアントでJSをオフにして作業します。
6. 100％同形（一般）コード; *
7. 実装のために、「ハーフメジャー」と「クランチ」を使用しないでください。 **
8. 最大のシンプルでよく知られた技術スタックを使用します。 ***
9. 最終的なバンドルのサイズは、100Kb gzipを超えないようにしてください。
10. アプリケーションコードの行数は1000 locを超えてはなりません。

ご覧のとおり、リストはかなり野心的です。 ここには、議論の余地のある「同型」と、誰もが切望しているが達成できない「進歩的な強化」があります。 そして、SPAのスタイルで動作するブログプラットフォームですが、同時にSEOをサポートします。 これらはすべて、既存のバックエンド上にある単一のコードベースで、TORに従って変更できません。



そういえば。 同型アプローチを嫌う人の多くは、本格的な同型アプリケーションを作成するためには、特別な方法でバックエンドを書き換える必要があるとしばしば言うので、このプロジェクトは私にとって興味深いものです。 つまり、既存のバックエンドは機能しません。 または、間違いなくNodeJSをバックエンドとして使用する必要があります。それ自体はfu fu fuです。 または、何らかの特別な方法で要件とTKおよびその他のナンセンスを策定する必要があること。



また、同型コードははるかに複雑であり、一般に同型アプリケーションを記述することは難しく、時間がかかり、経済的であると考えられます。 私の「マニフェスト」の最後の3つのパラグラフは、これらの誤解から生じています。



要するに、私にとって、このプロジェクトは、これを完全にまたは部分的に反論する機会であり、同時に楽しむことでもあります。 私は本当に成功することを願っています。 トピックに興味があり、このパスをステップでフォローしたい場合は、切り替えないでください！

スタック選択

あなたはすでに理解していると確信していますが、そうでない場合は明確にします-アプリケーションのフロントエンド部分を作成します。 このため、RealWorldプロジェクトは以下を含む仕様をフロントエンドに提供します。

• 必要なすべての機能をサポートするREST APIを備えたレディバックエンド 。
• Bootstap 4のカスタムテーマ 。
• アプリケーションのすべてのページのHTMLマークアップ。
• ルーティングのガイドライン。

指示の完全なリストはここにあります 。



そのため、すぐにマニフェストのステップ8を実行し、可能な限り最も単純なスタックを選択します。

• アプリケーションのRactive +プラグイン。
• WebサーバーのExpress +プラグイン。
• Webpack +アセンブリ用プラグイン。
• httpリクエストのAxios 。

ご覧のとおり、非常にシンプルに見えます。 接頭辞「isomorphic-」が付いた超大型の特別なソリューションはありません。



おそらく、このリストの多くの「ダークホース」はRactiveJSかもしれません 。 はい、確かに、ビッグスリーの一部ではなく、人気の記録を破らないフレームワークの選択は奇妙に思えるかもしれません。 ただし、このタスクには最適です。これは私のお気に入りのツールの1つであり、「反応角ビュー」チュートリアルの通常の日常的なルーチンを少し多様化したいと考えています。 さらに、おそらくそうすることで、私はいくつかの身近なことについて新しい見方を示すこともできるでしょう。 これは私の目標ではありませんが。

サーバー側

Habrは依然として技術的なリソースであるため、結果としてこの記事は単なる意図の宣言ではなく、おそらくこの部分では既にWebサーバーの初期コードを実装することになります。 このコードは、特定のプロジェクトの実装に依存しません。 実際、レポート用に作成した既存のデモプロジェクトからコードを取得し、それを調整します。

建築について

これは、アプリケーションアーキテクチャ全体の外観です。 いくつかの重要なポイント：

1. Fontendの部分は、RactiveのクライアントサーバーアプリケーションとExpress / Nodeの純粋にサーバーベースのアプリケーションに分かれています。
2. RealWorldバックエンドは、フロントエンドサーバーの背後にあります。
3. REST APIへのHTTPリクエストは、フロントエンドサーバーを介してバックエンドにプロキシされます。

ワークフロー

1. ユーザーはURLをアドレスバーに入力します。
2. クライアントはサーバーに同期要求を行います。
3. サーバーは着信要求を処理し、メインアプリケーションコードを実行します。
4. アプリケーションの準備ができた時点で、サーバーはアプリケーションの現在の状態をHTMLでレンダリングし、応答を返します。
5. クライアントは受信したHTMLを解釈し、関連リソース（CSS、JS、画像、フォントなど）の読み込みを開始します。
6. ユーザーはコンテンツを受け取ります。
7. アプリケーションコードはバックグラウンドでダウンロードされ、初期化されます。
8. ユーザーはインターフェースを操作します。
9. アプリケーションのクライアントコードは、アクションを処理し、サーバーへの非同期要求を作成し、状態を更新します。

このプロセスは、同形のWebアプリケーションでは完全に正常であり、この場合でも同様に機能します。

プロジェクト構造

私がよく知っている同様のプロジェクトの構造を使用します。

• /資産 -静的リソース。
• / config -jsonアプリケーションの構成。
• / dist -webpackの出力ディレクトリ。
• /ミドルウェア -サーバースクリプトのディレクトリ。
• / src-アプリケーションのソースコード。
• /テスト -テスト。
• /ツール -ユーティリティ。
• / views-純粋にサーバー側のHTMLテンプレート。
• server.js -Express上のWebサーバーのコード。

そしてもちろん、すべての種類のpackage.json 、 webpack.config.jsおよびその他の構成ファイルの完全な束。その説明はチュートリアルの範囲外です。

コードを書く

Webサーバーのメインコードは./server.jsファイルにあります。 Express自体に加えて、実用的なタスクを解決するためにプラグイン（ 「エクスプレスミドルウェア」 ）のいくつかを使用します。 以前は、もちろん、必要なモジュールはすべて、 npm iコマンドを使用してpackage.jsonに登録する必要があります。



最初に、サードパーティのモジュールとExpress自体を接続します。

const express = require('express'), helmet = require('helmet'), compress = require('compression'), cons = require('consolidate');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用されているすべてのExpress拡張機能は完全に普通のものであり、同型とは関係ありません。 それらのほとんどは非常に標準的です。 以下に簡単な説明と目的を示します。

• ヘルメット -特定のHTTPヘッダーを設定することにより、いくつかの一般的な攻撃からフロントエンドを保護します。
• 圧縮 -サーバー応答のgzip圧縮。
• 統合 -Expressのテンプレートモジュール。

次に、これまで何もしないミドルウェアをいくつか作成し、それらを接続します。

 const app = require('./middleware/app'), api = require('./middleware/api'), req = require('./middleware/req'), err = require('./middleware/err');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• app-サーバーでアプリケーションを起動するコードはここにあります。
• apiは、APIバックエンドのhttp要求のプロキシです。
• req-すべてのHTTP要求の前処理。
• err-サーバーエラー処理。

メインサーバーの設定common.jsonを接続し、Expressと拡張機能を初期化します。

 const config = require('./config/common'); const server = express(); server.engine('html', cons.mustache); server.set('view engine', 'html'); server.use(helmet()); server.use(compress({ threshold: 0 })); server.use(express.static('dist'));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Expressのテンプレートエンジンとして口ひげをインストールします。 なぜ彼は正確に？ Ractiveはテンプレートに口ひげ構文を使用しているだけなので、均一性を実現します。



次に、静的全体も圧縮したいこと、および静的が「./dist」フォルダーにあることを通知します（Webpackもそこに生成されます）。



次に、最後の仕上げ：

 server.use(req()); server.all('/api/*', api()); server.use(app()); server.use(err()); server.listen(config.port);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードには特別な説明は必要ありません。 ここでのキーポイントは次のとおりです。

• / api / *へのすべてのリクエストはREST API（apiミドルウェア）にプロキシされます。
• 他のすべてのリクエストは、アプリケーション（アプリミドルウェア）を起動し、HTMLを返します。
• 特定のケース（oauthなど）を処理するために、追加の「ミドルウェア」を追加することが可能です。 中間の「ミドルウェア」が機能しなかった場合、またはnext（）に進んだ場合、制御は常に「アプリミドルウェア」に転送されます。
• サーバー側のエラーが発生すると、 「errミドルウェア」でストールが発生します。

Expressの経験があまりない純粋なフロントエンドの開発者でさえ、このようなプリミティブコードを簡単に理解できるように思えます。 もちろん、彼が「ミドルウェア」とは何か、そして一般にこの概念を理解している場合。



これまでのところ、このコードは実際には何もしません。 いずれの場合でも、プロジェクト内で行う必要があることは行いません。 次の記事では、純粋にサーバー側のコードを追加し、アプリケーション自体のコードに進みます。



ご清聴ありがとうございました！



UPD： SSRとProgressive Enhancementを使用した同形RealWorldアプリケーションの開発。 パート2-Hello World



UPD 2： RactiveJSロゴを更新し、マニフェストにパラグラフ9および10も追加しました（ パート3を参照）