前端与后端-前端开发后端开发

前言

ok，上周后台有个消息说前后端分离，所以今天的文章有点科普，大家可以看看，内容不会很深。 本文由@AlgorithmDog 授权。

正文从这里开始~

最近一直在鼓捣前端的东西前端与后端，学习了一点前端的知识。 由于这方面的知识太浅前端与后端，所以这篇简单的博客应该作为介绍。

在web开发中，前端攻城狮和后端攻城狮是不同的物种。 一个在任何场景都追求美，一个在巨大的压力下追求失重。 但两人必须紧密配合，才能使项目顺利进行。 分工的核心是在哪里渲染页面。 不同的渲染位置决定了不同的分工方式。

渲染就是将数据填充到模板中，按照模板自定义的样式展示数据。 如下图知乎的例子，图中左上方的模板自定义了我们看到的内容，其中？ 表示没有数据。 这时在模板中填入一个用户的数据（图左下方），就得到了我们看到的页面（图右侧）。 这个过程就是渲染。 共有三种渲染方法。

1.服务端渲染

浏览器向服务器发送请求，服务器处理请求并准备数据，然后将数据写入前端编写的模板生成html文件，并将生成的html返回给浏览器。 这将在浏览器上显示页面。

上面是一个模板。 此模板是一个包含数据绑定命令的 html 文件”

”。后台程序整理数据时，将服务端的数据填充到模板中，渲染页面。如下代码所示，app.render(template, project)语句表示将项目数据填充到服务器端模板生成页面，并发送给浏览器。

这种模式有一个问题——部分更新无法实现。 即使用户点击了一个按钮，并且有轻微的数据变化，后端也需要在将页面发送给浏览器之前重新渲染整个页面。 如果页面有大量的静态部分，这种方法无疑效率不高。

同时，前端工程师需要使用模板来定义呈现形式，后端工程师需要使用模板来输出数据。 随着时间的推移，模​​板将变得越来越复杂且难以维护。

2.在浏览器中渲染

现在的趋势是将渲染移动到浏览器。 浏览器发送请求后，从服务器接收模板和JS代码。 浏览器执行接收到的JS代码，JS代码向服务器请求数据并将数据填充到模板中。 以下代码在页面加载后从接口/online/projectlang中获取项目语言的数据，写入到html页面中。

这段代码执行的效果如下图所示。

使用运行在浏览器端的Javascript语言，前端工程师可以从后端服务器获取数据，然后根据业务逻辑渲染页面。 这个时候，后端工程师只需要开发一个稳定的API来提供数据即可。 这种模式虽然还是B/S模式，但是开发场景和C/S模式类似。 在浏览器端渲染的好处是前端完全掌控模板，后端只需要开发相应的API，分工比较明确。 并支持部分页面更新。 同时，同一套后台服务可以同时支持不同的展示方式，比如同一套后台服务也可以支持移动端开发。

当然，浏览器渲染也存在一些问题。 最大的问题之一是它对 SEO 不友好。 搜索引擎的爬虫程序必须像浏览器一样执行JS代码才能获取页面内容，这样就增加了爬虫爬取页面的难度。

3.大前端模式

在神器Node.js的帮助下，前端工程师终于将爪子伸进了服务器端。 Node.js 是老毛子的高性能异步服务器。 如果只是一个服务器，Node.js 并不奇怪。 一般服务端需要提供一种编程语言的运行时，方便开发者开发。 Node.js因为异步的关系选择了异步性能好的Javascript，也就是前端工程师经常写在页面上的Javascript。 这时候前端工程师看到了，啊，我知道这玩意儿。 因此，使用Node.js，前端工程师不再局限于浏览器，可以在服务端编写Javascript代码。 这时候前端工程师可以根据需要选择在浏览器端或者服务端完成渲染。 我们可以把这种模式称为大前端模式。

在大前端模式下，前端工程师有更多的开发灵活性，可以避免前两种模式的弊端，发挥自己的长处。 然而，世界上没有十全十美的东西，大前端模式也有自己的弊端。 前端工程师被赋予了在服务端编写代码的能力，他们需要承担服务端编程的责任。 拥有权利的同时也被赋予了重大的责任。 在服务端编写代码时，前端工程师必须承担日志、安全、负载均衡等只有后端工程师才需要承担的职责。 大前端攻城狮相当于前端攻城狮和后端攻城狮的基因混合而成的混血体，其稀有程度可想而知。 这就是为什么很少有程序员精通 Node.js 的原因。

第一种模式曾经是主流，但现在第二种模式正在慢慢受到大家的关注。 至于第三种模式，据我所知，目前只有淘宝在做这方面的尝试（ps：美团酒店也在做这方面的尝试，感谢“求助”网友提供的信息）。 我个人比较喜欢第二种模式。 第一个模式太旧了。 第三种模式对工程师要求太高。 毕竟前端工程师和后端工程师的技能树还是有很大区别的。 但是开发领域没有银弹，不同的场景需要不同的模型。

关于这篇文章