网站前后端分离什么意思

⑴ Web项目开发为何要走前后端分离模式

把前端与后端独立起来去开发，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员，前后端工程师需要约定交互接口，实现同步开发，开发结束后需要进行独立部署，前端通过接口来调用调用后端的API，前端只需要关注页面的样式与动态数据的解析和渲染，而后端专注于具体业务逻辑。具体好处有以下几点：

1.彻底解放前端

前端不再需要向后台提供模板或是后台在前端html中嵌入后台代

2.提高工作效率，分工更加明确

前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。

3.局部性能提升

通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。

4.降低维护成本

通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。

5.实现高内聚低耦合，减少后端（应用）服务器的并发/负载压力。

6.即使后端服务暂时超时或者宕机了，前端页面也会正常访问，但无法提供数据。

7.可以使后台能更好的追求高并发，高可用，高性能；使前端能更好的追求页面表现、速度流畅、兼容性、用户体验等。

我理解的前后端分离，前端是需要起服务器的，减少学习成本，可以用node，前端也要有域名的

如果是半分离， 那么前端提供js文件（css等）这个我也做过，前后端都用node就不说了，如果是两种语言，

如果一个工程文件下开发，webpack下直接打包进后台语言的静态目录下。

如果是两个工程，那么前端只提供生成的js（css）文件，git pull后台项目，扔进静态目录，这样又涉及到版本控制的问题，一般我会生成一个配置文件，直接读取的，内容是xxx.hash.js这种文件名，然后document.wirte动态写入js/css

前端起服务器就不需要动态引入了，直接html插件生成文件，更好的控制版本

半分离 还有一个问题，例如首页同构，如果更改xxx.blade.php文件，这就又动了php文件，甚至包括nginx反向代理啊，ssl这种缓存啊，都比较麻烦，你要是改了点啥，自己的ok了，后台的崩了，那就挺操蛋了，大公司有专门的运维还好，小公司真的是一团糟

后台我们采取全分离，nginx前端管理，至于升级nginx版本，http2，反向代理，https证书，都是前端自己弄，毕竟小公司，每个人水平都不一致，自己负责自己的比较好

但是这个跨域又要稍微处理一下，至今我这边后台还是*，我也没法说什么

阿里云这么便宜，如果把成本浪费在人力上，会变得很贵

一个人的精力有限，前后端分离有助于我们更专注我们所要注重的技术点，俗话说：“术业有专攻”。

比如我们后端，前后端分离有助于我们把注意力放在java基础，设计模式，jvm原理，spring+springmvc原理及源码，linux，mysql事务隔离与锁机制，mongodb，http/tcp，多线程，分布式架构（bbo，bbox，spring cloud），弹性计算架构，微服务架构（springboot+zookeeper+docker+jenkins），java性能优化，以及相关的项目管理等等。

而前端也可以集中精力在前端的展示上。

总的来说，前后端分离利大于弊。这也是越来越少用jsp的原因。

补充两点

1.每次请求的数据量变小，也意味着更少的响应时间。

2.也不是每个应用用前后端分离都是最合适的，要根据应用规模，工期综合判断。

⑵ 现在开发网站一般都使用什么方式什么是前后端分离

前后端分离的由来是：以前开发网站都是 jsp、asp 这类动态脚本。
jsp、asp这种参杂了后端语言、javascript、css、html 的混合脚本，使代码开发和维护都极其不方便。
随着前端交互越来越复杂，jsp、asp 这种脚本语法已经不能满足开发的需求了。
于是前后端的概念就提出了：前端人员负责页面展示和交互，然后通过 ajax 调用后端人员写好的数据接口。
所以开发网站的核心现在基本上就是：

html + css ：页面展示
javascript + ajax（这个算是浏览器的一部分，可以通过 javascript 调用） : 页面交互、逻辑处理
通常的开发框架选择：

简单网站： jquery + bootstrap
后台管理系统： angularjs + jquery + bootstrap + webpack
复杂的产品： react + rex + webpack

⑶ web开发为什么要前后端分离

