目前GraphQL没有特别成熟的技术实现方案，Java成熟的技术方案就更少了；为了2年内也很难出现，而且java社区不是特别关注GraphQL的技术实现；
    目前实现GraphQL的技术反而是nodejs社区，尤其是随着koa和egg的web解决方案；
    egg+mongdb来实现GraphQL是目前比较推荐的技术实现方案；
    商业成功案例不是特别多，更多的是分为三层：前端层 + node（koa ， egg）中间层 + 后端接口；中间层仅仅只是作为封装层来实现；
    新技术的产生多是在特定的场景下解决某些问题，现在前后端分离而且前端开发任务越来越重，解决前端的api问题和开发效率成为关键；但是GraphQL目前概念成分多，实现成分少；

    GraphQL对团队有益处的是schema定义，整体会规范一些，时间充足可以尝试一下。同时也要注意一个问题，基于node的服务端开发中，GraphQL技术较为成熟常用，在基于java的服务端开发中，查的资料说是用的比较少，以及引入GraphQL可能需要维护两份重复数据（schema和相应java代码实现）。 从规范角度看，用程序来规范代码方向是对的，同时编码效率上要验证下，如果导致开发效率降低，就要考虑下了。

    发表下个人意见，仅供参考。我赞同@马伟 说的，软件开发没有银弹，需要结合具体场景使用。graphQL顾名思义，是基于图状数据的。如果单看商家应用核心业务，无疑是满足这一要求的：卖家，商品，买家，这都是数据顶点，而卖家和商品，商品和订单，商品和评论等，也都存在边边对应关系。这为构建graphQL提供了非常好的前提条件。但也不是所有的场景都适合graphQL，像用户登录，短信验证码等等没有任何图的概念的模块，强行将其写成graphQL没啥卵用。总之，不要为了使用graphQL而去使用graphQL，要结合具体的业务场景，系统数据结构等进行具体的分析。另外说一句，现在的Java对graphQL支持应该不大友好，我觉得这也是个巨大的挑战。如果说使用node搭建数据中间层，个人是不大推荐的。node这东西怎么说，做一些轻量的东西还行，随着业务逐渐复杂，node就捉襟见肘了，前几天还和@孙中强 讨论要不要把普云营销后台从Serverless转到Java云应用，node后台业务一复杂维护起来那是相当操心。

    graphQL目前我没有找到很权威的指导手册，上面说的是我自己的理解，再说一下我关于graphQL的思考：
    graphQL不仅仅是前端端接口对接的规范和约束，其实是一个系统工程；这要从领域模型设计开始说起；
    再需求确定正式开始之前，一定要做的事情是领域模型设计，领域模型设计本身是结构话，而架构和开发人员要做的是把结构化的数据变成关系数据库可以存储的数据；
    但是业务理解还是基于结构化的业务领域，前端和后端都是基于统一个业务领域模型，为什么前端想要结构化的数据的原因，因为直观简单，没有经过形变；而后端为什么给的数据不是业务领域的结构化数据，因为关系型数据库的制约；现在随着非关系型数据库的发展，这个问题似乎可以再特定的业务领域上部分解决；
    如果在新领域，特定范围内，设计和规划的好一些，是可以完全解决结构化问题；
    模型设计直接基于非关系型数据库实现，不用再多一步进行拆解结构变为二维数据；
    而且理解取用的时候都可以基于结构化的数据进行，前后端都是基于同一个数据结构进行沟通理解；是否非常不错；
    所以我首先想到的是如果结构化数据的优势很大，GraphQL理念也非常好，但是首先要再底层数据结构和存储上支持这种实现，上层的技术实现才能更好的搭建；
    另外一个问题是：GraphQL的字段的动态性，对静态语言以及强类型语言Java是一个极大的考验，而对动态语言和弱类型语言具有天然优势(PHP,Ruby,JS),而介于两中间的Typescript则集两者的优点，又屏蔽了其弱点；成为在语言层面实现GraphQL最佳语言选择；但是问题来了Typescript太年轻了，还没有完全成长起来；
    从struts1到struts2，再到springmvc再到springboot最终成为行业规范，这中间只是要走时间；EJB1.0 2.03.0，Hibernate，Mybaites，Jpa1.0，jpa2.0到目前国内国外两个不同的选择来看还没消停，这中间也走了10年；中间被淘汰的技术也多了去了；
    谁敢说现在的graphQL的技术实现架构用我就对了呢，目前的GraphQL还没有一个能叫的出名字的技术实现方案出来，做分析和做比较；大部分是我用什么技术实现了GraphQL，但是很难形成一套完成的体系和架构被其他公司拿来就用；估计还需要继续摸索和思考；而当前应该观察拥有数万名最聪明大脑的大厂是怎么做的，他们更聪明更有能力提出更好的方案；Facebook提出了方案，但是没有公开自己的实现；而Google，Twitter似乎更关注PWA这个技术；而最有可能为Java提供技术实现的公司我觉得是Google和Alibaba，因为他们的东西大多是Java开发的；
    —————————————————
    对java不能说不友好 只是说没有团队或个人针对其开源的框架成长起来，而且graphql也是一种理念规范而以 至于你怎么实现 你用什么语言实现 你在什么场景下使用完全是由你来决定 这个自由度很高 Apollo一直在针对graphql提供技术解决方案 我最近也在看这点 利弊都有 取舍都有 百分百完美的技术没有 看你想不想做 愿不愿意接受结果罢了 吃“螃蟹”的人总归会付出点代价
    ——————————————————-
    选择GraphQL初衷是什么？GraphQL成熟度如何？GraphQL是否有成熟文档和方案？GraphQL是否在一直在更新迭代？GraphQL是否能提高生产力？GraphQL是否能真正落地？

    如果真正想选择GraphQL，就要考虑一个过渡阶段，有一个全面的逐步替代的方案，小版本试错迭代，解决掉可能遇到的坑。

    GraphQL实际使用情况报告
    —————————————————————————————————-
    整体生态比较完整，可以方便快速的整合并使用，在使用上没有问题；

    当然在使用中也发现一下几点不足，需要其他技术团队注意：
    1：要求比较严格，必须要严格按照技术规范实施，如果出现不规范的部分就很容易报错；
    2：出错后很难定位错误，文档较少，中文文档更少，大部分都是国外node社区提供的解决方案；

    整体来说对是一个不错的技术规范，对前后端是一个很好的约束，但是提高生产力上作用不大；目前使用还比较初级，技术成熟度还需要进一步的进行提高；