まず、フロントとリアの概念（フロントエンドまたはバックエンドは、区別する方法です）
これは、順番にいくつかの小さな問題に分けることができますか？フロントエンドとは何ですか。
それはフロントで1.JS？2.限りJSが書かれたとして、それはフロントはありますか？長いフロントエンドエンジニアとして3としては、それをすべてのフロントエンドを書きましたか？4.大型フロントエンドはそれを終了し、サーバー上で実行されている場合でも、JSのフロントエンドと書き込みに使用される言語を指し？5.Appフロントエンドはそれを数えますか？6.Html + CSSフロントエンド、それを数えますか？7.アプレットのフロントエンドはそれを数えますか？8.ReactNativeフロントエンドはそれを数えますか？
通常の状況下で、我々は、フロントエンドは、ブラウザのこの側面を参照してくださいと言うので、アイデアは、ほとんどのプログラムは、JSを使用して書かれていただろう、通常の状況下では、達成するためのJSを使用している、ブラウザこの最後、およびアプリケーション、アプレット、のようなH5を備えたフロントエンド、。しかし、NodeJSが表示され、書かれた後端部NodeJSで、人々は、前にフロントを区別するために、フロントエンドとして分類されます後は、それらを与えると呼ばれる、名前を持っている「ビッグフロントエンド。」
しかし、分割点として、この言語は、フロントとリアエンドを区別するために、本当に正当化？
過去には、我々は関係なく、JavaやJS、書き込みにすべての人であるかどうかの、フロントとリアエンドです。
最後に、我々は、フロントとリアエンドを区別するために始めた理由は何ですか？
第一个，是可以并行开发。前后端的进度互不影响，在过去，前后端不分离的情况下，前端的工作量相对较少，一个前端可以对四个后端。可以理解为，前端花了一周时间写好了静态页面，只需要调几个Ajax接口，不需要路由，也不需要渲染，所以他可以把时间继续在下一个项目里。
第二个，是成本问题。在过去，后端的成本还是比前端要高一些。同样的工作，如果能拆给两个人做，一个成本高一点，一个成本低一点，能接受。
第三个，CSS太难了。JS还好，和后端语言在对技能的训练上相差不大，可是CSS是什么鬼？记住那么多的属性，和Hash算法有关系吗？だから、残念ながらそれはフロントとリアエンドになった、HTML形式+ CSS + JSながら、統一されたフロントエンドと呼ばれ、ブラウザ上で実行されました。Javaの、CやPython、PHPこれらは、統一されたバックエンドと呼ばれ、サーバー側で実行することができます。
前端と後端の定義ので、定義するための言語をベースとするべきではありませんが、それはサーバ側にある場合、それはあなたが見たり触れ表す、バックエンドと呼ばれるべき、動作環境に基づいている必要があります。
あなたは、クライアントを実行する場合、あなたが代表を見ることができ、フロントと呼ばれるべきです。
第二に、静的および動的分離
リクエストのアクセスを区別するために、静的および動的なリクエスト。
自体TOMCAT静的効率は高くはないが扱うだけでなく、リソースのオーバーヘッドをもたらす。したがって、静的及び動的分離を使用して、静的nginxの処理、動的処理はPHPまたはTomcatで処理されます。
nginxのURLを要求されたURLは、nginxのプロセスによって、JPG、PNGが含まれている場合、要求されたリソースは、静的であるかどうかを判断するために、クライアントの要求に応じました。
要求URLがまたは.jspファイルなどの.phpである場合、要求は動的で、この時間は、それがプロセスTomcatに転送されます。結論として、nginxのは、URLを介して、要求のタイプを区別するためであり、別のサーバに転送
システムアクセスの異なるアーキテクチャ設計方法を分離するために、静的及び動的分離手段、静的ページと動的ページ。
JPSサーブレット春のMVCの動的リソースと静的リソースは、JS、HTMLのimg cssの同じサーバーにデプロイされません。