在学习前端开发的时候，会发现前端开发的知识非常琐碎，前端往往是靠拼凑来完成页面效果，开发过程没有java后端开发有逻辑，代码也很难管理。后端开发有各种各样的工具类、jar包、maven依赖、spring框架等，具有工程化模块化思维，可以满足后期的优化。vue.js和react.js等这些前端框架的出现，它们从本质上打破了以前前端开发的规则，这就是前端开发组件化框架。这些框架出现后，前端开发也开始像后端一样，遵循一套体系来进行约束性的开发，越来越工程化、组件化、迭代化，变得有章可循。前后端分离核心思想是前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互。

⑷ web开发中，什么是前后端分离

优秀的WEB架构，必定会应用一些分层设计的思想，这样可以让系统开发起来更灵活，同时后期维护也比较方便。

• 前端的页面基本都是使用 JavaScript 的富户端页面，主要应用的框架用，jquery、jquery ui、knockout js、Durandal。

• 自己封装的 UI 组件，后端的主要采用到的技术有 OData、MVC、Linq to SQL 以及自己写的一个权限管理组件，数据库采用的是 SQL Server 2005。

⑸ Web 前后端分离的意义大吗

什么是前后端分离？前后端分离说白了就是把前端和后端分成两个工程，由不同的团队负责开发，这样从工程和职责的角度上都有分开，这样，后端偏向于提供单纯的API接口，前端就是调用API接口进行展示和业务调用。
这样不仅将页面渲染和业务逻辑从server剥离开来，将页面渲染放给前端，甚至放给浏览器；将业务逻辑放给后台专心搞业务，降低了他们之间的耦合性，而且从职责上进行了分明，更适合大项目和大团队管理和开发。

⑹ 怎么理解前后端分离

对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。

这个说法是不合适的，打个比方，别人问的是逗如何解决家禽把蛋生在水草边的问题看地，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答逗不让去水边就行了地，这显然不在点子上。

这
两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了
少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。

那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：

- 性能优化（尤其是外部资源的管理与发布，请求合并等等）
- 协作的顺畅性（已形成模板的界面片段的返工等问题）

那么，模板到底应该在什么地方跟数据结合看

这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。

所
以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就
是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。

所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。

至
于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node
做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。

这时候回头看你问题中的这句：

> 前后端分离的意思是，前后端只通过 JSON 来交流，组件化、工程化不需要依赖后端去实现。

我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到服务器端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。

组
件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗看是数据吗看是数据和模板的结合体吗看没法回答。在此，我说一
句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不
带逻辑的界面模板。

最近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问
题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改
变，用这个方案去解决的话，有些牛刀杀鸡的感觉。

关于B类项目的组件化，我之前那个没写完的系列是关于它的，但经过最近一年多的思考，我又觉得需要再重新写一篇东西了。感谢你的问题提醒了我，这就写。

⑺ 什么是前后端分离为什么分离

在不使用vue ,react ,anglar这类的框架的情况下，前后端分离应该如何做？
需求是这样：
前端写html页面（非单页面应用），
index 首页
about 关于我们
newslist 新闻列表
newsdetail 新闻详情
proctlist 产品列表
proctdetail 产品详情
后台只提供json数据
那么
1、前端数据如何渲染？
2、页面跳转是否必须使用路由？（不想使用路由）
3、页面间的数据传递如何做，比如：列表页到详情页的参数传递如何做？

⑻ 什么是前后端，有没有前后端分离，还有如何区分mvc与前后端分离

1>>前后端分离的意思是，前后端只通过 JSON 来交流...

同意其他几位，JSON 只是一种可选的协议，而不是唯一，也未必是前后端通信的最佳方案。

2>>组件化、工程化不需要依赖后端去实现...有哪些好处或弊端？

前端的组件化、工程化，js 等代码越来越胖，有点类似于过去 C/S 时代的 fat client。所以这个问题相当于，计算是主要放在 client 好，还是 server 好？

Fat client 好，还是 thin client 好，取决于所开发应用、产品、系统的类型、规模和特点，其中一些权衡因素主要包括软件复杂度、人机交互模型、网络带宽、server 与 client 的处理能力等等。无所谓好坏，适合就好。

Client-side MVC 确实是一个趋势，Web 架构设计上的一个创新。