本文是学习 尔达 Erda 在前后端分离系列文章之后的简单整理和总结，方案非原创。

传统的前后端分工和合作方式

  1. 后端需要先设计和确定好API, 交给前端处理渲染和交互逻辑
  2. 前端需要关心很重的业务逻辑
  3. 前后端需要高度的沟通业务，保持协同

存在的问题

  1. 沟通成本，前端需要很好理解业务，与后端沟通好，但是实际效果并不佳
  2. 开发依赖，前端高度依赖后端定义好 API。 如果后端未定义好接口，影响前端开发进展

优点

  1. 前后端分离，降低后端开发工作量。后端能更专注在业务功能实现，不需要关心前端交互
  2. 通过 Restful API, 能很好地描述前后端操作流程

彻底的前后端分离

Erda 提供了一种新的前后端分离的实现方案，减少前端对业务的理解，把更多的交互渲染和业务逻辑交给后端来实现。

简单来讲，就是大致回归到以前前后端未分离状态。

不全依赖 Restful API, 而是前后端约定好一种 组件渲染协议。请求从前端过来后，后端处理，然后以表单形式返回给前端，前端只关心组件功能，根据协议对表单内容渲染，不处理业务。

优点

这种新的前后端分离方式，最大的优点在于很好地解决了目前在前后端开发人力不均衡的现状（前端一直是相对稀缺），减轻前端的开发压力和对业务的理解成本。 同时通过 渲染协议，后端把控前端业务逻辑，不再有沟通不足导致项目理解不一致问题

缺点

缺点也是相对明显的：

  1. 后端开发工作量增大，后端需要关注前端交互逻辑。
  2. 不直接依赖 Restful API, 业务方对接口数据的处理会复杂些

总结

其实整个方案下来，可以看到这两者更多地是一种相对的过程，通过 渲染协议的约束，释放了前端资源，但是这种方案是将前端压力给到后端开发，而且仅仅只靠协议约束是不够的。

可以看到最后 Erda 在落地该方案的时候，没有完全抛弃通过 Restful API 进行前后端交互，因为这会带来一定的困难，而是各取这两个方案的优点，在实现上更好地帮助业务。

整个方案下来，让人耳目一新有两个概念：

  1. 彻底的前后端分离：前端只关注前端组件渲染，不需要处理业务逻辑，后端负责所有逻辑，更好帮助业务实现
  2. 组件渲染协议：Restful API 的一个可替代方案，通过协议约定，前端不需要理解逻辑

另外，一开始是被标题吸引阅读文章，但其实题目没有提炼本文内容，并没有提及 Go 怎么实现前端功能， 有点噱头。不过提出的问题和解决思路值得大家一起借鉴和学习。

参考链接