这是一个创建于 2045 天前的主题，其中的信息可能已经有所发展或是发生改变。
首先呢，我们后端写的 API 太屎了（一年 C#经验，转 Java 了），也就是说，后端给的数据，和前端用户交互的时候产生的数据产生太大的 gap，我每天都在转化数据，把后端来的数据，重新梳理成前端能用的结构。 （当然，和业务本来就很复杂也有关，也不能完全怪后端。）
老板尚未发现后端 API 太屎，但是他至少认可了这里有很大的 gap，需要我来抹平。
于是我就想起来了，阿里巴巴据说是利用 nodejs，写中间层，就是聚合各种后端 API，然后封装成一个对前端更友好的 API。
大概是这样的，可能记忆不太精确。
所以请教各位，这样的操作是否是常规操作？
如果是，我就考虑考虑用 nodejs 写个中间层，这样前端的代码会更优雅一些，性能和可维护性应该稍微好一些。
至于为啥不要求后端写对前端更友好的 API ？原因我就不说了，指望她，还不如指望我自己。 她设计的数据库，我看了一下结构，比鸡窝还乱，但我没说话，毕竟不好对别人的工作指手画脚。
第 1 条附言 · 2019-04-11 01:23:14 +08:00
7 楼说的对啊
用 nodejs 写中间层，会导致甩锅不好甩的问题，和导致 bug 不好定位的问题。
用 nodejs 写中间层，会导致甩锅不好甩的问题，和导致 bug 不好定位的问题。
 |
1
zyEros 2019-04-11 00:40:39 +08:00 via Android
我觉得封装 model service 等类，在内部抹平就行了，没必要上 node
|
 |
3
FEDT 2019-04-11 01:01:32 +08:00 via iPhone
完全可以。
|
 |
4
q8164305 2019-04-11 01:05:56 +08:00 via Android  2
前端封装下就好了，没必要上中间层，中间层是为了加快首屏渲染和 seo 的，不是这么玩的
|
 |
6
azh7138m 2019-04-11 01:15:40 +08:00
我觉得 GraphQLParty 还行，可以看一下之前的记录 https://juejin.im/post/5b29cd2be51d4558d217c644
其实算一个 BFF 层，但是会好很多（对前端的友好程度） |
 |
7
blessyou 2019-04-11 01:16:36 +08:00 via Android
所以你打算用 node 吃屎了吗，并且做好面对以后可能会出现不知道是 node 太屎还是他们后端太屎的准备了吗
|
 |
9
IvanLi127 2019-04-11 09:11:22 +08:00 via Android
只有我不知道什么是 gap，google 还搜不出来吗😂
|
 |
11
Dogergo 2019-04-11 09:35:12 +08:00
这种问题当然让后端来搞啊，规范要从一开始就开始执行，数据结构走统一的定义。而且我疑惑的是，不是你要什么数据他给你什么数据么？
|
 |
12
HSvng 2019-04-11 10:04:25 +08:00
GraphQL 了解一下
|
 |
13
daodao116 2019-04-11 10:18:52 +08:00
这个听起来不是前后端的问题，而是系统总体设计的问题。不要为了弥补设计的缺陷去盲目的加入一层。
还有，想问问现在大家用的 js 后端框架都是什么呀？感觉 node 就是个玩具，其他有什么更好一点的推荐吗？ |
 |
14
alexmy 2019-04-11 10:57:09 +08:00
后端用的 egg.js -> 同构框架 beidou。这就是练手产品 https://www.keylala.cn ，为了简便(实际是云服务器低配)，就把后端都移除了，注册登录，redis，mysql 什么的都不要了。
|
 |
15
stillsilly 2019-04-11 10:58:09 +08:00
在前端的 model 层处理 不需要多加个 node ……
|
 |
16
baojiweicn2 2019-04-11 11:00:48 +08:00 via Android
接口屎为啥不怼他.....大家都是同事，凭啥要埋别人的坑
|
 |
17
babedoll 2019-04-11 11:02:06 +08:00
。。没必要
你只需要告诉后端你要什么数据让他穿就好了，另外一般不是穿 json 类型的吗（挠头）还要什么转换吗 |
 |
18
ben1024 2019-04-11 11:26:51 +08:00
指望她？
渲染层需要包装数据的 |
 |
19
ianva 2019-04-11 11:34:02 +08:00
后端的 api 会尽量考虑和前端的业务解耦的，所以是必然不适合前端调用的，前端有两个选择：
一个是前端建模，加一层把后端的 api 映射到前端的模型里，然后前端基于前端的模型去开发具体业务，但问题在于前端要不断维护模型的状态，而且无法夸业务复用模型。 另一种就是现在比较通用的加一层 BFF （ Backend for Front-End ），BFF 层去聚合后端 API 然后给前端调用，BFF 层的复用性会更高。 |
|
20
ianva 2019-04-11 11:36:32 +08:00
|
 |
21
yhxx 2019-04-11 11:38:28 +08:00
是常规操作，但是我觉得除了 KPI 和提升自己之外没什么好处
为了处理数据，你在浏览器里一样能做 出问题浏览器里还能调试一下，用 node 搞就只能翻日志了吧 |
|
22
ianva 2019-04-11 11:48:20 +08:00
另外在现在微服务及面向多终端的背景下，后端的 API 必然不会和前端耦合的，而且前端也会面对不同服务的接口，这种情况下 BFF 是有必要的。
|
 |
23
november 2019-04-11 12:09:54 +08:00 via iPhone
所以大家都知道 gap 是什么意思吗？。。。
|
 |
24
NaVient 2019-04-11 12:44:53 +08:00
在现在服务端背景下后端的数据和前端业务数据有出入是相当正常的吧....
现在后端提供的是可供多人调用的标准数据，前端根据自己业务整理数据才是“常规操作吧“ |
 |
