疯了吧！这帮人居然用 Go 写“前端”？（一）

作者 ｜ 郑嘉涛（羣青）
来源 ｜ 尔达 Erda 公众号
​

无一例外，谈到前后端分离“必定”是 RESTful API，算是定式了。但我们知道 REST 在资源划分上的设计总是与 UI 大相径庭，大量专用、特异、古怪的接口就像永远拾不尽的菌菇，你费力铲除它们，但一场雷雨便又枯树复披。另一方面接口越来越通用，最后却只剩下 CRUD，美其名曰后端只考虑稳定和性能，大量业务逻辑却全权“丢”给了前端，不禁让人怀疑，这真的是前后端分离了吗？

Erda 作为企业一站式云原生 PaaS 平台，也存在着大量面向使用交互的布局各色的界面：从个人后台到部署总览再到项目设置；从集群管理到监控大盘再到成员管理。我们从 REST 开始做起，但也逐渐发生变化。本文将从头讲述我们如何从确实问题切入，逐步建设和完善 Erda 的前后端分离框架。
​
由于整个框架牵涉到太多内容，所以我计划以系列文章的形式来进行详细解读。本文主要介绍其产生的缘由以及设计思路，更多相关的细节会在后续文章中进行展开，包括但不限于：
​

• 框架实现细节
• 使用框架后测试如何展开？
• 稳定性和工程管理
• ······

简要介绍一下本文的主要结构：
​

• 朴素的想法
• 交互 vs 业务
• 回归经典
• 组件及协议

前面三个部分主要介绍了我们建设框架的背景以及方案分析，“组件及协议”部分则整体阐述了框架的核心设计理念。如果你赶时间，建议直接阅读“组件及协议”部分。
​

朴素的想法

所有软件公司都会遇到的困境，那就是分工。老派开发者会信奉单打独斗全栈的能力，但软件变得复杂之后，分工是不可避免的，而最为显著的就是前后端的分工。

Erda 的前端资源一直是紧缺的，最夸张的时候前后端比例可以达到 1:8，大部分情况下，工程的瓶颈在于前端。我们很朴素的认为，改变这个局面需要后端承担更多的工作，以释放前端的人力。
​

交互 vs 业务

所谓前后端的分工，从根本上来说是交互和业务的划分。

下图是最通用的场景，前端关注视觉、体验等，后端关注 CRUD、安全、稳定等。而业务流程、权限等则是散落在前端和后端，我们很难说清楚一个具体的业务逻辑究竟是前端实现的，还是后端实现的。

由上文描述可以预见，这样的划分会导致一些问题：
​

• 重复性工作：进而系统开发会在某些位置产生疏忽（比如前端实现了鉴权，导致后端的鉴权逻辑得不到很好的验证）。
• 前后端对接面积大：带来沟通成本，往往这个成本由前端同学承担，这也是前端资源短缺的原因之一。

试想一下，你是否经常会看到这样的场景：后端写完接口后拍拍屁股走人，独留下前端默默猜测接口的参数意义。包括后来测试出的 BUG，也“总”被认为是前端的问题。

面对上面的问题，业界也存在很多种解决方法，比如采用 NodeJS：