hacker news 上对 graphql 的问题和讨论
https://news.ycombinator.com/item?id=32366759
摘抄了下来， 做了一点点点评。
The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system.
graphql 的查询不可控， 所以性能开销也不可控。
I'm not a fan of graphql for anything that the public could see. It's somewhat akin to exposing a SQL interface; it opens up too many avenues of trouble. Keep public communication channels as dumb as possible.
在一个domain 放了太多的东西
I worked with a team that was going down a similar path. At some point it felt like they were reinventing REST on top of GraphQL with a strict set of predefined queries and result shapes.
这听着有点像在nosql上实现 sql
自由必然伴随着代价。
Agreed - REST APIs can include a field mask or similar for sparse selection on a single entity but you'll still need several requests to fetch fields on related entities.
这是一个典型的对rest的误会了
It's also not that hard to implement attribute filtering with REST endpoints. People make a big deal about being able to control the shape of your API responses with GraphQL, but this completely achievable with standard REST APIs as well.
这个人说到点子上了。
makeitdouble:
I see GraphQL as unneeded if you already have a BFF managed by front teams.
Going with basic REST gives you simpler caching/optimisation paths, more straightforward mapping between the front request and the backend calls, and it makes it easier for other teams to look at what you’re doing and comment on/fix stuff as needed. GraphQL would be pure syntax sugar, and I’m not sure it would be worth the trade-off.
BFF + restful (RPC) 才是王道
100% agree that it’s about dependence on other teams. That said, I’d much rather that we were communicating across a well defined api boundary, rather than a graphql api. You could, of course, very easily do this with an api layer in the middle.
我的想法
帖子里面从技术以及合作的角度讨论了许多，可很少有人从组合复杂度爆炸的角度来看待问题。
在graphql 模式下， 后端需要拆分service 来提供一个个业务逻辑模块（这个是常见做法）
然后 graphql 层是个大广场，所有的service 功能都将在这边进行组合。
这个广场太大了，里面的数据可以进行任意的组合。
这里有个隐藏设定， 就是用了这个模式， 业务数据的组合就随心所欲了（自由度max）
那就要问一句： “代价是什么呢？”
这个代价是以：前端可以随意组合，但后端无法100% 控制所有组合可能出现的问题。
这点非常的致命。
这导致， graphql 合适的场景只能是内部API，在充分沟通的情况下快速输出一个可用的API。（这一点非常优秀）
对， 这个前提就是， 前端依然需要后后端保持沟通， 确保构建的查询是没有安全，或者性能问题的。
对外暴露， 依然需要以一个个独立，可控的entry 的方式，否则后端面临的就是无穷的问题的组合。
甚至可能出现，为了减少大广场组合太多导致的问题， 会将大广场收敛到满足一组业务复杂度的程度。
然后就会导致大广场分裂成多个小广场。 （这不就返回restful / rpc 多入口的场景了么）
其他聊到的一些工具
- JsonApiDotNetCore https://www.jsonapi.net/getting-started/install.html
- odata https://www.odata.org/
- PostGraphile https://www.graphile.org/postgraphile/introduction/