1.7.4 迁移到GraphQL的代价

对于已存在的大型系统从REST等架构迁移到GraphQL，需要慎重考虑，这不会是一个小改动就能完成的。至于会具体带来多少后端开发工作量的问题，分以下几点来讨论。

（1）一般不需要为GraphQL换语言。GraphQL各语言实现的进展非常快，现在至少有十几种主流语言支持GraphQL，也就是说常用的语言基本都支持，这个速度是非常惊人的，一般的技术需要好多年才能覆盖这么多语言。

（2）不需要为GraphQL换框架。GraphQL和框架无关，各种主流Web框架，无论是Django，Rails还是Express，哪怕是Spring MVC，Play Framework，Finatra都不会和GraphQL冲突。

（3）可以让GraphQL和RESTful服务共存。如果服务是一个单一的大型RESTful服务，可以把GraphQL直接连接到已有的RESTful项目上。这样做的好处是可以重用已经实现的业务逻辑代码、数据库和Cache访问代码。只需为GraphQL加一两个Endpoint就行了。这样还有一个好处，就是可以让GraphQL和已存在的RESTful API并行一段时间，让升级更加平滑。

（4）可以让GraphQL和微服务集群共存。如果服务已经很好地使用了微服务的构架，也不需要重写已存在的微服务，可以用GraphQL挡在所有后端服务前面来自由拼装已存在的微服务。这样做既可以为后端微服务提供保护，让前端和后端微服务一定程度上解耦，还不损失灵活性。

（5）可能还需要额外考虑GraphQL的后端优化问题，尤其是优化GraphQL对数据库以及缓存的访问。不过GraphQL的优化办法更多，毕竟是一个单一的访问请求，都共享一个单一的Context对象，可以从全局出发进行优化，优化的效果会更好。而RESTful API会产生多次请求（多次请求本身就是一个不小的问题），这些请求很可能分发到不同的服务器，即便在同一个服务器也很难控制它们到达的先后顺序。这些不确定性，都会造成RESTful API优化的困难。