《当前端把手伸向后端，做起全栈时》

链接

本次内容来自内部的一些课题分享，也非技术性的内容，只是浅谈一下作为前端如何“卷”起来罢了。

首先是我们都从事着前端开发的工作，也会每天和产品、设计、后端、测试、运维等产品生命周期内的成员们打交道。

那么什么被称作是“全栈”呢？

从知乎上我看到一句内容我挺赞同的，全栈就是一个通才，能够自己创建不平凡的应用程序。

很关键，其实会和你看到这次分享时的想法有点不太一样，只是在定义全栈这件事情的角度发生了变化。

从广义上来说，全栈就是一条龙服务，即用户提出了一个应用程序的需求，全栈能够独自设计并交付这个应用程序来满足用户的需求。

可以说是包揽了整个应用程序产品的生命周期，样样精通。

但是我们今天也不会讨论的这么广，那么回到正题。

从软件开发的角度来说，即前端+后端可以产出一个应用程序，前端也就是我们俗称的切图仔，也就是我；后端是我们俗称的业务仔。

那么有了如此浅显的认识后，我们该如何从前端出发，把手往后端伸过去，做起一个全栈开发工程师呢？

其实我们可以慢慢的伸过去，我们来回忆一下。

我们与后端交互频率最高的操作，那必定是 HTTP 请求，通俗宽泛一些的讲就是 AJAX 。

在工作多了其实会发现 RESTful 这种架构并没有真正意义上的方便我们的交互，它也有它的问题。

那么这时候喜欢“卷”的我们就设计了一套中间服务，美其名曰 BFF 。

其实 BFF 可以算是我们伸向后端的第一步，首先跟我们的后端同学分析现状，业务仔每次因为一个特殊的需求或者场景需要给我们增加一个 API 接口真的很心累，作为业务仔才不想关心这些呢。我们的后端同学表示只想专心于业务，那么我们“卷”的机会就出现了。

这时候后端同学通常会暴露出一些具备通用性且抽象的 API 接口，至于我们想如何使用，我们则在 BFF 进行自行定义，那么如果遇到上面的问题，我们也不需要苦苦的去求后端同学增加 API 接口，后端同学也可以跟切图仔说拜拜了。

当然了，BFF 中间的实现过程依然可以是 RESTful to RESTful 的形式，也可以是 GraphQL to RESTful 的形式，前者有后端控制，我们 BFF 只做中间的转换者。

慢慢的，你会发现后端没有心思来管业务，他们更多的会去关心一些底层的设计和性能问题，那我们就可以既是切图仔又是业务仔了，这时候的后端为我们提供可以是一些由后端给出的操作数据的接口、或者直接操作数据库的权限，那么这时候我们就是名副其实的业务仔了。

再慢慢的，我们就把手伸到那些底层的设计和性能问题时，后端就不复存在了……（开玩笑的）这是不可能的。

当然了，对于前端……啊呸！软件开发工程师来说，熟悉并掌握整个软件开发的细节，这时候就是全栈了！

自身能力也得到了提升，可以说是卷王之王！

当然了，我觉得接触后端不一定是要做个业务仔的，也可以从应用程序优化的角度着手。

比如我们前端常说的 SSR ，优化应用程序在客户端的启动时间，也会让你接触到后端的技术。

优化 DevOps 流程、缩短编译时间等等优化方向都会让你接触到后端技术，只是作为前端，其实身边有很多机会可以把手伸到后端去，所以大胆伸进去试一试吧！

当然从此发散出去，也可以把手伸向产品设计、视觉交互设计、软件测试、软件运维等各个环节中去……卷他们。