在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
最近刚做了一个vue的多页面项目，但是在网上看到很多人说前后端分离不利于seo，原理是为什么呢？难道前端写好静态页面丢给后端进行服务端渲染这样有利于seo优化吗？还有另外我想问一下逻辑操作是放在前端处理还是后端进行处理？比如机票排序，是前端对数据进行排序处理，然后再用js渲染页面，还是后端进行排序处理？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
seo 本质是一个服务器向另一个服务器发起请求，解析请求内容。但一般来说搜索引擎是不回去执行请求到的js的。也就是说，如果一个单页应用，html在服务器端还没有渲染部分数据数据，在浏览器才渲染出数据，而搜索引擎请求到的html是没有渲染数据的。 这样就很不利于内容被搜索引擎搜索到。 所以服务端渲染就是尽量在服务器发送到浏览器前 页面上就是有数据的。
第二个问题，一般的数据逻辑操作是放在后端的。排序这个如果仅仅是几条数据，前后端排序开起来是一样的，如果是有1000条数据，前端要排序就要都请求过来。这样显然是不合理的。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
因为搜索引擎不太喜欢执行 JavaScript，所以后端渲染更好。比如你可以试试，好像 Google 完全搜不到知乎专栏里的文章了。Internet Archive 也无法应用于知乎专栏。
我的个人意见是：以内容为主的网站，核心内容尽量后端渲染，以利于非浏览器使用。以软件为主的网站，比如各种 SAP，则不用在意这些。在意了也没用。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
搜索引擎的基础爬虫的原理就是抓取你的url，然后获取你的html源代码并解析。 而你的页面通常用了vue等js的数据绑定机制来展示页面数据，爬虫获取到的html是你的模型页面而不是最终数据的渲染页面，所以说用js来渲染数据对seo并不友好。
ps:另外js并不是所有的引擎都爬不到，如google早就实现去解析js内容了，而国内的一批“蠢一点”的则还不行。google搜索不到知乎，是因为有网站的robots.txt可以配置，知乎默认是不对搜索引擎开放的。守规则的引擎还是会遵循你的配置不去抓取，而一些流氓软件则不见得了。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
知乎默认是不让搜索引擎爬去内容的，在robot.txt中有配置。谷歌对于robot.txt有很好的遵守，国内的一些嘛~
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。前端性能优化—前端工程师不得不说的痛
互联网 & 发布时间： 15:21:00 & 作者：佚名 &
上篇文章的留言里有好多朋友是对我css架构就http请求的问题提出质疑,我本想回答的，但不知道从何说起.希望这里面的东西有你想要的答案吧,感兴趣的朋友可以了解下吧
前言 在上一篇文章《》中，承蒙园内的朋友们抬爱，竟然一路被推荐，让我这小小一枚前端攻城狮既意外又兴奋进而惶恐。惶恐的是资历实在有限，知识实在匮乏，相当害怕误人子弟。此真心话！但接下来我依然会坚持有时间就写写文章，既能总结，又能学到新知识，还能分享给诸位，我认为，分享---是件功德无量的事，互联网不就是因此而绚丽多彩嘛！ 上篇文章的留言里有好多朋友是对我css架构就http请求的问题提出质疑，我本想回答的，但不知道从何说起。前端性能方面的知识我了解得并不深入，囫囵吞枣地看过一两本重构的书、喜欢查查资料，看看一些大牛写的文章，觉得人家那么做有道理了，就搬过来用，林林总总的做些总结，于是有了此文。都不是什么新东西，但是因为小知识点太多，希望这里面的东西有你想要的答案吧。 前端性能优化--前端工程师不得不说的痛 1.html、css、js三者相分离。分离得彻底点！为什么这三者要分离，相信大家都明白，不多说。 2.css的导入方式。css用link而不用@import，因为在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部，延长css的载入时间，还可能出现文件下载次序被更改的情况。 3.理性对待jquery。jquery让我们&write less,do more&，它有太多优势：强大的选择器、DOM操作的完美封装、完善的Ajax、良好的兼容性处理。但是，我们是否就此离不开它呢？我觉得应该根据需求，根据业务逻辑来。一个页面如果只需要几行或几十行js代码可以搞定的效果，为什么要用jquery？让页面先加载个jquery.js，再书写自己的代码？没必要吧。 4.合理布局页面的内容。DOM的加载顺序是由上而下的，遇到css，加载css，遇到js，停滞下来，加载并解析js。在布局页面的时候，把主体内容优先显示，把重要内容靠上布局，让浏览器优先解析，是种较好的方案。　 5.js的导入方式。《javascript王者归来》里有对js的导入方式进行优劣对比。我个人认为，在不考虑js代码重用及维护的前提下(但是往往这点成为我最重要的衡量指标)，把具有重要业务模块的js代码置于title里，把次要的具有操作效果的js代码置于DOM相对应的对象之后。而这样做的理论依据即DOM的加载顺序。上面那话不好理解，举例来说： &上图是QQ音乐首页的导航，主导航的重要作用不言而喻，如下是两段相应的代码： 代码如下: &!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"& &html xmlns="http://www.w3.org/1999/xhtml"& &head& &meta http-equiv="Content-Type" content="text/ charset=utf-8" /& &title&test--js导入方式1&/title& &script type="text/javascript"& &/script& &/head& &body& &ul& &li&&a href=""&首页&/a&&/li& &li&&a href=""&乐库&/a&&/li& &li& &a href="" id="mv"&MV&/a& &div class=""& &a href=""&MV推荐&/a& &a href=""&MV库&/a& &a href=""&音乐现场&/a& &a href=""&MV专题&/a& &/div& &/li& &li&&a href=""&我的音乐&/a&&/li& &li&&a href=""&下载客户端&/a&&/li& &/ul& &/body& &/html& 代码如下: &!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"& &html xmlns="http://www.w3.org/1999/xhtml"& &head& &meta http-equiv="Content-Type" content="text/ charset=utf-8" /& &title&test--js导入方式1&/title& &/head& &body& &ul& &li&&a href=""&首页&/a&&/li& &li&&a href=""&乐库&/a&&/li& &li& &a href="" id="mv"&MV&/a& &div class=""& &a href=""&MV推荐&/a& &a href=""&MV库&/a& &a href=""&音乐现场&/a& &a href=""&MV专题&/a& &/div& &/li& &li&&a href=""&我的音乐&/a&&/li& &li&&a href=""&下载客户端&/a&&/li& &/ul& &script type="text/javascript"& &/script& &/body& &/html& 两段代码的js效果为鼠标移到MV菜单项时显示子菜单选项。第一段代码中，当浏览器解析到&script&标签时，会停滞下来，直到都解析完了，再继续往下，当MV显示时，我们鼠标一移上去，子菜单就会显示出来；而第二段代码中，浏览器解析到MV时，再到&script&，得先加载js，直到完成，子菜单才会显示。显然，对于这种重要功能模块，更适合采用第一段代码。关于这个原理，我理解的方向不知道有没有偏差或者错误，园中朋友有深入研究的请纠错。 6.图片文件格式的选择。关于这点，淘宝UED的图片格式与设计那点事儿有很深入地探讨，我个人觉得受益匪浅，但是文章太长，写得太深入，没耐心还真看不下去，所以后来我又自己总结了下，可以参考下三种图像文件格式的选择。当时总结完这篇文章后，工作的时候就严格按照这上面的来执行了。 7.sprites贴图技术。这是一项从一出现就备受争议的技术，第一、我们需要打开ps，把许多小图标有规则地排放在一起；第二、我们需要打开ps，最好再放大5倍，再水平垂直拉下两条参考线，然后对到标尺，记下left/top值，写到css文件里；第三、sprites贴图技术与height、line-height关系紧密，因为它们，第二点中定位的left/top又将变得不准确，这时你应该给图标之间留出一定的间隙，不然当心显示出来的都是一半的图标哦。我实在没精力再去截图写代码来证明我是对的，这个自己可以有。我似乎把这项技术说得一文不值，让Dave Shea情何以堪！贴图技术之所以到现在还在被广泛使用，我想最主要的原因就是它大大减少了请求数并在一定程度上减少了图片的总体积的缘故。跟这两点比起来，我前面所说的那些缺点似乎不值一提了。 8.让页面渐进增强。将分辨率、操作系统、浏览器、项目针对的用户目标群相结合，在页面制作的过程中采用渐进增强的原则。如果项目的用户目标群普遍采用的是、Mac os x、ie7+浏览器，那么在设计页面的时候，宽度要做相应的限制，最好水平不出现滚动条；字体也不再选择宋体，采用其他web安全字体；接下来我们开心了，因为可以不考虑ie6，是不是觉得工作忽然间变得很幸福？渐进增强不单单可以应用到大的方向上，还可以具体到单页面模块中; （图1)&（图2） 图1和图2是截取自一列表中的一个li，图2为鼠标移到li上的效果--显示&取消关注&。 我将在这模块中应用渐进增强原则：第一、需要考虑ie6，那么由于ie6不支持除了a标签以外的其他标签的hover效果，且&取消关注&又是个重要的功能，不要不行，所以只能采用js代码来实现鼠标移入移出效果；第二、如果不考虑ie6，那么假设&取消关注&的标签为span，就可以在css样式表里这么书写：li:hover span{display:}；第三、如果&取消关注&功能换成无关紧要文字显示，如时间显示，那么一样可以采用第二点写法，让其他浏览器显示、ie6不显示影响也不大。 9.少用滤镜、表达式和hack。这在很多重构书上都会被提到，项目中有对滤镜进行过测试，一堵照片墙过去，全用上滤镜，浏览器加载页面速度那个慢啊，亲眼见到了！表达式不晓得。hack打一开始就在规避，几乎没用过，所以不发表意见。 10.借助一些外在的应用来减少css、js文件的请求数。php程序的可以考虑用minify来把每个页面的css和js整合到一起，再在页面中进行调用，这样页面就只请求一次css和js，性能会优化许多。 我暂时能想到的就先写到这里了。关于前端性能的优化应该还有很多，这些都是皮毛而已，慢慢再深入了。好吧，再侃点其他的！ 前端与美工人员 前端工程师上衔美工、下接后端、背靠产品，缺一不可。职责分工要明确，前端要告诉美工能少用图片尽量少用、合理地选择图片的文件格式、网站页面风格尽量同一、给出网站主业务链接色、辅链接色、主文本颜色和其他文字颜色等等。美工都是单一页面做出来的，往往没办法考虑到整个网站最终的效果，这个时候前端就应该起到一个提示的作用，如果这个环节没把该确定的东西确定下来，到时候改版起来会相当痛苦。 前端与后端人员 把命名方式沟通清楚、跟后端人员解释前端css、js、image目录结构定义的想法、了解后端的工作原理。 前端与产品经理 每个职位的人员都不容易，产品经理更是，最终对产品负责的还是产品经理。不知是否是这样的原因，我所遇到的产品经理都格外细致，有的甚至细致到跟原型效果图差2、3px他都能看得出来！产品经理如果过于追求细节，前端会很悲催。怎么处理这样的情况？和产品经理一样站在产品和用户的角度去思考问题，千万不要站在个人的职位上去想问题，不然永远无法说服他。当然，这有点难度... 终于侃完了，做个总结吧，关于程序设计的些许想法：程序跟人生一样，有的时候需要妥协，不能说为了减少请求数，就不注重代码维护，对待使用2M的用户和10M的用户是不能使用同样的处理方式的，网站访问量的多少也应该考虑在内，多个方面综合考虑、权衡，给出一个最优化方案。我想这才是最合理的。
大家感兴趣的内容
12345678910
最近更新的内容前端后端分离,怎么解决SEO优化的问题呢?_百度知道
前端后端分离,怎么解决SEO优化的问题呢?
我有更好的答案
你可以利用现在的前端框架做同构支持（目前热门的前端框架都支持同构）。在初次网址访问时由服务器渲染页面内容，Client端资源做CDN，这样就可以支持SEO优化了。
能有详细的解决方案吗
采纳率：81%
为您推荐：
其他类似问题
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。WEB 前后端分离三个最大的优点在于：1：最大的好处就是前端JS可以做很大部分的数据处理工作，对服务器的压力减小到最小2：后台错误不会直接反映到前台，错误接秒较为友好3：由于后台是很难去探知前台页面的分布情况，而这又是JS的强项，而JS又是无法独立和服务器进行通讯的。所以单单用后台去控制整体页面，又或者只靠JS完成效果，都会难度加大，前后台各尽其职可以最大程度的减少开发难度。
为了解决传统Web开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了“前后端”的定义，引入前端同学都熟悉的NodeJS，试图探索一条全新的前后端分离模式。
随着不同终端(Pad/Mobile/PC)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，我们往往需要针对不同的终端开发定制的版本。为了提升开发效率，前后端分离的需求越来越被重视，后端负责业务/数据接口，前端负责展现/交互逻辑，同一份数据接口，我们可以定制开发多个版本。
这个话题最近被讨论得比较多，阿里有些BU也在进行一些尝试。讨论了很久之后，我们团队决定探索一套基于NodeJS的前后端分离方案，过程中有一些不断变化的认识以及思考，记录在这里，也希望看到的同学参与讨论，帮我们完善。
一、什么是前后端分离？
最开始组内讨论的过程中我发现，每个人对前后端分离的理解不一样，为了保证能在同一个频道讨论，先就什么是”前后端分离”达成一致。
大家一致认同的前后端分离的例子就是SPA(Single-page application)，所有用到的展现数据都是后端通过异步接口(AJAX/JSONP)的方式提供的，前端只管展现。
从某种意义上来说，SPA确实做到了前后端分离，但这种方式存在两个问题：
WEB服务中，SPA类占的比例很少。很多场景下还有同步/同步+异步混合的模式，SPA不能作为一种通用的解决方案。
现阶段的SPA开发模式，接口通常是按照展现逻辑来提供的，有时候为了提高效率，后端会帮我们处理一些展现逻辑，这就意味着后端还是涉足了View层的工作，不是真正的前后端分离。
SPA式的前后端分离，是从物理层做区分（认为只要是客户端的就是前端，服务器端的就是后端），这种分法已经无法满足我们前后端分离的需求，我们认为从职责上划分才能满足目前我们的使用场景：
前端：负责View和Controller层。
后端：只负责Model层，业务处理/数据等。
为什么去做这种职责的划分，后面会继续探讨。
二、为什么要前后端分离？
关于这个问题，玉伯的文章
中解释得非常全面，我们再大概理一下：
2.1 现有开发模式的适用场景
玉伯提到的几种开发模式，各有各的适用场景，没有哪一种完全取代另外一种。
比如后端为主的MVC，做一些同步展现的业务效率很高，但是遇到同步异步结合的页面，与后端开发沟通起来就会比较麻烦。
Ajax为主SPA型开发模式，比较适合开发APP类型的场景，但是只适合做APP，因为SEO等问题不好解决，对于很多类型的系统，这种开发方式也过重。
2.2 前后端职责不清
在业务逻辑复杂的系统里，我们最怕维护前后端混杂在一起的代码，因为没有约束，M-V-C每一层都可能出现别的层的代码，日积月累，完全没有维护性可言。
虽然前后端分离没办法完全解决这种问题，但是可以大大缓解。因为从物理层次上保证了你不可能这么做。
2.3 开发效率问题
淘宝的Web基本上都是基于MVC框架webx，架构决定了前端只能依赖后端。
所以我们的开发模式依然是，前端写好静态demo，后端翻译成VM模版，这种模式的问题就不说了，被吐槽了很久。
直接基于后端环境开发也很痛苦，配置安装使用都很麻烦。为了解决这个问题，我们发明了各种工具，比如
，但是前端还是要写VM，而且依赖后端数据，效率依然不高。
另外，后端也没法摆脱对展现的强关注，从而专心于业务逻辑层的开发。
2.4 对前端发挥的局限
性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作才能碰撞出火花，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。
为了解决以上提到的一些问题，我们进行了很多尝试，开发了各种工具，但始终没有太多起色，主要是因为我们只能在后端给我们划分的那一小块空间去发挥。只有真正做到前后端分离，我们才能彻底解决以上问题。
三、怎么做前后端分离？
怎么做前后端分离，其实第一节中已经有了答案：
前端：负责View和Controller层。
后端：负责Model层，业务处理/数据等。
试想一下，如果前端掌握了Controller，我们可以做url design，我们可以根据场景决定在服务端同步渲染，还是根据view层数据输出json数据，我们还可以根据表现层需求很容易的做Bigpipe,Comet,Socket等等，完全是需求决定使用方式。
3.1 基于NodeJS“全栈”式开发
如果想实现上图的分层，就必然需要一种web服务帮我们实现以前后端做的事情，于是就有了标题提到的“基于NodeJS的全栈式开发”
这张图看起来简单而且很好理解，但没尝试过，会有很多疑问。
SPA模式中，后端已供了所需的数据接口，view前端已经可以控制，为什么要多加NodeJS这一层？
多加一层，性能怎么样？
多加一层，前端的工作量是不是增加了？
多加一层就多一层风险，怎么破？
NodeJS什么都能做，为什么还要JAVA？
这些问题要说清楚不容易，下面说下我的认识过程。
3.2 为什么要增加一层NodeJS？
现阶段我们主要以后端MVC的模式进行开发，这种模式严重阻碍了前端开发效率，也让后端不能专注于业务开发。
解决方案是让前端能控制Controller层，但是如果在现有技术体系下很难做到，因为不可能让所有前端都学java，安装后端的开发环境，写VM。
NodeJS就能很好的解决这个问题，我们无需学习一门新的语言，就能做到以前开发帮我们做的事情，一切都显得那么自然。
3.3 性能问题
分层就涉及每层之间的通讯，肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作，会大大提高开发效率。分层带来的损失，一定能在其他方面的收益弥补回来。
另外，一旦决定分层，我们可以通过优化通讯方式、通讯协议，尽可能把损耗降到最低。
举个例子：
淘宝宝贝详情页静态化之后，还是有不少需要实时获取的信息，比如物流、促销等等，因为这些信息在不同业务系统中，所以需要前端发送5，6个异步请求来回填这些内容。
有了NodeJS之后，前端可以在NodeJS中去代理这5个异步请求，还能很容易的做Bigpipe,这块的优化能让整个渲染效率提升很多。
可能在PC上你觉得发5,6个异步请求也没什么，但是在无线端，在客户手机上建立一个HTTP请求开销很大，有了这个优化，性能一下提升好几倍。
淘宝详情基于NodeJS的优化我们正在进行中，上线之后我会分享一下优化的过程。
3.4 前端的工作量是否增加了？
相对于只切页面/做demo，肯定是增加了一点，但是当前模式下有联调、沟通环节，这个过程非常花时间，也容易出bug，还很难维护。
所以，虽然工作量会增加一点，但是总体开发效率会提升很多。
另外，测试成本可以节省很多。以前开发的接口都是针对表现层的，很难写测试用例。如果做了前后端分离，甚至测试都可以分开，一拨人专门测试接口，一拨人专注测试UI（这部分工作甚至可以用工具代替）。
3.5 增加Node层带来的风险怎么控制？
随着Node大规模使用，系统/运维/安全部门的同学也一定会加入到基础建设中，他们会帮助我们去完善各个环节可能出现的问题，保障系的稳定性。
3.6 Node什么都能做，为什么还要JAVA？
我们的初衷是做前后端分离，如果考虑这个问题就有点违背我们的初衷了。即使用Node替代Java，我们也没办法保证不出现今天遇到的种种问题，比如职责不清。我们的目的是分层开发，专业的人，专注做专业的事。基于JAVA的基础架构已经非常强大而且稳定，而且更适合做现在架构的事情。
四、淘宝基于Node的前后端分离
上图是我理解的淘宝基于Node的前后端分离分层，以及Node的职责范围。简单解释下：
最上端是服务端，就是我们常说的后端。后端对于我们来说，就是一个接口的集合，服务端提供各种各样的接口供我们使用。因为有Node层，也不用局限是什么形式的服务。对于后端开发来说，他们只用关心业务代码的接口实现。
服务端下面是Node应用。
Node应用中有一层Model Proxy与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式，封装一些view层需要的Model。
Node层还能轻松实现原来vmcommon,tms（引用淘宝内容管理系统）等需求。
Node层要使用什么框架由开发者自己决定。不过推荐使用express+xTemplate的组合，xTemplate能做到前后端公用。
怎么用Node大家自己决定，但是令人兴奋的是，我们终于可以使用Node轻松实现我们想要的输出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步，想怎么整就怎么整，完全根据你的场景决定。
浏览器层在我们这个架构中没有变化，也不希望因为引入Node改变你以前在浏览器中开发的认知。
引入Node，只是把本该就前端控制的部分交由前端掌控。
这种模式我们已经有两个项目在开发中，虽然还没上线，但是无论是在开发效率，还是在性能优化方面，我们都已经尝到了甜头。
五、我们还需要要做什么？
把Node的开发流程集成到淘宝现有的SCM流程中。
基础设施建设，比如session,logger等通用模块。
最佳开发实践
线上成功案例
大家对Node前后端分离概念的认识
技术上不会有太多需要去创新和研究的，已经有非常多现成的积累。其实关键是一些流程的打通和通用解决方案的积累，相信随着更多的项目实践，这块慢慢会变成一个稳定的流程。
六、“中途岛”
虽然“基于NodeJS的全栈式开发”模式很让人兴奋，但是把基于Node的全栈开发变成一个稳定，让大家都能接受的东西还有很多路要走，我们正在进行的“中途岛”项目就是为了解决这个问题。虽然我们起步不久，但是离目标已经越来越近！！
相关 [后端 分离] 推荐：
- ITeye资讯频道
前后端分离已经是业界所共识的一种开发/部署模式了. 关于前后端开发的另一个讨论可以参考这里. 即使通过API来解耦前端和后端开发过程，前后端通过RESTFul的接口来通信，前端的静态内容和后端的动态计算分别开发，分别部署，集成仍然是一个绕不开的问题 — 前端/后端的应用都可以独立的运行，但是集成起来却不工作.
- Web前端 - ITeye博客
WEB 前后端分离三个最大的优点在于：1：最大的好处就是前端JS可以做很大部分的数据处理工作，对服务器的压力减小到最小2：后台错误不会直接反映到前台，错误接秒较为友好3：由于后台是很难去探知前台页面的分布情况，而这又是JS的强项，而JS又是无法独立和服务器进行通讯的. 所以单单用后台去控制整体页面，又或者只靠JS完成效果，都会难度加大，前后台各尽其职可以最大程度的减少开发难度.
- 文章 – 伯乐在线
对目前的web来说，前后端分离已经变得越来越流行了，越来越多的企业/网站都开始往这个方向靠拢. 那么，为什么要选择前后端分离呢. 前后端分离对实际开发有什么好处呢?. 在以前传统的网站开发中，前端一般扮演的只是切图的工作，只是简单地将UI设计师提供的原型图实现成静态的HTML页面，而具体的页面交互逻辑，比如与后台的数据交互工作等，可能都是由后台的开发人员来实现的，或者是前端是紧紧的耦合后台.
- TaoBaoUED
前后端分离模式下的安全解决方案. 在前后端分离的开发模式中，从开发的角色和职能上来讲，一个最明显的变化就是：以往传统中，只负责浏览器环境中开发的前端同学，需要涉猎到服务端层面，编写服务端代码. 而摆在面前的一个基础性问题就是. 本文就在前后端分离模式的架构下，针对前端在Web开发中，所遇到的安全问题以及应对措施和注意事项，并提出解决方案.
- TaoBaoUED
近年来各站点基于 Web 的多终端适配进行得如火如荼，行业间也发展出依赖各种技术的解决方案. 有如基于浏览器原生 CSS3 Media Query 的响应式设计、基于云端智能重排的「云适配」方案等. 本文则主要探讨在前后端分离基础下的多终端适配方案. 关于前后端分离的方案，在
《前后端分离的思考与实践（一）》中有非常清晰的解释.
- TaoBaoUED
Nginx + Node.js + Java 的软件栈部署实践. 关于前后端分享的思考，我们已经有五篇文章阐述思路与设计. 收藏夹将 Node.js 引入传统技术栈的具体实践. 淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java，即：. 在这个体系中，Nginx 将请求转发给 Java 应用，后者处理完事务，再将数据用 Velocity 模板渲染成最终的页面.
- ITeye资讯频道
API就是开发者使用的界面. 我的目标不仅是能用，而且好用, 跨平台(PC, Android, IOS, etc…)使用：本文将详细介绍API的设计及异常处理，并将异常信息进行封装友好地反馈给前端. 上篇文章前后端完全分离初探只是讲了些宽泛的概念，接下来的文章将直接上干货，干货的源码会挂在github上.
- TaoBaoUED
随着不同终端(pad/mobile/pc)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，我们往往需要针对不同的终端开发定制的版本. 为了提升开发效率，前后端分离的需求越来越被重视，后端负责业务/数据接口，前端负责展现/交互逻辑，同一份数据接口，我们可以定制开发多个版本.
- 数据库 - ITeye博客
网上看到一个读写分离的帖子，感觉不错. 构建高性能web之路------mysql读写分离实战（转）. 一个完整的mysql读写分离环境包括以下几个部分：. 在本次实战中，应用程序client基于c3p0连接后端的database proxy. database proxy负责管理client实际访问database的路由策略，采用开源框架amoeba.
--> 坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：itarea.。