推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 867 天前的主题，其中的信息可能已经有所发展或是发生改变。
我还是希望 restful 风格，graphql 也用了，给我的体验不太好，我也不是一个拒绝接受新事物的人，不知道该怎么办
 |
1
sunhelter 2022-07-20 10:56:16 +08:00
当然是直接跟他讲你不想用呗
|
 |
2
muunala10221 OP @sunhelter 谢谢，主要是担心直接讲了会给对方留下自己固守己见和不喜欢接受新事物的看法
|
 |
3
fcten 2022-07-20 11:06:20 +08:00  2
让后端把你们业务场景下切换 graphql 的好处讲清楚。单纯折腾谁不会。
|
 |
4
sfree2005 2022-07-20 11:19:40 +08:00
写全新功能的时候用还差不多，如果现有的都要改那就太那个了。 话说你为什么不喜欢 graphql ？ 我觉得挺不错，type 类型从后到前， 不容易有 bug ，文档也清晰。
|
 |
5
adoal 2022-07-20 11:22:29 +08:00 via iPhone 11
一般是前端喜欢 graphql ，后端不喜欢…
|
 |
6
pengtdyd 2022-07-20 11:23:56 +08:00 2
根据我多年使用 graphql 的经验来看，这是灾难
|
 |
7
libook 2022-07-20 11:24:33 +08:00 2
把前端且 GraphQL 的成本、风险都整理出来，最好列举一些当前项目已有的用 GraphQL 很难处理的问题，然后让技术经理去做权衡。
个人经验是，完全不用和一股脑全换都是不明智的，工具要用在合适的地方。 |
 |
8
learningman 2022-07-20 11:25:02 +08:00 via Android
graphql 不是挺好吗，试试 codegen ，完整的运行时类型都能拿到，以后都不用联调接口了，拿着类型文档直接写就完事
|
|
9
muunala10221 OP @pengtdyd why
|
 |
10
Jealee 2022-07-20 11:44:59 +08:00
从个人一年左右的使用经验来说，其实 GraphQL 还是挺方便，对于通用接口前端用起来很灵活，后端省事。
不过在做复杂一点的报表时，感觉很难处理，这部分就切换成 restful （也可能是对 graphql 还不够熟悉） 另外鉴权这一块也挺不好做，还需要研究研究... |
 |
11
wu67 2022-07-20 11:45:13 +08:00
新项目, 没什么意见, 可以一试. 如果是旧项目一堆坑, 还加码, 怎么考虑不用我讲了吧....
|
 |
12
jydeng 2022-07-20 11:56:34 +08:00
正在用 gql ，有几个问题搞不定，请教一下各位大手子：
1 、gql 导入文件，目前用 restful 接口替代了； 2 、gql 写不了递归，目前用 any 替代了。 gql 的文档和类型校验，用起来还是不错的，可以很快发现问题。 如果你的前端项目也用 TS 的话，体验还可不错。 |
 |
13
Mithril 2022-07-20 12:04:03 +08:00 3
多年经验告诉我，大部分号称 restful 的风格，都并不是 restful 。
基本都是在拿后端当 View Model 。 对于前端来说，真正 restful 风格设计的 API 比 GraphQL 难用多了。 无非是后端懒得给你改 View Model 了，虽然费事，但上个 GraphQL 你爱怎么折腾就怎么折腾去吧。 |
 |
14
Sendya 2022-07-20 12:11:03 +08:00 via Android
说点我的偏见，graphql 开发一时爽，维护火葬场
|
|
15
muunala10221 OP @wu67 新项目旧代码。。就是相当于换了个皮
|
 |
16
IvanLi127 2022-07-20 13:37:33 +08:00
如果没有专门做 BFF 的话，后端估计不想给你写专供视图层的接口了。如果你坚持要 RESTful ，你可能要自己解决 RESTful 的数据聚合问题。
技术问题嘛，你们前后端开发把各自对这两个技术的优缺点列举出来评审下呗？ GraphQL 我前后端用起来都没啥问题，挺舒服的，前提是要会用。 |
 |
17
siweipancc 2022-07-20 13:44:13 +08:00 via iPhone
照我的体验，身边的前端对数据库一窍不通，让他们写这个只会躺平摆烂。
本身要求就高，不会就换框架或者换人吧 |
 |
18
liaoliaojun 2022-07-20 14:01:49 +08:00
推 GraphQL 其实是利好前端的
|
 |
19
duan602728596 2022-07-20 14:03:00 +08:00
被 restful 坑过的表示，还是 graphql 好用
|
 |
20
zilongzixue 2022-07-20 14:04:36 +08:00
不好做，简单的登录注册还好的，复杂的权限管理和菜单配置简直没法用
|
 |
21
NoNewWorld 2022-07-20 14:15:56 +08:00
新项目尝试下也没撒，但是旧项目直接拒绝，直接说技术栈不好改呗
|
 |
22
janxin 2022-07-20 14:35:57 +08:00
BFF 会对前端不友好？不可能啊...
不过想象一下以后没有前后端接口对接的日子，甚至有时不用等后端修改接口（当然其实这个比较理想） |
 |
23
mcfog 2022-07-20 14:51:41 +08:00
多年没关注了，GraphQL 的后端现在有什么方案是能够比较好的解决 N+1 效率，恶意 query 攻击，复杂 query 性能优化的了吗？
|
 |
24
gouflv 2022-07-20 15:15:18 +08:00 via iPhone 1
@mcfog 跟 ORM 差不多，不太可能有新的方案，架构本身已经定死了。
性能靠各个端的缓存，query 有前置检查来避免复杂度，比如限制结构深度。 |
 |
