最近想尝试用 GraphQL 写一些接口，于是就有同学提出，GraphQL 不是属于后端的吗，为什么要前端去写？而后端则认为，前端离业务更近，应该前端去写。
我们先来讨论谁离业务更近的问题
前端后端谁离业务更近？
前后端的关系可以大概这么划分
举两个例子
- 列表页面
交互部分：需要展示什么字段
底层逻辑： 需要存储哪些字段
- 成员邀请功能
交互部分：通过手机号还是邮箱邀请？需要做哪些格式限制？
底层逻辑：如果是手机号邀请，能否创建相应的数据记录
结论
前端离交互更近，后端离底层逻辑更近。不管是交互还是底层逻辑，都属于业务的一部分。所以并不存在谁离业务更近的问题
主要争议
接口的业务逻辑放在前端还是后端？
推导过程如下
问：哪一类接口存在这种争议？
答：一般是信息查询类的接口
问：查询类接口离交互更近，还是离底层逻辑更近？
答：离交互更近，如果没有用户界面，根本就不需要这类接口
结论
所以我认为，很多接口需求是为前端交互服务的，前端长啥样当然前端更清楚，所以条件允许的话前端自己写这部分接口能减少沟通成本。 离谁更近，由谁去开发效率更高
这样做的好处是
- 后端不需要关注“交互”部分。前后端除了都要了解通用业务逻辑以外，各自有自己关注的侧重点。减少团队内没必要的重复阅读文档的时间
- “交互”部分更改频繁，一般情况下只需前端就能搞定，无需每次带上前后端
- 接口定义上减少前后端的沟通成本
