今天聊：前后端分界线与 GraphQL

Posted 2021-04-30 十年有点短

天下苦前后端协同久矣

过去一年多太多同学问我对于 GraphQL 的态度，就小小作文一篇，瞎聊一下。

前后端，从十几年前开始明确的分化，无论前端后端，到现在都经历了太多次的技术变迁，多少程序员黑发到白发，长发到秃头沉沉浮浮，前后端如今的边界在哪里，我们大脑皮层遇到这个问题的第一个反应，往往就是，前端开发页面，服务端渲染页面或者与页面异步同步数据，剩下的事情就交给浏览器了，边界仿佛就在静态页面开发和数据渲染这里，那么它真的是在这个地方么？

要回答这个问题，先聊一聊我的职业生涯，我从事前端开发快 10 年了，算是一个老前端，在我的眼中，前端后端的边界越来越模糊了，而且这个边界也在不同的公司，不同的团队，甚至不同的业务模式下，不断的发生着变化，这不是废话么，那到底边界线哪里，是什么？

我个人觉得，就是数据的控制权和与视图所依赖的 API，这里就是目前前后端的边界，数据控制权属于后端，API 属于后端，把前后端简单看做是一个完整的系统，这个系统中自 API 向下自然是后端的，API 向上则慢慢属于前端，为什么是慢慢属于前端，前后端的职能变化，前后端的分工边界，前后端的角色变迁，都跟我们这一次以 GraphQL 为代表的数据方案有着密切的关系。

不过话说回来，虽然 Scott 从业已久，但这个问题依然是回答的战战兢兢，原因就在于对于技术方向的判断，大多数资深的工程师都会有相似的判断，但对于某一层或者某一块具体的技术实现方案，大家得出的结论会相差甚远，这个有一小部分是人的问题，比如技术视野，技术胸怀，技术背景，以及个人的职业规划，但大部分是客观环境的问题，我们总是站在自己熟悉的若干客观环境下，以此举例和类推，得出整个世界也基本上是类似的情况类似的运作模式这样的结论。

其实不同公司不同团队甚至不同风格的工程师组合在一起，是完全没办法通过理论推导来达成统一的，所以我需要再次重申一下，GraphQL 有可能是不能解决你当下甚至未来的团队合作效率、开发模式问题的，但是它一定会给你带来一些不同的视角来认识到两件事情：

• 第一个， 前后端的合作成本其实很高，源于语言栈源于主导权，也源于各自职能的不同，这个是必然的，即便是有了各种的 Mock 方案，团队规范，工具基建，都没办法大幅度的降低这个成本。
• 第二个， 前后端的边界既不像我们认为的那么清晰，前后端的职能壁垒也不像我们认知中的那样不可逾越，他跟我们内心对自己的工程师身份认同有很大的关系。

所以大家要问自己一个问题，为什么我一定是一个前端工程师，为什么我一定是一个后端工程师， 为什么我一定不想去关心任何系统底层或者上层 UI 的问题，为什么我觉得端上的体验和页面或者服务搭建，几乎是我工作的全部重心，为什么作为前端，往往会觉得上线那一刻起自己的工作就已结束。

这一二十年前后端技术演进的过程中，前后端各自的能力边界都得到了很大的扩展，互相合作才有了今天互联网的繁荣，我个人的角度是，前端后端的边界模糊也好，清晰也罢，本质上我们是一个系统的上下组合部分，通过各种咬合来保证产品正常上线运行为公司创造价值。

至于我们咬合的部分，是需要双方都有足够的勇气和胸怀，迈出一步甚至两步，以团队效率为根本出发点，而不是仅仅职能，前端工程师尽量不要限定自己的界限，可以放大自己的能力甚至是权利，主动承担灰色地带的事情，这些事情的承担看上去是苦活累活，但最终解放的依然是我们自己的价值枷锁。

说的有点玄乎，一句话收尾，前后端在变化，边界也在变化，无论前后端都应该开放心态，调研新工具，实践新方案，站在一起来让工程师的技术价值最大化，帮公司省更多钱，给公司赚更多钱，这个需要决策者的心胸格局和专业度。

这个边界到底如何变化呢，我认为截止到目前，GraphQL 是一个可小范围尝试的解决方案，它能解决问题也同时带来挑战，大家用的时候要小心慎重，而这两年大火的 Serverless，它也有它特殊的生存环境，我们依然可以用 open 的心态看待，小范围试用的尝鲜，但具体到生产环境，我们依然要小心慎重。

10 年一晃而过，大家千万不要以为时间还多的是，所以我把名字改了，暗中提醒大家关注当下。