2089人阅读
前端开发（17）
项目采用前后端分离开发的模式，这就不可避免的遇到了跨域问题，我前台页面ajax需要请求小伙伴的后台接口，解决办法如下
配置nginx，修改conf，
& & server {
& & & & listen & & & 8888;
& & & & server_name &192.168.2.95;
& & & & #nginx -s reload &
& & & & location /rdms-mgr-web/web/ {&
& & & & & & & proxy_pass http://192.168.2.95:8182;
& & & & location &/rdms-mgr-web/ {
& & & & & & & proxy_pass http://192.168.2.94:8482;
& & & & location /node/ {
& & & & & proxy_pass http://192.168.2.95:8081;
192.168.2.95是我的ip地址，94是后台伙伴的地址，http://192.168.2.95:8888/rdms-mgr-web/web/会访问我的前台，如果不加web，则访问了他的后台接口
其中http://192.168.2.95:8888/node/为请求我的模拟数据，8081是node.js监听端口,8182为tomcat端口，8482为小伙伴的tomcat端口
遇到一个很坑爹的问题，起初我以为可以直接通过192.168.2.95可以访问，不需要加端口,结果是http://192.168.2.95/rdms-mgr-web/web/可以访问自己的html，无法解决跨域，另外http://192.168.2.95/node无法访问node，纠结了很久，最后将listen 80 改为8888，加上端口就能正常访问了！！！！！！
写的匆忙，打卡下班。。。。。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：210920次
积分：3667
积分：3667
排名：第9298名
原创：132篇
转载：77篇
评论：41条
n年后的事情会是什么样子 谁知道呢 做好现在吧 每天能进步一点 你就应该满足了
(3)(6)(29)(10)(1)(1)(2)(6)(1)(1)(4)(7)(1)(8)(10)(5)(10)(9)(12)(13)(1)(1)(31)(6)(6)(3)(5)(13)(3)(1)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'前后端分离实践 — 如何解决跨域问题 - CNode技术社区
这家伙很懒，什么个性签名都没有留下。
随着前端越来越火，越来越多的人推崇前后端分离，后端只提供API，前端只负责消费API。这样我们就能更加专注自己的事情了，比如前端可以使用任何想要的工具（Webpack、Gulp等等），后端也不用因为集成前端的代码而苦逼加班了。这里不讨论前后端分离的必要性，更多可参考
这里主要分享前后端分离后，如何解决跨域问题
作为一个Rails程序员，首先分享一下在Rails里面的解决方案, 大家可以使用一个 中间件，并作以下配置:
#config/application.rb
config.middleware.insert_before 0, &Rack::Cors&, :debug =& true, :logger =& (-& { Rails.logger }) do
origins ['http://localhost:3000']
resource '*',
:headers =& :any,
:methods =& [:get, :post, :delete, :put, :options, :head],
:max_age =& 0
更多配置请参考
当然，如果后端是NodeJs，我们也可以找到同样的中间件
请看以下配置
var express = require('express')
, cors = require('cors')
, app = express();
// 同样的，只支持开发环境跨域
if(process.env.NODE_ENV == 'development'){
app.use(cors());
这时候，后端程序员可能会说，为了保持跟生产环境配置一直，请直接用 Nginx 来配置吧，这样能减少差异。啪啦啪啦…
直接看配置吧
# 配置可访问域名，注意需要添加相应host配置
server_name xxx.
#charset koi8-r;
error_page
500 502 503 504
/50x.
location = /50x.html {
location /istore/v1 {
proxy_set_header Host $
proxy_set_header X-Forwarded-For $remote_
proxy_set_header X-Real-IP $remote_
# API Server
proxy_pass http://localhost:4000;
proxy_next_
location / {
proxy_set_header Host $
proxy_set_header X-Forwarded-For $remote_
proxy_set_header X-Real-IP $remote_
# Frontend Server
proxy_pass http://localhost:3000;
proxy_next_
proxy_http_version 1.1;
proxy_set_header Upgrade $http_
proxy_set_header Connection &upgrade&;
http-proxy-middleware
这时候前端也不服了，说，我们自己能搞定
PS： 其实这里用了Nginx配置之后，webpack的hot reload会存在比较大的延迟，具体原因还没研究
# 安装插件
cnpm install --save-dev http-proxy-middleware
# 添加配置
import proxy from 'http-proxy-middleware';
const apiProxy = proxy('/api/v1', {
target: 'http://localhost:4000',
changeOrigin: true,
browserSync({
baseDir: 'src',
middleware: [
你也可以通过添加chrome插件来支持跨域
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的全栈开发：前后端分离配置篇（vue+webpack+mock+nginx+spring） - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"contributes":[],"title":"全栈开发：前后端分离配置篇（vue+webpack+mock+nginx+spring）","author":"wang-wei-long-78-29","content":"
目前的技术方案：后端java，前端react+velocity（最近在用thymeleaf做后台），流程是前端开发页面交给后端然后后端统一打成war包上传至服务器，缺点显而易见，即做到了前后端开发分离，服务器部署没有分离。
今天要讲的是如何使前后端完全分离，答案是在服务器端利用nginx做转发，前端文件单独部署到服务器某目录下，nginx负责提供入口和接口监听，也就是前后端分离成两个项目部署到服务器上，好处是前端人员可以自行运维前端项目，后端人员只需要提供api接口即可，互不干扰。其实这种方案老早之前就已经被使用过了，由于入行时间不长，我在这里只是记录下自己研究的一些心得，欢迎批评指正。
下面说一下具体玩法，前端使用vue-cli搭建项目，webpack打包，在后端接口未完成情况下用mock模拟假数据，使用nginx转发接口，后端使用spring框架。本地开发：三种情况：1、后端接口未完成，前端使用mock模拟数据（mock玩法请baidu）2、后端接口可用，使用webpack-dev-server来启动项目配置config/index.js 的 proxyTable参数实现转发，例：访问http://localhost:8080/api/login，请求会发送到http://localhost:9090/api/admin/logindev: {\n
env: require('./dev.env'),\n
port: 8081,\n
autoOpenBrowser: true,\n
assetsSubDirectory: 'static',\n
assetsPublicPath: '/',\n
proxyTable: {\n
'/api': {\n
target: 'http://localhost:9090/api/admin/',\n
changeOrigin: true,\n
pathRewrite: {\n
'^/api': ''\n
// CSS Sourcemaps off by default because relative paths are \"buggy\"\n
// with this option, according to the CSS-Loader README\n
// (/webpack/css-loader#sourcemaps)\n
// In our experience, they generally work as expected,\n
// just be aware of this issue when enabling this option.\n
cssSourceMap: false\n}\n3、后端接口可用，不使用webpack-dev-server来启动项目配置conf/nginx.conf文件。listen：前端项目端口号，server_name：前端项目服务器名，location.root：npm run build到的dist文件夹，location.index：入口文件，location 路径名，proxy_pass：转发到的地址，例：本地访问http://localhost:8080/api/login，会转发到http://localhost:9090/api/admin/login（此处可设置成线上路径，即可以使用线上数据进行开发）server {\n
#charset koi8-r;\n
#access_log
logs/host.access.\n
location / {\n
F:\\.../vue-admin/\n
}\n\tlocation ^~/api/ {\n\t
proxy_pass
http://localhost:9090/api/admin/;\n\t}\n
#error_page
# redirect server error pages to the static page /50x.html\n
error_page
500 502 503 504
location = /50x.html {\n
# proxy the PHP scripts to Apache listening on 127.0.0.1:80\n
#location ~ \\.php$ {\n
proxy_pass
http://127.0.0.1;\n
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000\n
#location ~ \\.php$ {\n
fastcgi_pass
127.0.0.1:9000;\n
fastcgi_index
fastcgi_param
SCRIPT_FILENAME
/scripts$fastcgi_script_\n
fastcgi_\n
# deny access to .htaccess files, if Apache's document root\n
# concurs with nginx's one\n
#location ~ /\\.ht {\n
#}\n}\n结语：通过一些简单的配置，可以使前后端分离开发，分别部署（服务器按上面配置好nginx.conf，npm run biuld出的dist文件传至服务器即可达到前后端单独部署）。前端人员在开发时，如果后端接口没有完成，可以先使用mock模拟接口数据，如果后端已经提供正确接口数据，使用vue-cli内置的代理或者本地架nginx服务器实现接口的转发，这样前后端只要在开发前商议好接口，就可以分别开发部署，极大提高开发效率，如果你是一名全栈开发人员，你更需要这种方式。","updated":"T11:44:43.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"collapsedCount":0,"likeCount":3,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-b0a0b3e9de9960cdc8c28_r.jpg","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"Nginx"},{"url":"/topic/","id":"","name":"webpack"},{"url":"/topic/","id":"","name":"Vue.js"}],"adminClosedComment":false,"titleImageSize":{"width":535,"height":300},"href":"/api/posts/","excerptTitle":"","tipjarState":"closed","annotationAction":[],"sourceUrl":"","pageCommentsCount":0,"hasPublishingDraft":false,"snapshotUrl":"","publishedTime":"T19:44:43+08:00","url":"/p/","lastestLikers":[{"bio":null,"isFollowing":false,"hash":"a79b0ed7a79ebd5f04c07ae2","uid":359300,"isOrg":false,"slug":"chen-ying-heng-34","isFollowed":false,"description":"","name":"cyheng","profileUrl":"/people/chen-ying-heng-34","avatar":{"id":"v2-653b7ee4dc3e7d7e3be1","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"","isFollowing":false,"hash":"f16d1f2a0b73ae6de9997d","uid":52,"isOrg":false,"slug":"sun-yuan-tong-48","isFollowed":false,"description":"你想要的，将来都会得到","name":"孙远通","profileUrl":"/people/sun-yuan-tong-48","avatar":{"id":"ab83e996b4e","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"前端工程师","isFollowing":false,"hash":"12a3733fccf626b6db969b","uid":774400,"isOrg":false,"slug":"fei-fei-9-31-69","isFollowed":false,"description":"","name":"菲菲","profileUrl":"/people/fei-fei-9-31-69","avatar":{"id":"v2-fabea22f4","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"summary":"目前的技术方案：后端java，前端react+velocity（最近在用thymeleaf做后台），流程是前端开发页面交给后端然后后端统一打成war包上传至服务器，缺点显而易见，即做到了前后端开发分离，服务器部署没有分离。 今天要讲的是如何使前后端完全分离，答案是在服…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"annotationDetail":null,"commentsCount":0,"likesCount":3,"FULLINFO":true}},"User":{"wang-wei-long-78-29":{"isFollowed":false,"name":"王炜龙","headline":"","avatarUrl":"/v2-59e51a57db0a6afd5e40_s.jpg","isFollowing":false,"type":"people","slug":"wang-wei-long-78-29","bio":"互联网 前端 程序员 产品 项目经理","hash":"4c399fff7db","uid":465200,"isOrg":false,"description":"","profileUrl":"/people/wang-wei-long-78-29","avatar":{"id":"v2-59e51a57db0a6afd5e40","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"next":{}},"columnPosts":{},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"edition":{},"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{},"message":{"newCount":0},"pushNotification":{"newCount":0}}Nginx前后端分离将多个请求转发到多个Tomcat，负载均衡控制反转
Nginx前后端分离将多个请求转发到多个Tomcat，负载均衡控制反转
科技狂想曲
一、谈谈“渲染”相信好多人都挺听过“渲染”这个词，但不清楚它是什么意思？前端开发以为这是后端的活儿，后端开发以为是前端的事儿，推着推着就不了了之。其实渲染很简单，不说概念，直接举例：1、 后端渲染：以JSP为例，可以分成三步a、编写标签或Java代码（可以称之为模板）b、在JSP编译阶段被转换成Servlet编译为Servlet Classc、执行编译后的代码，将响应（模板执行结果）返回给页面优势：减少前端工作，前端只需要设计纯页面，其他的都由后端来做；缺点：依赖于服务器端，增大服务器压力，前后端职责分工不明确；应用场景：在页面不太多、渲染压力不大、服务器端能够承受范围内可以使用后端渲染。2、 前端渲染：以基于js的模板引擎为例a、编写模板代码b、通过模板引擎将模板转化为脚本语言，拼接在JS中（第一次拼接，以后使用缓存）c、页面加载执行JS优势：减少服务器压力，前后端职责可以很好地分开，后端只做Json数据接口，前端进行渲染；缺点：前端渲染依赖于客户端，增大的前端压力，需要代理服务器、末班渲染引擎的支持；应用场景：在前端页面较多，前端开发人员能力较强，需要前后端分离的场景可以使用前端渲染（前端渲染是趋势）。二、谈谈nginx1、谈谈为什么会用到nginx？首先明确一件事，浏览器可以发出请求吗？可以！那我们为什么要用到服务器呢？因为我们的前端如果不依赖服务器，页面就只能访问本地资源而不能访问服务器上的资源，而我们的后台一定是写在服务器上的。所以举个例子，我们在使用Tomcat服务器时，就必须把前端资源架在Tomcat上，才能访问后台的servlet。如下图所示：所以当我们希望前后端分离时，前端的资源就不能放在Tomcat上面，那如何获得Tomcat的资源的？这就用到了nginx，如下图所示：2、谈谈nginx的反向代理有反向代理必有正向代理，先谈谈正向代理：一般默认的代理都是正向代理，用户访问不了一个资源，然后通过代理服务器去访问这个资源，将响应带回给用户。关键在于用户知道自己访问的是其他服务器的资源，代理服务器不会掩饰URL。而反向代理是，代理服务器也是在中间层，但是用户不知道自己访问的资源是其他服务器的资源，代理服务器会掩饰URL。3、谈谈如何使用nginx反向代理tomcat（1）首先打开nginx，两种方式，一种是直接点击ngnix.exe，一种是使用命令行，cd到nginx目录下，start nginx，无报错即启动成功（2）启动成功后，如何验证，因为ngnix.conf核心配置文件默认配置监听80端口，所以浏览器打开localhost，看到如下显示：（3）下一步就是配置反向代理Tomcat，打开conf目录下的nginx.conf文件，主要看35行左右开始的代码，下面是我修改过的代码：主要修改lacation属性，使所有的请求都被转发到http://localhost:8080的Tomcat服务器下处理：listen：是监听的端口，即用户访问nginx服务的端口server_name：服务名，经过测试并不会影响到什么location：定义资源类型与服务器中资源地址url的映射关系，可在/后面定义资源类型，可设置多个location其中proxy_pass代表要反向代理的服务器资源url，只要资源类型匹配，在这个url下的子路径资源都可以访问到，其中root代表本地的资源路径，同样只要资源类型匹配，这个路径下的子目录资源都可以被访问到，一个location中只能配置一个root或proxy_pass。（4）修改后ngnix.conf文件后，使用nginx -s reload指令，重启ngnix，如果没有报错即重启成功（5）发出请求，获得Json，url显示依然是80端口的资源，即我们说的反向代理的特点，掩饰url，效果如下图所示：事实上，nginx是将请求转发到Tomcat服务器，是8080端口下的资源，如下图所示：（6）如果不光有Tomcat服务器的资源，那么就需要定义多个location，比如，jsp资源请求就转发到Tomcat服务器下，PHP、html、js、css等资源资源可以转到Apache服务器目录下，如下图配置示例：[html] view plain copylocation ~ \.jsp$ {proxy_pass http://localhost:8080;} location ~ \.(html|js|css|png|gif)$ {root D:/software/developerTools/server/apache-tomcat-7.0.8/webapps/ROOT;}Ngnix的功能远不止于此，它的高效也同样被称道，有兴趣可以更深入了解！有兴趣的朋友一起学习java 可以加群---《专注JavaWeb开发》 群号：
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
科技狂想曲
百家号 最近更新：
简介: 任何一个人都是独一无二的
作者最新文章为什么我不喜欢「前后端分离」（个人观点，欢迎来喷） - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
- a JavaScript code quality tool
为什么我不喜欢「前后端分离」（个人观点，欢迎来喷）
07:17:39 +08:00 · 38989 次点击
我不知道国外有没有「前后端分离」的运动，我只知道国内的大公司喜欢搞这个。
前后端分离大概的意思就是后端只给前端提供数据，前端负责 HTML 渲染（可以在服务器渲染，也可以在浏览器渲染）和用户交互。
说这个说得最多的就是阿里的前端了。同时阿里的前端也是在中国最活跃的。
为什么做前后端分离？
本篇文章我来腹黑地揣测一下原因。以下言论不针对某个个人，而是对前端群体的群嘲。我坦然接受你的反嘲讽。
最开始的前后端：
某些团队做前后端分离，主要的原因是
如果不分离，前端对网站的控制力太弱，没有话语权。
前端想要扩大势力范围。扩大了势力范围才有晋升的机会。
在前后端分离之前，前端就是页面仔。技术大牛都是后端，鲜有前端能晋升到架构师层级。这不是对前端的歧视，而是前端真的只是做做页面、加个动效而已，凭什么晋升到架构师。
当时前端能控制的，就是 CSS 和 JS 文件。连 HTML 都是放在后端的仓库的。因为 HTML 是由服务器输出的，用到的模板语言就是后端的。
Node.js 火了之后，前端看到一个机会， HTML 是可以用 Node.js 来输出的呀，于是鼓吹前后端分离，把 HTML 层面交给前端来控制。这样前端就能管控更多的东西了（好可怜，终于能掌握 HTML 的控制权了）
HTML 如果放在浏览器渲染，就是下图
HTML 如果用 Node.js 渲染，就是这样
看起来只是掌握了 HTML 的控制权，但是这里面可以做的文章可多了。
以前 HTML 是 Java 、 PHP 输出的，或多或少存在效率不高的地方，现在用 Node.js 重写，效率是不是就提升了（很少有程序重写了，效率还下降的）。效率提升了是不是该奖励下前端，给几个晋升名额呢？
前端得到好处了，就更要巩固自己的地位了。以前的 jQuery 代码，后端看看就懂。「那不行，我要搞点后端看不懂的」，这样才能显示我前端的技术含量，这样才能升值加薪啊。于是 React 、 Gulp 什么全加上。
好了，我编不下去了。
总之我不认同这种前后端分离。
又增加了一个中间层（当然程序员通过增加中间层来解决问题），好处是有，职责明确；但是也有坏处：人为地拉长了战线。对比图一和图三你就会发现，结构变复杂了，一个人能做的事情变成需要两个人做了
并没有实质变化。以前的后端结构也是存在调用 Service 逻辑的，现在只不过换成让前端用 Node.js 做。除了把本来就吃紧的前端人力耗费在他不擅长的领域，我没看到什么提升。这里唯一的好处就是前端是势力范围扩大了。
我认同的是「全栈工程师」。
一个业务的前后为什么要分给两个人写？以表单提交为例，后端要对数据做校验，前端也要做。为什么要让两个人都写一次？前端说可以让后端也写 Node.js ，这样就可以服用代码了呀。
搞笑吗？后端写了三年的 Java 你现在告诉他要全部重来？后端肯定不愿意啊。
矛盾就出在，分『后端』和『前端』两个职位上。
大公司细分后端和前端，也是可以理解的。这里不表。
我只是说前端端分离的缺点：
大部分站点，不应该分前后端。除非你的前端，非常非常非常复杂。但是大部分站点的前端，根本没有那么复杂！
分了前后端很容易出现各自为政的情况。推诿、邀功、互相鄙视，不一一列举了。
有人问一个人怎么又学后端又学前端？我的建议是把前端做薄，如果没有必要，不要搞什么 Angular 、 React 。用原生 JS 或者 jQuery 能满足大部分网站。同时后端向 Rails 学习。局部交互复杂的地方，采用动态加载来做交互。
有人说你是前端的叛徒，你这么做前端还有什么前途。
搞笑，你做了前端就要一辈子为前端说话吗？太屁股决定脑袋了吧。
标题有点标题党，其实真正主题是：前后端分离是前端不得志的必然结局。（好像更标题党了 XD ）
难道前后端分离没有好处吗？
我觉得只有一个好处：好招聘。毕竟你要招一个优秀的全栈工程师是极其困难的。
有人说，你真有意思，说这么多缺点，你还不是给不出解决方案，说了跟没说一样。
说下我的思路
保持前端简单，复杂了就用原生的方式封装，具体来说就是用自定义标签来封装复杂组件。这样一来，后端同事还是可以开发页面，因为只是多了一个自定义标签而已，本质还是 HTML
尽量不要在开发状态加 watcher ，目的也是让后端可以直接上手，不需要了解那么多工具。转译放到 Web 框架的开发者模式里面做，看到 less 请求加转义成 CSS 不是什么难事也不复杂。
前端只是辅助（这里说的是大多是网站，不包括重型 Web 应用），前端要做好服务化：健全的文档、友好的接口。
前端也要学后端知识，别在那自嗨。
小公司别搞前后端分离，徒增复杂度！！！
第 1 条附言 &·&
07:53:45 +08:00
有些人老是喜欢揣测我的能力是不是不行才这么说。
工作经历：
毕业前在腾讯某前端部分实习近一年
在腾讯、阿里纯前端部门工作三年（jQuery、Vue.js 和 React.js）。
在某创业公司做单页面应用一年（Angular和Backbone）
目前在学后端（用过 PHP、C#，现在在用 Rails）。
其他的情况看我以前的帖子
第 2 条附言 &·&
08:25:46 +08:00
严格来说，我做了四年『纯前端』，所以不要以为我是后端开发。
第 3 条附言 &·&
09:31:54 +08:00
我回复太快，被限制回复了……
第 4 条附言 &·&
09:41:35 +08:00
@ 如果这些好处没有带来弊端，那当然是好。但是你 client render 之后，逻辑分散、状态不一致的问题要怎么解决呢？
另外，渲染重，你有两个选择：让一个前端把渲染放到浏览器做，或者再买一台服务器。显然，服务器更便宜。
第 5 条附言 &·&
10:01:00 +08:00
关于首屏与第二屏的问题。这个确实是前后端分离的最大契机。
以前所有页面都是一次输出的，但是大公司首页实在太大了，功能太多，等全部渲染完， 10 秒钟都过去了。
于是乎，第二页让 JS 来动态渲染。
这里有两种场景：
1. 第二页的内容与第一页没有关系（这个有点奇怪，为什么不新开页面）
2. 第二页的内容与第一页的结构基本一样（如微博、推特）
场景 2 最著名的解决方案就是 big pipe ，后端前端混合方案。你说的分离是一种方案，但不是唯一的方案。
场景 1 我觉得就是产品经理的问题，需求没想好。
前端工程独立管理看从哪个角度了，维护权给前端没问题，但是可以集成到后端的，比如后端路由发现是 less 请求，直接就变成 CSS 内容。然后发布之前， build 一下前端资源就好了。
我反对的是把简单的事情做复杂，把一个人能做的事情给两个人做。
比如 V2EX 上好几个人发帖『用 vue.js 做了一个 XXX 页面』，说实话，用 PHP 加 jQuery 几下就弄出来了。性能还比他好。
启动服务器工程慢，就要解决慢的问题。
第 6 条附言 &·&
10:06:14 +08:00
我又不能回复了 @ ，我没有太频繁啊。
第 7 条附言 &·&
10:15:04 +08:00
你们就不要拿空洞的『细分总是好的』『发展规律』这种话来讨论了。
你司咋不专门雇一个人写 HTML、一个人写 CSS、一个人写 JS 呢？
而且现在前端把所有东西都跟后端隔开，到底有什么好处？
解耦？如果你认为后端输出就不能解耦，只能说你的后端框架有问题。
处理bug方便？那是因为你们的后端不会写前端，前端不会写后端造成的。就跟一个人学了 CSS 但是不会 JS 一样。
对开发者要求太高？是的，所以我说要把前端做薄，不要搞单页面框架。用 jQuery 你遇到过什么很复杂的 bug 吗？反观 React，一旦出了 bug，呵呵。
第 8 条附言 &·&
10:19:04 +08:00
再说不分离的好处：
1. 一个人知道整个业务。任何业务问题，马上解决。
2. 代码量少。同样的逻辑不需要写两遍（相比浏览器渲染而言）。
3. 也能支持多端。/data 分 /data.json 和 /data.html 两种表现（ RESTful ）
4. 简单。所有概念都来自 W3C 标准，没有那些私有的概念（我说的就是 Virtual DOM ）
5. 省人力。多了 100% 的人力啊（分离需要两个人）
第 9 条附言 &·&
10:50:42 +08:00
OA 跟 ERP ……
这里有几个人是做这种软件的，这种软件完全符合我说的『非常非常非常复杂』好吗，当然需要前后分离。
第 10 条附言 &·&
14:27:08 +08:00
机器到期，换地址了
546 回复 &| &直到
17:27:47 +08:00
& & & & & &
& & 12:42:49 +08:00
前后不分离的话 UI 元素有的是后端直接渲染出来的有的是前端 ajax 得到的
久了之后会很混乱，会让人不想去改 UI
项目小的话不分离没啥问题人脑理得清，项目大了久了就有问题了
& & 12:50:23 +08:00 via Android
前后分离应该是考虑到今后用 app 的，保证数据统一性。
& & 12:50:42 +08:00 via Android
& & 12:51:11 +08:00 via Android
@ 不好意思手抖了...
& & 12:51:22 +08:00
你所说的简单网站里有 ajax 吗？ ajax 取到的数据，塞到模板里头，这是后端的事还是前端的事？前端负责 ajax 的话，这是不是就前后端分离了？把调接口，塞模板这一块放 node 那层，跟页面里头 ajax 取数据区别大吗，你觉得这就能算后端了吗？
& & 12:59:08 +08:00 via Android
现在的前端又不是只是做几个展现页面的。我现在在做一个 WebApp ，并且没什么心情一个一个$$$$，开发效率太低都在做无用功。另外我没懂楼主强行扯上 Nodejs 中端有什么意义。你说前端的东西要让后端可插手，然而后端的东西仍然要配置一堆环境才能跑得动（ PHP 都要起 cgi 呢）。而且双方互相插手有什么意义？前端出现了一大堆构建工具，恰恰说明现在的前端正在工程化、正规化，也大大提高了双方的开发效率。而且你说不提倡前后端分离，那这么多年的客户端开发全部都要变成后端直接给 XAML 之类的渲染吗？大部分的软件也是如你所说可以直接后端模板渲染出来的呀。分离需要两个人就完全是强词夺理了。我赞同的是，例如活动页等一次性展示页、博客等基本没什么交互的页面，直接模板+jQuery 方便。剩下的，就前后端分离吧。
& & 13:00:49 +08:00
楼主说的前端的概念很局限，只局限在了浏览器是吧？
如果项目只给网站提供服务，团队又足够小，那爱咋写咋写。一旦你的产品既要为浏览器端提供数据模板渲染，又要给移动 App 提供数据，那么前后端分离的做法是不是会降低一些后端压力呢？
后端只提供数据接口，处理业务逻辑。前端管你是什么浏览器还是桌面应用还是移动应用，来后端拿数据就是了。
这样，浏览器前端因为浏览器的特性，就要自己去实现登录态管理，去实现部分缓存以降低后端压力。
跟语言没关系，跟框架也没关系。你的后端只是一个单纯的数据业务中心，把它当成一个数据库就好。
另外，一个人就能知道整个业务，说明还是业务太少，项目不够大（小项目瞎折腾个啥）。没见过哪个医生啥病都会治的。
& & 13:01:03 +08:00
正在前后端分离的团队工作，可是业务逻辑前端尽然不闻不问？！鉴于这种现状，我更倾向选择全栈式开发。
& & 13:03:27 +08:00
& & 13:09:12 +08:00
1. 一个人知道整个业务。任何业务问题，马上解决。
这个不是好处，有些时候还是必须要避免的弊端。
4. 简单。所有概念都来自 W3C 标准，没有那些私有的概念（我说的就是 Virtual DOM ）
看似简单，其实很混乱。你也说了，不利于招聘。
只有前后端分开，才能各自快速的发展，而不需要拖个大油瓶，互相掣肘。这一点参考物理学的发展史就可以了。
& & 13:11:52 +08:00 via Android
@ 前端没必要知道业务逻辑啊，只要完成前端应该完成的工作就行了吧
& & 13:30:58 +08:00 via iPhone
@ 我很荣幸
& & 13:48:58 +08:00
@ 这就是问题所在，后端负责数据相关的处理，页面上也有很多业务逻辑。
& & 13:49:34 +08:00
感觉楼主看问题不够透彻啊。哪有这么简单的。。。
& & 13:52:56 +08:00
看起来像是废柴前端和废柴后端写的东西。
为什么这么说？以为一个工程师要能 精通前端的时候还能把后端也掌握到精通（或者反过来）？
& & 13:52:56 +08:00
很多前端都会后端，这个话题还有什么好争论的...，一个人写完了
& & 13:56:26 +08:00
@ 哪有那么复杂的？
& & 13:57:22 +08:00
同意楼主观念，很多时候，前后分离是多此一举的举动，反而徒增复杂度，如无必要，勿增实体。当然我们也要考虑到具体的场景来分析，如果所构建的应用比较复杂，前端开发人员水平比较高的情况下，前后分离对于工程化，结构化等系统性架构问题还是很好的。
但是，大多数情况下，真的没有必要，只会增加成本，当然对于行业来说是一个利好，但事实上，该有的问题依然存在，甚至增多。开发效率，项目管理，代码可维护性等，未必会好，开发成本可能更高。当然这一切都是取决于团队人员和项目的具体分析而来。
总之：不要为了前后分离而分离，项目的人员水平和项目具体业务等情况，都是参考因素。
& & 13:58:31 +08:00
人员上是否要分离主要看团队内人员的能力，代码上是否要分离就要看 leader 是否重视质量了。
鉴于目前人才市场上充斥大量培训班水平的，能分还是分吧，一端腐烂总比总体烂好
& & 13:59:07 +08:00
@ 前端如外包，对业务不关心（不愿关心），也关心不了（无法关心）。
& & 14:00:17 +08:00
工程师当然是要往全栈发展，但是技术架构上肯定是前后端分离的，即使后端模版渲染，也要做到前后端分离啊。这里的前端指的是直接面向用户的部分，并不是按语言分，不管你写 PHP 也好， Java 也好。
& & 14:00:44 +08:00
@ 一个三五年的后端，花点时间学下前端，不是什么问题。反过来就不一定了。
& & 14:03:21 +08:00
@ 后端没必要知道需求啊，完成 PM 布置的任务就好了吧
对自己不了解的领域不要太想当然
& & 14:03:51 +08:00
以前后台开发新功能不用做管理，现在前后分离还要写文档，唉，文档真的好恶心。。。。。。
& & 14:05:00 +08:00
想知道 LZ 的“分离”定义是什么
从文章及回复看，存在人手分离和业务分离两种概念混杂，而且一会儿说这个，一会儿又是那个，很不清晰
前后端分离理应指的是业务分离，即使同一个人做，也是应该分离的
为什么业务分离？
很重要一点是前端和后端并不是一对一关系，是多（前端）对一甚至多对多关系
从后端摆脱前端直接输出，是可能要使用很多套输出方案并行的
再说人手分离
一个人同时做网页（ N 大浏览器兼容）、 Android/iOS/WindowsMobile 、非面向公众的业务客户端……呵呵
& & 14:10:08 +08:00
@ 分离指后端输出 JSON 就不做了，前端负责渲染界面。一般分给两个人做一个业务。
& & 14:11:04 +08:00
抛开业务说技术都是耍流氓的
& & 14:17:17 +08:00
@ 大部分业务都不需要前后分离。 只有上面说的几个特例需要。
& & 14:20:04 +08:00
& & 14:20:30 +08:00
解耦， 必要时后端和后端也要分， 前端和前端也要分，，，
& & 14:22:35 +08:00
@ 纯粹引战啊。。。每个项目都有自己的架构思路的。。。
& & 14:25:38 +08:00
我是前端，刚开始看到这个题目，我也觉得楼主是来引战的，看着看着，确实有点道理
& & 14:27:13 +08:00
@ 你再看看我以前的帖子
& & 14:27:49 +08:00
@ 不是的， 90%的网站都是增删改查而已，而且不需要做成单页面
& & 14:29:07 +08:00
@ 分开和分离还是两个意思。
在后端把数据和标记做好，然后在前端去初始化、去请求数据。逻辑分开当然是对的。
现在的前后分离是前后端互相看不懂，只通过 HTTP 交流。
& & 14:32:54 +08:00
分离挺好的, 职责清晰, 就像当年 MVC 要分开一样, 现在是 MC 了, 直接不管 VIEW 了, VIEW 独立出来, 更爽...
& & 14:33:59 +08:00
我只说一句话：一大帮比自己牛 X 的人都在努力的方向，基本不会是偏离的方向，尤其是技术上。 全栈工程师在此飘过。
& & 14:40:48 +08:00
你这是偷换概念啊，前后端分离是大概念，怎能大幅缩小范围呢？纯粹是引战
json 只是一种数据格式而已，例如以前，包括现在还很普遍的使用 xml ，网页端就用 xslt-&html+css ，其他客户端就用各种 xml paser 解析器+渲染器
诸如此类，但总的来说就是后端输出一个不限客户端的通用可解析数据，这就是目前前后端分离的概念
如果不分离，后端至少要输出两个方案：一个 BS ，一个 CS ，而且根据需求，极可能要两套或以上设备运行，之间还要做数据同步
& & 14:40:54 +08:00
@ 那可不一定啊……比如 XHTML 、 Flash ……
& & 14:44:48 +08:00
@ 输出两个 format 是很简单的事情， RESTful API 就行了
不然 HTTP 请求头里面的
accept 是干啥用的。
& & 14:51:25 +08:00
@ 后端 model 映射到一个结构化数据是很简单，映射成一个 HTML 文档简单吗？ UI 说白了就是一直在变，就是复杂，所以把他单独管起来。
& & 14:52:24 +08:00
你这里所说的前端是指 web 前端，但在我们划分前后端职责的时候说的是：前端负责交互和展示。而这个范围包括 PC 、 App 、网页等等。
& & 14:55:46 +08:00
你只需要知道服务的接口怎么用就行， 干吗知道那么多呢， 比如你要用到 twitter api, 难道你不知道他怎么内部实现的， 就不能工作了，，， 说白了就是抽象
& & 14:57:41 +08:00
楼主很早就离开阿里了么？
目前我们已经开始主推「全栈工程师」了，内部项目和控制台类应用，甚至部分线上项目，开发同学都是从前端写到后端（基于 React 封装的 DPL ，包含基本的样式和交互），前后端分离的概念已经越来越淡了：）
这套技术方案，我们即将开源，可以关注下
PS ：阿里巴巴-国际 UED-前端团队（ Base 杭州 /深圳）欢迎大家，一起来做点有趣的事情
& & 15:01:14 +08:00
@ 今年离开的，早期 1688 那边的 React DPL 我也参与了……
& & 15:08:57 +08:00
@ 不是很复杂呀，毕竟 HTML 很类似 XML
& & 15:30:56 +08:00
说的挺好的，这个观点我也一直在思考，首先全栈我是最推崇的，我自己也是走的全栈的路线，在队伍允许的情况下，全栈我觉得会更好，当然队伍条件可以的情况下，怎么做都不会是问题。
不过就我个人来说，我也经常回头看自己的代码，比如 rails 做的项目，我会发现，大部分时候，都在写 js 或者 coffeescript ，所以我会考虑是否要在前端引入框架，但是做到后面，发现分离以后，后端无论用什么，都没有 rails 舒服。
但是回到队伍本身，有时候事情不是完全能按照自己的意愿去建立，在人员实际情况的限制下，前后端分离目前还是有一定的可取之处
& & 15:40:19 +08:00
难道不是越是全端越是喜欢前后端分离么？
& & 15:43:10 +08:00
我是前后端分不分都无所谓，反正学点后端模版语言也没啥
& & 15:46:51 +08:00
@ 嗯，变化挺快的，我们都已经经历了三次迭代升级了：）
& & 15:48:18 +08:00
不过楼主倒是说出了真相，国内有多少公司需要 react 呢？大部分业务 jquery ＋ template 足以，无非就是装逼显得自己很牛逼抬高门槛，我不是阴谋论，我就是前端，看到很多，比如新闻类的网站也装逼上 react ，知乎有阵子也特么上个 react ，神经病，现在是项目还没开始，先 react ， babel ， gulp ， webpack 全都搬出来了，好了，终于可以开始写 hello ， world 了，有意义么？不是说反对这些项目，而是没用到点，比如前端在线编辑器，管理后台重操作重数据编辑的用下 react ， vue 说提升效率我不反对，这个稍微了解下就知道，但是尼玛你一新闻网站，问答网站搞 react 不是装逼是干嘛？国内这风气，哎
& & 15:54:01 +08:00
不过全栈要求确实太高了，以现在创业公司体量，基本上是找不够人的，你说的是招软件工程师， web 工程师
& & 15:55:28 +08:00
@ 对啊，一套服务对应多个产品，这样的例子太多了
& & 15:57:25 +08:00
java 全栈开发的路过，目前进阶 node.js 开发
& & 15:57:40 +08:00
感觉楼主说的和我所理解的不太一样。。。
个人认为前后端分离后，后端服务化，而不只是 Web 层开发的前后端分离，这样分离后整个 Web 层都可以理解为前端。在这之前前端一方面有点闲了，分离增加点任务提高门槛也不是坏事，另一方面后端更后，专注底层服务的稳定。而分离后的前端，不用去考虑 API 的背后发生了什么，至于页面渲染在 B 端渲染和在 S 端渲染各有各的合适场景。各自做各自的测试等等也会更方便。
前后端分离个人理解为一种架构，这与设计模式等等类似，每种架构和模式都有对应的场景，抛开场景谈架构和模式意义不大。
楼上有人把 Vue 和 jQ 比较的个人感觉一个 view 层的库和一个工具类库没有比较性可言，要比也是把 Vue 常见的一套和 jQ+backbone 来比较。
至于 Node.js ，感觉这个出了有利有弊，利在于前端生产力的提升，推动了前端工程工具的发展，在这之前不可否认前端工程化不是没有，但推广程度挺差的， Node 的火爆让前端工程化工具层出不穷，工具优劣不做评论，个人感觉现在还是探索期，实践才能沉淀出最佳实践； Node 的弊端除了 Node 自身之外，还有就是一些人会将传统前端的开发思维带进 Node 。然而 Node 只是一个普通的后端平台，注定和其他的平台一样有优点和缺点，无脑鼓吹 Node 不可取，无视 Node 更不可取。
还有就是前面提到的 Node 和 nginx ，感觉 Node 和 nginx 没有什么竞争关系啊， nginx 是一个服务器，用做静态资源服务器和负载均衡等等， Node 虽然也可以实现 nginx 的功能，不过并不觉得他们会有什么冲突。
不可否认的是 JS 相关的东西都在越来越火， JS 一统天下可以当个笑话来看看，也可能被实现，无论如何可以看到的是 JS 相关的东西以及 JS 本身正在借鉴已经成熟的平台 /产品，变得越来越完善。我的态度是在这股热流中，保持自己的见解，学习值得学习的东西，不去过度迷信工具。
& & 16:09:28 +08:00
其实就是前后端分离的架构并不适合楼主现在的业务，所以看不到好处，还带来了一堆问题。
我的观点是，前后端是否分离没有好坏，只有合不合适
& & 16:20:29 +08:00
@ 确实。另外分离有利于保持 小团队运作，文档写清楚，不用天天开会讨论。 怎么感觉楼主在故意挣积分呢。。
& & 16:24:29 +08:00
@ 不分离一样要好好写文档，你看那些流行的 jQuery 插件，文档多好看啊
& & 16:25:43 +08:00
@ 我说过啦，用 RESTful API 就能解决这个问题
安卓请求 json format ， Web 请求 HTML format
& & 16:31:04 +08:00
“安卓请求 json format ， Web 请求 HTML format ”？
难道 在某个语言的模板里写 html 会比直接写 Html 更舒服？
& & 16:41:34 +08:00
看过楼主的两个帖子，都有干货，是抱着讨论的目的来发帖的，这一点我很欣赏，赞一个。
不过我觉得这篇文章写得不太好，最起码应该先就什么是”前后端分离”达成一致。
看了大家的回复，结合我不多的开发经验，我觉得“分离”之后的模块化更容易理解和被工程使用。
& & 17:04:35 +08:00
@ 因为按照 REST 的观念， JSON 和 HTML 只是两种展示方式而已，数据内容是一样的。
& & 17:07:05 +08:00
@ 不分离也能模块化，只是面向全栈的 Web 框架不多而已。比如 meteor js 。
前后分离之后只是让「写出针对前端的框架」更容易而已。
& & 17:08:04 +08:00
肯定不一样啊。
html 还包括 js,样式。
而且一个 html 未必只调用一个接口的数据。
& & 17:09:15 +08:00
@ 不包括 JS 的 HTML ， JS 是行为，不跟数据放在一起。
这个是「古代」 Web 开发的约定吧
& & 17:09:24 +08:00
楼主~ 艹粉么~ 加个微信呗
& & 17:10:26 +08:00
html 也不是数据。
你不在 html 中插入 /使用 js 的吗？
& & 17:16:35 +08:00
你做 webapp 也不搞分离，我给你点赞。。你们公司招的人都要全栈。你们老板有钱还是有耐心。。
& & 17:40:12 +08:00
@ 彩程公司，你搜搜。
& & 17:50:37 +08:00
其实我觉得纠结分不分离，还不如直接写写 ios/安卓，你不分离都不行。
浏览器端的乱象是必然的，因为框架要发展，但是 W3C 好像也不重视这个，所以各个流派就起来了。我前几年就预料到了这种情况，所以一开始就选择安卓，等浏览器端发展好了再回来看看。
& & 17:58:48 +08:00
我觉得并不是会不会的问题，就算你是全栈，一个大项目一个人就是做不了（规模在那里），这个时候就需要分工，前后端分是一个相对较优的分工方式吧
& & 18:45:34 +08:00 via Android
@ 用现成的库或组件啊
& & 19:47:52 +08:00
脱离了工程实际，这种问题只会变成宗教争论。
“前后端分离”看上去很正确。其实即使从整个社会的尺度来看，“专业化”也特别政治正确。
但这个正确是建立在复杂度的基础上的，不应该不加权衡地奉为圭臬。
遗憾的是，许多人深知缺乏规范的弊端，所以特别喜欢追求规范，以至于矫枉过正，特别热衷于信奉信条。
既然以解决问题为目的，应该少谈些主义。
& & 19:50:06 +08:00
求作图的软件
& & 20:24:36 +08:00 via Android
@ balsamiq 加 hanzipen 字体
& & 20:43:29 +08:00
看各位大大讲感觉好厉害的样子
& & 20:45:44 +08:00
我玩前端两个月的时候，打算重写一个每日 IP 量四位数论坛，用的设计就是前后端分离（ REST+Angular ），前端工程化方案，甚至连 Node.js 中间层都有考虑在扩展方案里面。这个项目想找人一起做，多半是因为我是学医学的，一直找不到能合作的人。
后来自己忙了，再加上 Angular 出了 2 有些犹豫，就一直搁置在那里。
当时还和某刚入职美团的前端妹子讨论这套方案来着，直到一年后，突然发现阿里那群人怎么弄的东西和我想得一样……
& & 20:55:15 +08:00
前后端不分离写起来实在是累，又不是人人都是全栈
& & 21:10:02 +08:00
楼主，我就在国外，大公司不用说了，小公司不单搞分离，而且搞的比国内还明确，归根结底是人工费用高要外包给不同的人，不分离以后怎么维护？
& & 21:19:38 +08:00
除了刚开工作的时候使用 Rails 全栈之外，之后的所有的项目都是前后端分离，而且个人项目也一直前后端分离。
& & 21:46:04 +08:00
开始学写后端了？
& & 21:54:06 +08:00
我觉得楼主说得很有道理, 前端单纯用 HTML + CSS + jQuery 一样能做复杂的业务.
& & 22:03:44 +08:00
还有一条，前后端分离对 SEO 并不友好。
不过 在企业开发领域，前后端是很有必要分离的
& & 22:07:04 +08:00
这不是显然么……如果一个人都会了，当然就不分最好。。。
最好还是前端，后端，算法，设计全包了。。。
问题难道不是因为实在是这样招不到人，于是得想办法拆开啊。。。
& & 22:49:03 +08:00
前后端分离的意义除了能处理更复杂的交互以外，更大的意义来自协作效率的提升。
事实上规模稍大的公司，前后端都是独立的人负责的。要让前端理解后端的架构，让后端更写出性能好又没有 BUG 前端页面，这提高了双方的学习成本。 OK ，你们公司运气比较好，找到了 2 个全栈工程师，前后端都牛逼，那么某天其中一个人离职了，你的公司可以承受这样的风险嘛？无论怎么推崇全栈工程师，真正面向用户的产品，最终会回归到前后端独立工作的局面。而这种人员架构的分离，才最终导向了前后端分离的架构。
具体不分离的时候有多坑，有经验的都体验过，不多说了。
& & 23:21:27 +08:00 via iPhone
前后端分离是次要的。初期的架构设计太重要了，设计的烂，中后期各种坑，各种重构
& & 23:25:34 +08:00
作为一个长达 6 年的全栈工程师兼架构师，我说一下我的观点。
经手了很多项目后发现，一些稍大的项目（至少 4 人配合），前后端完全分离具备一定的意义，在磨合较好的团队中施行这套策略，可以很好地提升开发效率。不过前提是你能把握住局面，也就是清楚的知道各个部分的衔接，前后端彻底分离开后需要一个人来控制总体结构，才能保质保量。那么实质上考验的是负责衔接的那个人。
不过大多数创业项目可能在初期并没有那么多人负责开发，顶多一个人两个人，那么这个时候其实也可以做到前后端完全分离，怎么做呢？那就是预留。
把接口预留好，这样后端在做前端的时候使用接口（虽然还是用 PHP 之类的后端语言构建前端页面），等队伍壮大后，前端独立出来，这套接口还是可以继续用的。
稍微有进展的公司，项目都会从单纯的 web 扩展到移动客户端甚至是桌面客户端，前后端完全分离还是有一定的意义的，只不过过程可能是极其缓慢的，正如你考虑的那样，一开始就做前后端完全分离是不理智的，不过适当的预留也可以避免项目扩大后的重构危机（假如有机会）。
至于个人玩的项目，我推崇楼主的观点。
& & 23:39:41 +08:00 via iPhone
后端那么好做？后端的学问很稳定，不像前端五花八门，但是知识面之广，做前端的小瞧了点吧.说实话，我觉得前端玩的一些概念后端早就有了.
& & 23:49:00 +08:00 via iPad
后台服务要服务化，满足多平台接入，例如移动端， web 端，第三方等。
前台要组建化，统一体验，对用户友好。
还没说可用性和安全性，这就是分工的意义，最终保障的产品质量和服务质量。
楼主应该是想表达个人能力，技术的发展宽度，而非组织架构团队分工的问题。
& & 00:03:47 +08:00
问题是，不是人人都和楼主一样有能力啊，能前后通吃。
& & 00:04:42 +08:00
@ 你有没有想过，是因为我们用的框架，不前后通吃。而不是因为人。
& & 00:04:44 +08:00
说就说，不说就不说，呵呵个***玩意啊。估计你属于有技术那种，但无奈语文体育老师教的……组织不起来！
& & 00:07:32 +08:00
我的前端团队的主要 Leader 就在上周提出了前后端不分离的想法，不过后端是用 nodejs 。讨论的结果是接下来的一个项目按页面而不是按功能分，要什么接口自己写。这样可以生产高聚合的程序，忽略适用性和可维护性，以提高效率。 Leader 自己也说这样做适合初创团队，适合小团队，有益于团队成员的成长，而不是在自己擅长的领域固步自封难以提升。与楼主不谋而合。
& & 00:25:19 +08:00
大公司我不知道，小团队来说前后端还是要分离的，后端 API ，前端完全独立一个项目是目前我们团队的状态，这样对每个人的要求都很高，但是业务逻辑十分清晰，每个人拉出来都能顶住一方面业务，还可以交换着做，很好。我们后端是 nodejs + python ，前端 angularjs 单页应用，后端是由好几个 git 项目组成的， API 同时面向 web 和 app ， web 前端也有独立的 git 项目，团队里每个人都是从 php ， nodejs ， python ， ruby ， java 到 jquery ， angularjs 都能写，数据库也是 pgsql, mongodb, mysql(极少)混杂，对这些全盏工程师来说要从业务到架构都分离，我们连模板引擎 ejs 和 jade 都省了，全部都是轻装上阵。
& & 01:04:02 +08:00
看情况吧，我们分离就有好处：
* 后端写一套 api 给 web/app 通用
* 后端写测试也方便
& & 01:15:30 +08:00 via Android
作为后端开发，我觉得前后端分离蛮好的，后端专心做逻辑就好，不用操心前端这种复杂的东西。专业的事情就交给专业的前端工程师们搞就好了。
至于全栈，我若是有学会前端从而成为全栈工程师这个闲工夫，我宁愿多写几个 testcase 提升一下后端代码的质量。
& & 01:35:29 +08:00
@ 不分离也能做到……请看 Rails
现在测试做得做好的社区就是 Rails 社区吧。
& & 01:57:38 +08:00
从我开始写第一行 html 开始，我一直以为凭着一个 chrome 和一个记事本我就能做一个“优雅”的前端……
直到有一天，他们开始逼我用这些前端工具……
& & 04:36:47 +08:00
「一个人能做的事情变成需要两个人做了」
并没有，原来 20 个人做的事，并不是变成需要 40 人做了，而是其中 10 人做后端， 10 人做前端了。总人数并没有变啊。
而且作为后端，前端那些活我压根不想做好吧！
& & 08:32:51 +08:00 via iPhone
前后端分离一方面 web 、 app 可以复用同一个服务器，使用同一套逻辑，降低维护成本；另一方面可以将渲染的计算压力丢给客户端，降低成本，前端直接使用静态文件维护起来也方便，还能提升用户体验。如果你看过 openstack horizon 那套渣渲染设计，就该庆幸前后端分离。我司就是全栈开发，照样前后端分离，一样搓的比原来爽。
& & & & & &
& · & 561 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 88ms · UTC 19:24 · PVG 03:24 · LAX 12:24 · JFK 15:24? Do have faith in what you're doing.