最近在研究graphql
背景介绍
首先本人IOS客户端开发，目前在一款电商APP的研发小组中。随着大前端的演进，各个厂在应用开发中，都重点参与在来钱快的项目，移动端刚兴起的时候，这块是挺吃香的，随意做一款APP出来都能挣钱，但是时间到现在，泡沫碎了，现在还能存活在市面上的APP越来越少，appstore更像是一个游戏工厂，用户手上的APP基本上被几个大厂的巨型APP霸屏（支付宝，微信，大众点评，美团饿了么等等），自从小程序的兴起，移动端的市场份额又被吃去一大块，对小公司来说，做APP还不如小程序来得快。
我现在就感觉深处这份焦虑中，自己该何去何从，在自己的项目中，尤其是电商项目中，业务逻辑基本都承接在业务后端，客户端的工作说的难听点就是，后端给什么我拿出来展示就好了。领导说，我们是最接近用户的开发，但是我们还不是产品说做啥就做啥，我们认为这种交互对用户不友好，但是产品会听嘛（例如：这个后退你加挽留弹窗，用户点停留当前页变成跳转下一个页面了）。
大前端nodejs的产生应该是最好的解释，让前端同学掌握后端的开发工作。前端同学揽下更大范围的活，大声说出，我现在不是简单的写写界面了，我现在也是很关心业务逻辑的。
有个概念是BFF（Backends For Frontends服务于前端的后端），最先引入的是在前端中，具体是什么含义可以自行google，客户端是否也能引进这种思想呢，BFF主导胶水层，做到对接各后端微服务的聚合，让客户端不在重度依赖后端。GQL就能做到这点。
回到GraphQL
GraphQL是facebook在2015推出的。最开始facebook为了解决的问题是如何将web服务（News Feed）接口平滑的使用到移动应用中，而对应的一项革新技术。
国内大部分的移动应用生态其实都是独立的server端，比如APP有app-server，web有web-server，小程序有miniapp-server，最终的现象就是一份产品稿子落地三端，最后开发会写三套代码在三端各自的服务器上进行维护，相关代码逻辑相差并不是很大。
GraphQL的相关介绍文档也挺多的，我这里粘贴下
GraphQL社区
- GraphQL：一种数据查询语言 - Lee Byron
- GraphQL 和 Relay 中的订阅 - Dan Schafer and Laney Kuenzel
- 用 GraphQL 轻松 mock 你的服务器 - Jonas Helfer
- 在 GraphQL 中包装 REST API - Steven Luscher
- GraphQL 简介 - Nick Schrock
- 从 REST 到 GraphQL - Jacob Gillespie
其他文章
我讲讲我目前在项目中的推动经历
1. 调研学习
gql的社区力量HOW TO GRAPHQL，提供各项语言实现的gql教程
其中我是根据apollographql的教程学习的，Apollo Basics -> Apollo Server -> iOS，实战操作完，你就能够真正的明白什么是schema什么是resolver，gql层做了什么，以及社区强大的力量（模型图，schma开发工具）
demo运行见RAMUtil的graphql分支，README中第七点的介绍
2. 汇报调研工作
调研一周之后，在周会上提出了这个事情，领导比较反对，因为找不到这个东西的业务价值，的确，gql在现有架构中对移动端并没有多少业务价值，反而还回平添更多的工作量，最好的价值其实在后端服务里面。所以就目前周会结束之后，组内反对声音较大。
3. 继续组织落地可行性的实施计划
gql在我们供应链和小程序已经落地了，在20年4月份就已经启动开始推进了，但是主站并没有介入。现阶段主站这边有意愿去进行服务器架构，对巨无霸式的app-server进行业务模块微服务化，其中就有一个对接前端的BFF层，所以gql正好是其中的一个选型，其中客户端的首页早几年就接入了手淘的TAC-tangram的架构模型，但是两年都为继续演进了，现在也只是累赘状态中。对于后端而言他们不关心BFF层的技术选型，但是我的意见是，推动这一层的工作还得他们多出力，不然最后的工作可能还是落在他们自己身上。
- 推进压测报告尽快落地
- 寻求业务价值-在人效上的价值
node层的大促承压能力一直是一块诟病，组内对这一块的是否能够承受住大促期间的流量峰值保持质疑，所以能否继续推进，年后的完成压测报告输出比较关键