关于前端工作的一些疑惑

[ericgui]

首先呢，我们后端写的 API 太屎了（一年 C#经验，转 Java 了），也就是说，后端给的数据，和前端用户交互的时候产生的数据产生太大的 gap，我每天都在转化数据，把后端来的数据，重新梳理成前端能用的结构。 （当然，和业务本来就很复杂也有关，也不能完全怪后端。）

老板尚未发现后端 API 太屎，但是他至少认可了这里有很大的 gap，需要我来抹平。

于是我就想起来了，阿里巴巴据说是利用 nodejs，写中间层，就是聚合各种后端 API，然后封装成一个对前端更友好的 API。

大概是这样的，可能记忆不太精确。

所以请教各位，这样的操作是否是常规操作？

如果是，我就考虑考虑用 nodejs 写个中间层，这样前端的代码会更优雅一些，性能和可维护性应该稍微好一些。

至于为啥不要求后端写对前端更友好的 API ？原因我就不说了，指望她，还不如指望我自己。 她设计的数据库，我看了一下结构，比鸡窝还乱，但我没说话，毕竟不好对别人的工作指手画脚。

[zyEros]

我觉得封装 model service 等类，在内部抹平就行了，没必要上 node

[ericgui]

@zyEros 这显然还是要指望后端。。。。

[FEDT]

完全可以。

[q8164305]

前端封装下就好了，没必要上中间层，中间层是为了加快首屏渲染和 seo 的，不是这么玩的

[ericgui]

@q8164305 加快首屏渲染倒是比较需要，SEO 不需要。

[azh7138m]

我觉得 GraphQLParty 还行，可以看一下之前的记录 https://juejin.im/post/5b29cd2be51d4558d217c644

其实算一个 BFF 层，但是会好很多（对前端的友好程度）

[blessyou]

所以你打算用 node 吃屎了吗，并且做好面对以后可能会出现不知道是 node 太屎还是他们后端太屎的准备了吗

[ericgui]

@blessyou 好吧，你说对了，这确实会是个问题，责任划分的问题。就算不考虑甩锅的问题，debug 定位也不好弄。

[IvanLi127]

只有我不知道什么是 gap，google 还搜不出来吗😂

[NCry]

@IvanLi127 我猜测是代沟，不知道对不对

[Dogergo]

这种问题当然让后端来搞啊，规范要从一开始就开始执行，数据结构走统一的定义。而且我疑惑的是，不是你要什么数据他给你什么数据么？

[HSvng]

GraphQL 了解一下

[daodao116]

这个听起来不是前后端的问题，而是系统总体设计的问题。不要为了弥补设计的缺陷去盲目的加入一层。

还有，想问问现在大家用的 js 后端框架都是什么呀？感觉 node 就是个玩具，其他有什么更好一点的推荐吗？

[alexmy]

后端用的 egg.js -> 同构框架 beidou。这就是练手产品 https://www.keylala.cn ，为了简便(实际是云服务器低配)，就把后端都移除了，注册登录，redis，mysql 什么的都不要了。

[stillsilly]

在前端的 model 层处理 不需要多加个 node ……

[baojiweicn2]

接口屎为啥不怼他.....大家都是同事，凭啥要埋别人的坑

[babedoll]

。。没必要

你只需要告诉后端你要什么数据让他穿就好了，另外一般不是穿 json 类型的吗（挠头）还要什么转换吗

[ben1024]

指望她？
渲染层需要包装数据的

[ianva]

后端的 api 会尽量考虑和前端的业务解耦的，所以是必然不适合前端调用的，前端有两个选择：
一个是前端建模，加一层把后端的 api 映射到前端的模型里，然后前端基于前端的模型去开发具体业务，但问题在于前端要不断维护模型的状态，而且无法夸业务复用模型。
另一种就是现在比较通用的加一层 BFF （ Backend for Front-End ），BFF 层去聚合后端 API 然后给前端调用，BFF 层的复用性会更高。

[ianva]

https://hackernoon.com/frontend-in-the-backend-a-pattern-for-cleaner-code-b497c92d0b49