In order to solve the problems caused by traditional Web development model, we have been many attempts, but due to physical gulf front / rear end, try the program are similar. Bitter experience, today we have to rethink the definition of "front and rear end", the introduction of front-end students are familiar NodeJS, trying to explore a new model before and after the end of the separation.
With the rise of different terminals (Pad / Mobile / PC), the requirements of developers increasingly high, pure browser-side response type can not meet the high demands of the user experience, we often need to develop customized for different end version . In order to improve the efficiency of development, before and after the end of the separation needs more and more attention, in charge of the back-end business / data interface, responsible for front-end presentation / interaction logic, with a data interface, we can develop multiple customized versions.
This topic was recently discussed more than, some BU Ali also make some attempt. After a long discussion, we decided to explore a set of team-based NodeJS before and after the end of the separation plan, the process with some knowledge and thinking constantly changing, documented here, would like to see the students participate in the discussion, to help us improve.
First, what is before and after the end of the separation?
Initially the group discussion process, I found that everyone is not the same before and after the end of the separation of understanding, the discussion in order to guarantee the same channel, first on what is the "before and after the end of the separation" agreement.
Examples of the separation of the front and rear end everyone agreed is the SPA (Single-page application), all the data used to show all the back-end through an asynchronous interface (AJAX / JSONP) way to provide front end just to show.
In a sense, SPA are done before and after the end of the separation, but there are two problems with this approach:
WEB services, SPA class proportion few. There are many scenes synchronous / asynchronous synchronous + mixed mode, SPA not be used as a universal solution.
SPA at this stage of development mode, the interface is usually provided in accordance with logic to show, sometimes in order to improve efficiency, the back end will help us deal with some show logic, which means that the back-end is still involved in the work of the View layer, not real separate front and rear ends.
Front and rear ends SPA-style separation is done to distinguish from the physical layer (as long as that is the front-end, server-side client is the back-end), this points system has been unable to meet our before and after the end of the separation of demand, we believe that division from the duty to we meet the current usage scenarios:
Front: in charge of View and Controller layer.
Rear: only responsible Model layer, business process / data.
Why do such a division of responsibilities, will continue to explore later.
Second, why should the front and rear end of the separation?
On this issue, Yu Bo article in the evolution of Web development mode explain very comprehensive, we'll probably haircut:
2.1 application scenarios existing development model
Yu pathi to several development model, each have their own application scenarios, which do not completely replace another.
For example, the back-end-based MVC, do some high efficiency synchronous show business, but encountered a combination of synchronous asynchronous page to communicate with back-end developers will have trouble.
Ajax dominated SPA-type development model, more suitable for the development of APP types of scenes, but only suitable for APP, because SEO and other issues not been resolved, for many types of systems, this development is also way too heavy.
2.2 before the end unclear
In the business logic of complex systems, we are most afraid of maintaining the code before and after the end mixed together, because there is no constraint, MVC each layer another layer of code that may appear, over time, there is no maintenance at all.
While the front and rear end of the separator can not completely solve this problem, but can be greatly eased. Because the guarantee from the physical level you can not do that.
2.3 Development Efficiency
Taobao Web are essentially based on MVC framework webx, the front-end architectural decisions rely on the back end.
So our development model is still the front-end written static demo, translated into the back-end VM template problem with this model is not to say, Tucao for a long time.
Based directly on the back-end development environment is also very painful, very troublesome installation configuration. To solve this problem, we invented a variety of tools, such as VMarket, but still want to write front-end VM, but also on the back-end data, efficiency is still not high.
In addition, the rear end would not be able to get rid of a strong concern for the show, which focus on developing business logic layer.
2.4 Limitations on the front end of play
Performance Optimization If you only do very limited space at the front, so we often need to cooperate in order to back-end collision sparks, but due to the back-end framework limitations, it is difficult to use Comet, Bigpipe and other technical solutions to optimize performance.
In order to solve some of the problems mentioned above, we have been many attempts to develop a variety of tools, but has not much improvement, mainly because we can only go to play in the back end to our division that small space. Only truly separate front and rear ends, we can solve these problems.
Third, how do before and after the end of the separation?
How to do before and after the end of the separation, in fact, the first section has been answered:
Front: in charge of View and Controller layer.
Rear: responsible Model layer, business process / data.
Imagine if the front master Controller, we can do url design, we may decide to synchronize the rendering on the server according to the scene, or under the view layer data output json data, we can easily do Bigpipe, Comet based on the presentation layer requirements, Socket and so on, is entirely demand determine how.
3.1 Based on NodeJS "full stack" Development
If you want to achieve layered on the map, we will inevitably need a web service to help us achieve before the back-end to do, so there will be mentioned in the title of "full-stack based on the development of NodeJS"
This picture looks simple and well understood, but not tried, there will be a lot of questions.
SPA mode, the backend for the required data interface, view the front end can already control, why pay more NodeJS this layer?
Extra layer, how about performance?
Adding one more level, front-end workload is not increased?
Extra layer on an extra layer of risk, how to break?
NodeJS can do anything, why JAVA?
These questions are not easy to make it clear, here about my understanding of the process.
Why add another layer to 3.2 NodeJS?
At present, we mainly after the end of the MVC development model, this model has seriously hindered the front-end development efficiency, but also to the back-end can not focus on business development.
The solution is to allow the front to control the Controller layer, but if it is difficult to achieve in the prior art system, it is impossible to make all front-end are learning java, install the back-end development environment, write VM.
NodeJS can be a good solution to this problem, we do not need to learn a new language, be able to do previously developed to help what we do, everything seemed so natural.
3.3 performance issues
分层就涉及每层之间的通讯，肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作，会大大提高开发效率。分层带来的损失，一定能在其他方面的收益弥补回来。
另外，一旦决定分层，我们可以通过优化通讯方式、通讯协议，尽可能把损耗降到最低。
举个例子：
淘宝宝贝详情页静态化之后，还是有不少需要实时获取的信息，比如物流、促销等等，因为这些信息在不同业务系统中，所以需要前端发送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的全栈开发变成一个稳定，让大家都能接受的东西还有很多路要走，我们正在进行的“中途岛”项目就是为了解决这个问题。虽然我们起步不久，但是离目标已经越来越近！！
END
碧茂课堂精彩课程推荐：
1.Cloudera数据分析课；
2.Spark和Hadoop开发员培训；
3.大数据机器学习之推荐系统；
4.Python数据分析与机器学习实战；
详情请关注我们公众号：碧茂大数据-课程产品-碧茂课堂
现在注册互动得海量学币，大量精品课程免费送！