express+reactソリューション(一)
2998 ワード
常に非常に軽量なフレームワークが必要で、私たちの多くの非常に簡単なニーズを満たすと同時に、一定の拡張性、柔軟性、緩和性が要求され、迅速な開発が要求され、一定の負荷能力があり、ここでは簡単なソリューションを設計しました.
データ・サービス・フレームワーク>>Github
こうぞう
より明確な階層化のために、ここではnodejsに基づいているため、統合するのも簡単です. Rest Apiは、基礎データサービスを提供し、httpプロトコルを採用し、node/expressから構成されている. socket、長接続サービスを提供し、socketを採用する.ioは、データ層を直接接続してもよいし、httpプロトコルでデータ層を接続してもよい. 表現層、Reactは基礎ページ構築方法として、オリジナル方法と組み合わせて、具体的なアプリケーション、またはアプリケーションの一部を構築する.
データ層
ここでは、MySqlをベースデータストレージフォーマット、redisをキャッシュとして選択します.
ほとんどの場合、従来のリレーショナル・データ構造が必要です.MySqlは最適な選択であり、PostgreSQL、MariaDBも選択です.
NoSqlの1つとしてmongodyは、非常に人気がありますが、リソースの占有量が高すぎるため、小型プロジェクトには向いていません.
Node
なぜnodeをベース言語としてフレームワーク全体を構築するのでしょうか.まず、他のいくつかの言語を比較してみましょう.
JAVA/Spring
現在最も人気のあるspringアーキテクチャは、ほとんどの大手企業の最初のフレームワークです.長所は説明するまでもありませんが、私たちが迅速に開発しなければならないフレームワークとして友好的ではなく、多くの穴があり、JAVAは強いタイプの言語として、煩雑すぎます.階層明確化(Model,DAO,Service,Controller)と同時に,開発速度も低下した.
もう一つスプリングを放棄させたのは、資源の占有量が高すぎるため、JAVAの運行環境には非常に大きなメモリが必要で、もしあなたの開発機械でMySql、redis、IDE、tomcatなどを運行する必要があるならば、まだ少しプレッシャーがあります.
Python/django
比較的人気のある開発フレームワークであり、成熟したアプリケーションも多く、Ruby On RailのPythonバージョンと言える.しかし、Pythonはサーバー向けに開発された言語ではなく、C言語とのつながりがあるため、今の時代には向いていないと感じ、オープンソースコミュニティのサポートも低下しています.
django自身はORMのシステムを持っていますが、柔軟性が足りません.
私が好きなのはPythonの修飾方法で、非常に柔軟にいくつかの方法のフィルタを配置することができます.△ES 7にも統一された特性が必要だそうです.
PHP
PHPはWEB専用に設計された言語という感じで、think phpのようなmvcのフレームワークはありますが、中間層としてはまだ不安定な感じがします.
Node.js
NodeはIO密集型ビジネスを処理するのに非常に良い選択であり、通常、私たちの中間層は大量の計算を行わず、多くは書き込みデータを読み取るために、他のフレームワークはトランザクションの完了を待つことを選択し、各リクエストはプロセスを生成し、1台のマシンの同時発生数はメモリによって直接決定されます.Nodeはこの点で同じ効果を得るためにより少ないリソースを使用することができる.
Nodeは現在非常に人気があり、オープンソースコミュニティも非常に活発で、多くのアプリケーションやフレームワークがnodeの上で開発されており、オープンソースモジュールが非常に完備しており、npmも非常に使いやすい.例えば私が上層部で採用したReactです.
同時にJavascriptはフロントエンド言語として、簡単で学びやすく、多くのフロントエンド開発者が入ることができます.
ES 6が発表された後、Javascriptはスクリプト言語というあまりよくない特性から脱し、専門的なオブジェクト向け言語に似ていると感じた.しかし、残念なことに、これまでv 8はすべてのES 6特性を基本的にサポートしてきたが、最新のnode v 6は完全にサポートされておらず、
v 8に感謝するしかない!
また,このフレームワークの大部分はjsで構成されていることが分かるので,中間層の開発としてノードを選択することも当然である.
次のステップ
中間層全体の構築.次の記事をご覧ください.
後記
Nodeサービスの効率については、公式説明や多くの水道水の吹き付けがあり、非常に優れていると感じますが、実際のプロジェクトでは実際の状況に応じて判断する必要があります.
しかし、効率の問題に遭遇した場合、Nodeは他の言語と簡単に混同することができ、最も時間がかかる場所を見つけることができ、C/C++で書き換えるのも非常に速い.
安定性はNodeの比較的弱い側面である.1つのスレッドは、小さなエラーによってサービス全体がクラッシュしやすいため、より詳細なエラー処理に加えて、サービス品質を確保するためにバランスとホットスペアが必要です.
Nodeの非同期構文はより多くのネスト関係をもたらし,使用が氾濫するとコードが理解しにくくなるため,プロジェクト全体の仕様と習慣を統一する必要がある.(例えばcallback関数の代わりにPromiseを使用する)
データ・サービス・フレームワーク>>Github
こうぞう
|----------------------------------------|
| web/HTML5 | mobile | ect. |
-----------------------------------------|
| React/Flux/React Native | ^ |
-----------------------------------------|
| rest api/node/express | socket.io |
| -----------------------------|
| | database/redis/storage |
|----------------------------------------|
より明確な階層化のために、ここではnodejsに基づいているため、統合するのも簡単です.
データ層
ここでは、MySqlをベースデータストレージフォーマット、redisをキャッシュとして選択します.
ほとんどの場合、従来のリレーショナル・データ構造が必要です.MySqlは最適な選択であり、PostgreSQL、MariaDBも選択です.
NoSqlの1つとしてmongodyは、非常に人気がありますが、リソースの占有量が高すぎるため、小型プロジェクトには向いていません.
Node
なぜnodeをベース言語としてフレームワーク全体を構築するのでしょうか.まず、他のいくつかの言語を比較してみましょう.
JAVA/Spring
現在最も人気のあるspringアーキテクチャは、ほとんどの大手企業の最初のフレームワークです.長所は説明するまでもありませんが、私たちが迅速に開発しなければならないフレームワークとして友好的ではなく、多くの穴があり、JAVAは強いタイプの言語として、煩雑すぎます.階層明確化(Model,DAO,Service,Controller)と同時に,開発速度も低下した.
もう一つスプリングを放棄させたのは、資源の占有量が高すぎるため、JAVAの運行環境には非常に大きなメモリが必要で、もしあなたの開発機械でMySql、redis、IDE、tomcatなどを運行する必要があるならば、まだ少しプレッシャーがあります.
Python/django
比較的人気のある開発フレームワークであり、成熟したアプリケーションも多く、Ruby On RailのPythonバージョンと言える.しかし、Pythonはサーバー向けに開発された言語ではなく、C言語とのつながりがあるため、今の時代には向いていないと感じ、オープンソースコミュニティのサポートも低下しています.
django自身はORMのシステムを持っていますが、柔軟性が足りません.
私が好きなのはPythonの修飾方法で、非常に柔軟にいくつかの方法のフィルタを配置することができます.△ES 7にも統一された特性が必要だそうです.
PHP
PHPはWEB専用に設計された言語という感じで、think phpのようなmvcのフレームワークはありますが、中間層としてはまだ不安定な感じがします.
Node.js
NodeはIO密集型ビジネスを処理するのに非常に良い選択であり、通常、私たちの中間層は大量の計算を行わず、多くは書き込みデータを読み取るために、他のフレームワークはトランザクションの完了を待つことを選択し、各リクエストはプロセスを生成し、1台のマシンの同時発生数はメモリによって直接決定されます.Nodeはこの点で同じ効果を得るためにより少ないリソースを使用することができる.
Nodeは現在非常に人気があり、オープンソースコミュニティも非常に活発で、多くのアプリケーションやフレームワークがnodeの上で開発されており、オープンソースモジュールが非常に完備しており、npmも非常に使いやすい.例えば私が上層部で採用したReactです.
同時にJavascriptはフロントエンド言語として、簡単で学びやすく、多くのフロントエンド開発者が入ることができます.
ES 6が発表された後、Javascriptはスクリプト言語というあまりよくない特性から脱し、専門的なオブジェクト向け言語に似ていると感じた.しかし、残念なことに、これまでv 8はすべてのES 6特性を基本的にサポートしてきたが、最新のnode v 6は完全にサポートされておらず、
--harmonyを加えてもほんの一部しかサポートされておらず、サードパーティのライブラリを借りる必要がある.v 8に感謝するしかない!
また,このフレームワークの大部分はjsで構成されていることが分かるので,中間層の開発としてノードを選択することも当然である.
次のステップ
中間層全体の構築.次の記事をご覧ください.
後記
Nodeサービスの効率については、公式説明や多くの水道水の吹き付けがあり、非常に優れていると感じますが、実際のプロジェクトでは実際の状況に応じて判断する必要があります.
しかし、効率の問題に遭遇した場合、Nodeは他の言語と簡単に混同することができ、最も時間がかかる場所を見つけることができ、C/C++で書き換えるのも非常に速い.
安定性はNodeの比較的弱い側面である.1つのスレッドは、小さなエラーによってサービス全体がクラッシュしやすいため、より詳細なエラー処理に加えて、サービス品質を確保するためにバランスとホットスペアが必要です.
Nodeの非同期構文はより多くのネスト関係をもたらし,使用が氾濫するとコードが理解しにくくなるため,プロジェクト全体の仕様と習慣を統一する必要がある.(例えばcallback関数の代わりにPromiseを使用する)