当前端把手伸向后端,做起全栈时

7,186 阅读4分钟

链接

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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