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

天下苦前后端协同久矣

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

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

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

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

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

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

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

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

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

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

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

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

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

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


发表评论

邮箱地址不会被公开。 必填项已用*标注

相关