日前と終了後にフロントでのモードと独立したアプリケーションの後端部の両方を共有するために、そして彼が上陸した地点に実際のシーンだけでなく、注意を払うに適用する方法を、総合的な検討を行いました。
現状
前と後に分離開発の終了は、業界標準となっています。
彼は、分離の効果を達成するために、アプリケーションサーバ（Tomact ...）フロントと効果的にウェブサーバ（nginxの|| Nodejs ...）+フロントとリアの端部によって切り離さ2つのサービスの後端部です。
技術的な核となるアイデア：JS RESTfulなAPIを介してバックエンドサービスを呼び出すために、フロントエンドのHTTPリクエストを作成するには、JSONデータ・インタフェースとの相互作用を返します。
Webサーバ：一般Nginxは、サーバーのノードの一種として、彼らは一般的に静的リソースと分析プロセスの制御だけでなく、いくつかの簡単なビジネス・ロジックのためにのみ適していますを意味し;
アプリケーションサーバー：一般的にTomcatのように指し、突堤サーバが動的なリソースのこの種は、静的リソースを解決することができます解決できますが、静的リソースの良いWebサーバを解決する能力。
彼の存在の主な目的は、より洗練され、よりプロフェッショナルを達成するために開発作業を投影することです。
前と分離モードの終了後も、この位置急速な上昇の理由の一つのフロントエンドを可能にします。
系統
前のプログラマは、フロントとリアエンドを分割しない、すべての項目は、基本的にDangdieプログラマと母として、そしてすべて込みの両方で、バックエンドの作業を1ページアバディーンの最大値を割り当てます。多くの企業の間、市場は主に、クライアントの経験、ゆっくりと発展するにつれことがわかります。これを行うために誰かを聞いているが、クライアントエクスペリエンスを最適化することで、その後はないプロのこのタイプ（または希少種である）小さなコストを喜ばかもしれません。
このとき、プログラマの会話を見つけるために会社のリーダーシップ、彼らはこの仕事を引き継ぐようにしたいが、それらのほとんどは、このライブの汚れや疲れを軽蔑見つけ、気にしない、それは無力でした。
ただ、リーダーシップ悲しい時間を示さなかった、と私たちは、愛に満ちた顔に顔を立って熱心少し目の満ちているページアバディーンのペアを振り返ります。だから、目を確認した右の人に会いました。このページからツァイ喜びは、カウンター攻撃の彼の方法を始め、プロのフロントエンドエンジニアは、このように誕生します。
分離に努め、エンジニアを区別するために、そのデューティ・フロントエンドとバックエンドのエンジニア、あまりにも多くの相互依存的な干渉を持つことはできません。前端と後端に分離パターンは、この有病率で得られることになります。
開発モデルの前端と後端
ない分離モード
このモードはあまり分析されていません。
このモードでは、2つの欠点があります。
コードの背後にあるコード連結深刻なフロントエンドのHTMLコードが表示されます。フロント楽屋テンプレートエンジン、テンプレートと多様化します。離職コストが高すぎます
プロジェクトの前と後の深刻なプロジェクトを結合。待機状態でフロントにつながることができ、問題がある場合、フロントエンドの開発プロジェクトは完全にバックエンド、バックエンドに依存しています
ハーフスプリットモード
ワークフロー：
1.なようにCSS、JSやなどの基本的なリソースを、読み込み、ウェブを開きます。
図2に示すように、ローディングを実証しながら、Ajaxリクエストと、サーバ要求データを開始します。
3、テンプレートに従ってJSONのDOMフォーマットストリング選択ロジックをレンダリングする前に得られたデータ。
4は、文字列は、DOM構造をレンダリングするDOMのWebビューページに挿入されています。
ユーザーデバイス上のワークフローのすべての進歩的な実装の上に、それはクライアントの速度は、ユーザーのデバイスに完全に依存と言うことです。お使いのデバイスよりローエンド場合は、より低速のページを開きます。
なぜフロントエンド層上に、主コントローラので、半分離されていない、フロントエンドページは、それが同期出力される、または非同期JSONをレンダリング通信する必要がありますか？ページの出力を同期させるために必要がある場合は、唯一のサービス側に置くことができ、それがバックアップ行かなければなりません。それだけで半デタッチと言うことができます。
単離された半利点：
図1は、コードが接続されていない、フロントエンドは、コードが挿入されている任意のバックエンドを持っていないであろう。
2、フロントエンドの開発は、クライアントの開発に集中することができ、バックエンドサービスに依存しません。アナログフロントエンドはまた、配置データによって並行開発することができます。
図3に示すように、正確な位置決めの問題であることができ、問題が前端又は後端の問題です。
孤立半短所：
1、SEOの質問は、検索エンジンは、非同期のデータ・ページにクロールすることはできません
図2に示すように、クライアントの応答速度が制御されず、JSONは遅いレンダリング大量のデータ、データ処理ロジックの複雑さ、に返さ、場合カトンが存在するであろう
レンダリングが完了すると、3、深刻な資源の消費量、ページが複雑なビジネスへの複数の要求を必要とするかもしれません。これは、より顕著な携帯端末に反映されています
完全な分離モード
完全な分離は、実際には、あなたは単純な論理処理サーバーを行うことができ、Webサーバーの層を追加します。
だから、全体の開発モデルの分離は次のとおりです。
フロント：ビューとコントローラ層は、単純なパラメータ制御、データ変換を行うための責任があります。
リア：DBとサービス層は、ビジネス/データ処理を行うための責任があります。
但是前端怎么写Controller呢？难道又要前端学JAVA PHP？那不又是成本加高?这时候nodejs就派上用场了，node.js适合运用在高并发、I/O密集、少量业务逻辑的场景。重要的是前端就不需要新学一名新语言可以快速上手了。
其实全分离模式本质只是在工作职责上做了分工。技术层面是又回到了不分离的原点。
增加中间层的工作职责如下图：
全分离的优点
1、后端服务的适配提升；一个应用要对应输出pc、mobile、app的时候。后端服务就不需要为各端写兼容代码了。统一由前端的web服务器处理即可，维护起来更安全有效率；此时架构应该如下图：
2、减少在客户端处理数据的逻辑代码，提高客户端响应速度；
3、减少客户端资源浪费，需要多HTTP才能拼装好的页面可以在内网一次拼好，再返回给客户端
4、可以借助node服务器渲染，解决seo问题。
全分离/半分离模式的工作流程如下：
按照流程图，我们的工作步骤应该如下：
步骤一、我们从需求评审的时候要求就是所有参与成员必须参加。
步骤二、沟通，协议制定阶段；（这阶段的第1、2小步一定要做好，不然影响第三大步的开发工作）
1、会后前端应该需要先跟UI沟通，设计稿的大概框架，页面效果实现的注意点；
2、前后端制定契约（接口文档），这个应该需要详细到每个字段的描述；
3、测试编写测试用例
第三步、开发阶段
1、前端根据接口文档，模拟API接口进行前端的开发工作（根据跟UI的沟通写大概的布局架构的设计，简单的业务逻辑开发。一定要等UI设计稿完全交互后再进行详细的业务逻辑编写）；
2、后端开发后端服务，并按照文档输出数据即可；或文档有修改一定要通知到下游的前端；
3、测试编写测试代码，如果后端接口开发完毕，前端还未开发联调完。测试可以先开始接口测试；
第四步、联调
第五步、整体测试，第六步、交付上线
从上面看我们的流程在第二，三步都是串联进行的。这样会大大提高我们的开发效率。
但这会有一个小缺点，就是：如果改了之前相关约定的东西，一定要通知到相关人员！！
如果改了之前相关约定的东西，一定要通知到相关人员！！
如果改了之前相关约定的东西，一定要通知到相关人员！！
重要的事情说三遍!!!!!
总结
分离模式的缺点：
沟通成本相对增高，需要团队更紧密和谐的配合，对团队要求相对增高；
职责精细化，需要的人力成本相对增高；
分离模式的优点
1、提高服务端质量；（服务端不再需要兼顾烦杂的前端处理工作。专心做后台框架和业务开发，进行更精准的单元测试）
2、提高客户端访问性能；（腾出空间让前端做各种专业的性能优化）
3、提高项目可维护性；（前端代码规范化，模块化，让前端逻辑清晰明了）
4、提高开发效率；（项目解耦，减少前后端相互等待时间。实行并行开发）
5、减少重复工作；（如果需支持要多端应用，服务端接口基本可以共用）
6、动静态资源解耦，减少应用服务器的并发、负载压力；（所有静态资源可使用CND分发，提高访问效率体验）;
7、提高解决问题效率；（发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰）
落地注意点
1、需求评审；（前后端，测试，UI必须参加，并提供出测试用例）
2、接口文档制定；（开发前，前后端必须一起制定出详细的接口文档，输出数据格式，包括字段名，这点非常重要！不然前端会重复返工！）
3、测试工作；（为提高项目进度效率，测试可以在服务端开发完接口后进行一波有效的接口测试。让开发测试并行，减轻后面整体测试的压力和时间。）
4、选型；(至于选择全分离还是半分离，完全根据当下业务来判断，需要不需要增加一层node服务来提高开发效率，已经性能。)
这次分享差不多久这些，如有其他疑问或者更好的理解欢迎在评论区留言讨论。谢谢！！
这次的分享资料也参考了：https://blog.csdn.net/fuzhongmin05/article/details/81591072
这也是我在大汉集团任职产出的东西。感谢大大工匠云平台