这样是不是就叫 前后端分离开发了?

以前曾经写过一个后台是用java写的有前后台页面的网站。

被朋友吐槽说我那个网站不是用的前后端分离,很low。说没有用请求api接口,而且用了jsp來改写html,说前后端分离不需要这样套模版的。

问题:
0.现在是不是差不多所有公司都用前后端分离了?没试过这种开发模式咋办…

1.是不是前后端分离与传统的开发其实主要就是以上那些区别?

2.工作中如果后端同事写的接口文档比较难看懂不就坑了前端?

3.看到别人github有前后端分离项目,为啥运行时前后台页面都是同一个端口号如9000,不是应该前端首页localhost:3000/index 后端首页localhost:9000/index这样分开才叫前后端分离吗? 都用9000端口那和我之前写网站访问前后台的方式一样阿…

概念其实在网上了解过,但怕很多地方还是理解错,所以上来求指正

阅读 12.1k
12 个回答

0 NO 前后端分离是趋势,但是也还存在问题(例如SEO,搜索引擎难以识别等),短时间内不可能取代不分离的
1 主要区别是,数据和表现分离,只需要静态的html和动态的接口(例如jsp),数据在浏览器端实现动态加载
2 理想情况是,先出文档(前后端都认可),然后后端、前端都按照文档来,一切以接口规定的为准
3 跟端口没一毛钱关系,重点在于接口!靠 API 来分离前后端,解决前后端大团队、多版本、复杂功能协作的问题

补充:
可以参考淘宝前端的设计,在 java 接口和 html 输出之前用 NodeJS 代理一层,暂时能解决 SEO 的问题
定义好了接口,前端就可以用不用等后端,直接用模拟的数据格式,方便地进行前端测试了

说重点,API 相比前后端混写、模板引擎之类的东西的好处:
方便设计、开发、测试(前端不再需要依赖后端,后端也不需要依赖前端,就可以各干各的,独立测试代码)
方便记录和统计功能使用(后端相同功能的入口位置统一,不同功能的位置也可以合理有序地组织)
方便修改和版本控制等(后端可以提供多版本的 API,不需要修改已有代码,不影响已有 API 的功能)

最重点的是:
你的Team要是分工不明确、人少、功能简单直接、代码修改不多,就完全不需要分离,就酱。

最明显的:
前端代码不用被后端粘贴来粘贴去了,后端的相同代码,也不需要各种位置粘贴来粘贴去了。

隐藏的好处:
到时候出了问题,照着 API 设计文档一对比,就知道是前端用的不对,还是后端写的不对,分分钟找到背锅侠。

Update 2017/10/13:
其实很有一个很大的优势忘了说……
以后网站的功能,要做Windows、Mac、Android、IOS、Linux的客户端,或者需要做成批量处理的脚本,或者需要和别的什么系统对接,什么微信公众号、小程序之类的,等等等等……
有API在就能瞬间解决问题!就这个提供给前端的API!一样的!调用这个接口就行了!

无论怎样的开发模式都各有优缺点,前后端分离大部分都是开发功能性的应用的,例如网站后台系统,公司内部系统,线上的交互系统等不需要seo的应用,如果开发CMS类的,需要利于搜索引擎抓取的内容管理应用,前后端分离显然是不合理的,js动态加载数据对搜索引擎来说就是个灾难,所以需要根据项目实际应用场景决定是否前后端分离;

前后端分离,分为部分分离和完全分离,部分分离为后端渲染,主要依赖于模板引擎把后端数据在前端显示出来。前端渲染为完全分离。主要依赖于后端提供接口,前端去请求这些接口。现在前端好多MV**框架,比如angular,react,vue可以很好的构建完全前后端的项目,数据渲染放在前端。

现在主流都是前后端分离,后端出接口,前端ajax接接口

首先端口肯定不能冲突,使用静态代理服务器(如Apache)代理前端应用(html+js),你得有若干服务提供者(接口应用),还有若干消费者;消费者调用服务提供者,前端js去请求消费者

前端框架的诞生,打包编译工具的兴起。前端工程化也越来越流行了。

前端负责页面逻辑 后台更专注数据 这是大势所趋

新手上路,请多包涵

前后端分离主要是分离 API, 后端专注于 API 及 数据库, 前端专注于展示, 如果有多端展示, 只需要复用一套 API 就好了, 职责清晰效率提高

新手上路,请多包涵

就是前后端利用API交流

搭车问一下前后端分离的情况,

以前用php的时候 可以直接include包含统一的header

现在前端变成了纯html,前端怎么样使用统一的header和footer。

新手上路,请多包涵

跨域跨域跨域

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