25
wangtian2020 2022-07-20 15:17:16 +08:00
直接说“我不同意”，然后让 leader 做决定吧
我司倒是直接完整版的 restful 风格，虽然后端他们技术不高逻辑写得慢，接口还是很规范漂亮的。restful+1 |
 |
26
lujiaosama 2022-07-20 15:22:31 +08:00
GraphQL 也不是万能的, 有些东西还是适合 RESTful. 非要上 GraphQL, 得罗列清楚职能范围, 该后端做的东西还是后端做. 到时扯皮就不好看了.
|
 |
27
deplivesb 2022-07-20 15:23:47 +08:00
不应该是前端更喜欢 GraphQL 嘛
|
 |
28
kunkunzhang 2022-07-20 15:58:40 +08:00
@muunala10221 担心直接讲了会给对方留下自己固守己见和不喜欢接受新事物的看法 这个看法看起来你确实很固守己见和不喜欢接受新事物
|
|
29
muunala10221 OP @kunkunzhang 你说的有道理 👍 那你觉得该怎么说好一点呢
|
 |
31
Innovatino 2022-07-20 16:48:59 +08:00
GraphQL 这个玩意儿后端性能到底好了没有，之前公司用过，卡的一批
|
 |
32
sutra 2022-07-20 16:50:53 +08:00
后端想偷懒，把工作转嫁给前端，前端来抱怨了。
|
 |
33
tcitry 2022-07-20 16:54:16 +08:00
GraphQL 这东西竟然有后端想用，前端却不想用的情况。。
|
 |
34
musi 2022-07-20 17:07:32 +08:00
我是前端，也很喜欢接受新事物，但工作毕竟是工作，还要考虑引进来的成本和好处，说白了就是 ROI ，不能为了用而用
|
 |
35
Actrace 2022-07-20 17:21:13 +08:00
不要揽活儿。
轻松一点不好吗？ |
 |
36
shyling 2022-07-20 17:42:01 +08:00
GraphQL 一般不都是前端想要，后端不想搞的吗。。。
|
 |
37
jiobanma 2022-07-20 17:54:49 +08:00
之前接触过 graphql ，后端做的，感觉很难受，而且一些复杂场景不好做。前端用的也不是那么舒服。也不知道是不是使用姿势不对，后来就没接触了
|
 |
38
laolaowang 2022-07-20 17:58:33 +08:00
@shyling 同感，哈哈，
|
 |
39
StarkWhite 2022-07-20 19:52:46 +08:00
graphql 很火了，再不学就 out 了
https://v2ex.com/t/589138 |
 |
41
zythum 2022-07-20 21:39:42 +08:00
一般是前端喜欢 graphql ，后端不喜欢…
graphql 对后端要求比较高，很容易就循环查找了。 |
|
42
StarkWhite 2022-07-20 22:02:50 +08:00
@zythum 用 dataloader
|
 |
43
ericls 2022-07-20 22:34:59 +08:00 via iPhone
你就说你不喜欢 然后为什么不喜欢就行了 他们自然会想办法说服你 多沟通啊 那还能怎么办
|
 |
44
Rocketer 2022-07-20 22:42:20 +08:00 via iPhone
我倾向于前端不要关心这些，后端只是个喂数据的，他能怎么喂取决于他的水平，我都能吃
|
 |
45
wanacry 2022-07-20 22:57:58 +08:00 via iPhone
apijson 不香吗
|
 |
46
realpg 2022-07-21 02:43:56 +08:00
看业务 QPS,以及数据库复杂度
如果 QPS 高,数据库超复杂 查询超复杂,graphql 纯属后端自己作死 |
 |
47
fox0001 2022-07-21 09:09:15 +08:00 via Android
不是应该有架构师、项目经理之类的角色去决定吗？
|
 |
48
haython 2022-07-21 10:43:55 +08:00
公司项目有时候是某些人的实验场，搞完换一家公司
|
|
49
StarkWhite 2022-07-21 16:13:07 +08:00
@wanacry 听说被腾讯收了😂
|
|
50
StarkWhite 2022-07-21 16:16:53 +08:00
|
 |
51
CatRingZ 2022-07-21 16:33:05 +08:00
我感觉使用 graphql 需要产品、前端、后端 一起协作，不然的话 graphql 和 restful 没有任何区别。后端不可能提供出一个能自由组合的图的。
|
|
52
StarkWhite 2022-07-21 17:37:57 +08:00
@CatRingZ 怎么没区别，graphql 比 rest 强太多了
|
|
53
StarkWhite 2022-07-21 20:09:25 +08:00
@Innovatino 用过 dataloader 么？
|
|
54
StarkWhite 2022-07-21 20:16:33 +08:00
@Sendya graphql 是强类型的，文档也是自动生成的，很好维护。。。
|
|
55
StarkWhite 2022-07-21 22:23:37 +08:00
@haython 比如小项目搞微服务的？
|
 |
56
bthulu 2022-07-22 08:30:51 +08:00
为啥你们就不能前端直接传 sql 到后端呢, 我们公司都这样来的, 所有查询统一一个接口, 接收前端的 sql 语句, 执行, 返回 sql 结果. 有人可能要说这样不安全, 是有点不安全, 但是这跟开发速度比起来都是可以忽略的, 安全自有公安局来负责.
|
 |
59
qshu 2022-07-25 16:26:01 +08:00
前端来讲，是更方便和简洁的，因为 apollo-client 等等 https://graphql.org/code/#javascript-client 已经很完善了，而且在 TypeScript 还有 codegen 的类型自动完成，已经用上，香的一批，可以参考我的这个开源项目，参考类型安全完成 https://github.dev/xkinput/jd-dict-client/blob/master/src/pages/index.tsx#L12-L20
|
|
60
muunala10221 OP @qshu 谢谢
|
Select Language