26
abcbuzhiming 2019-04-11 13:11:45 +08:00 2
我认真的看了一下，我觉得楼主完全没说清楚为啥叫“接口屎”。因为他给你的数据，必须你在前端再转一遍才能用，所以说屎？那我告诉你，前端转换层从来都是客观存在的，无论你用什么，说的再天花烂坠，转换层一定在某种程度上存在。无非这个工作是你来做还是他来做，他来做，那就要涉及后端的计算资源问题，因为后端资源总是稀缺的，很多中小企业是不愿意付出过多计算资源的，所以这个工作就被转嫁到客户的电脑或者手机上了，因此你以它的数据需要转换才能用就说他屎我觉得是不客观的。后端首先要保证的是可用性，其次是性能，最后才是，能不能让前端绑数据时觉得很开心。至于你说上个 Node，那么又涉及一个问题，多出来的计算资源谁出啊？
另外楼主已经觉得对方设计的数据库结构跟鸡窝一样，却打算“自己解决”而不主动在会议上提出，作为技术人员，虽然不违反职业道德，但是你不算尽职。有些问题是一定要及时指出的 |
 |
28
HustLiu 2019-04-11 14:12:39 +08:00
如果不是本身就有一套 node 服务体系，个人建议不要接入……洗数据的事儿，client 做不就完了么，能比放在服务端慢多少？你是打算在 node 层做缓存吗？还是说计算量大到会影响客户端速度？那不就更不适合用 node 来做了……
|
 |
29
whypool 2019-04-11 14:23:15 +08:00
正常操作，没啥喷的
客户端自己去筛选想要的数据 |
 |
30
zhangalong69 2019-04-11 17:01:17 +08:00
领域驱动设计了解一下
|
 |
31
v2chou 2019-04-11 17:11:18 +08:00 1
后端直接 select * from XXX ?
|
 |
32
chairuosen 2019-04-11 17:19:02 +08:00
缺一个前端 model 层
|
 |
33
swaggeek 2019-04-11 17:29:52 +08:00
看需求像是 graphQL
|
 |
34
doommm 2019-04-11 17:30:40 +08:00
我之前在 v2 发过一个类似的问题，对于每项业务我都得写 adapter 来转换请求及响应的数据
|
 |
35
dengshen 2019-04-11 17:34:51 +08:00 via iPhone
可是前端连服务器账户都没有啊！你 node 服务部署在哪呢？
|
 |
36
learnshare 2019-04-11 17:35:47 +08:00 1
找人定 API 文档，然后再开发，这样就可以名正言顺要求后端了
|
 |
37
a494836960 2019-04-11 17:44:23 +08:00
见过后端给的接口数据都是 ID 的嘛！想要 name 需要自己查出来在匹配上去
|
 |
38
wenhainan 2019-04-11 17:47:33 +08:00
兄弟啊,我都替你感到憋屈
|
 |
39
randyo 2019-04-11 18:12:12 +08:00 via Android
难道不是前端要什么数据后端给什么数据吗？本来只要很少的数据和简单数据结构，后端直接把整个 dao 层数据结构丢出来，数据乱七八糟，还要你自己去转换，流量也翻了几倍😙😐
|
 |
40
66beta 2019-04-11 18:36:10 +08:00 via Android
你推动下，上 graphql 吧
|
 |
41
duan602728596 2019-04-11 18:39:49 +08:00
我们的网站就是 node 后端获取数据，剔除掉前端不需要的字段，数据去重，格式化数据。不在前端做的原因是为了性能和节省流量，不存在甩锅的问题
|
 |
42
mars0prince 2019-04-11 18:48:54 +08:00
@abcbuzhiming 和计算资源关系不大，本来计算就应该服务端做的，说白了就是这事就是个狗屎活，没有技术长进还麻烦，谁都不愿意做，就看公司是不是愿意用技术解决了，很多公司面对重复工作就只会堆人力
|
|
43
mars0prince 2019-04-11 18:51:44 +08:00
这个要看你们公司是技术驱动还是业务驱动了，一般业务驱动的公司，基本就无解了，这层对业务没帮助还加了系统复杂度
|
 |
44
ChefIsAwesome 2019-04-11 18:54:39 +08:00 via Android
后端懒而已。你跟他讲 graph ql 他也不会愿意搞。老老实实前端转下数据就行了，能多费性能。
|
|
45
IvanLi127 2019-04-11 19:39:23 +08:00 via Android
我之前也是这样。。后面合作的项目我给他们写了 api 文档。。纯手敲 md，加上他们对我能力还算比较相信。第三个项目后 api 就好些了，不过还是有点不整洁。
现在，我是一名后端工程师了。 |
 |
46
ericgui OP @mars0prince 小型物流公司，所以没有所谓技术驱动。后端就一个人，还是一年 C#转来写 Java 的，因为老板觉得 Java 和 Oracle 数据库配合的更好。。。。。
所以我其实很无奈的。 |
|
47
ericgui OP @ChefIsAwesome 不仅是懒，她还觉得自己牛逼得不行。
|
|
49
ericgui OP |
 |
50
Sain 2019-04-12 10:23:12 +08:00
争取成为全栈
|
|
51
mars0prince 2019-04-12 10:34:19 +08:00
@ericgui 那就赶紧走吧，业务型驱动公司就是这样，尽自己最大能力吧
|
|
55
ianva 2019-04-18 09:51:03 +08:00
@ericgui BFF 层可以考虑 graphql，GraphQLParty 有两个技术分享很不错可以参考
https://juejin.im/post/5b29cd2be51d4558d217c644 https://juejin.im/post/5b32f27ae51d4558b277992b |
Select Language