摘要

从后端开发者的角度来看，GraphQL 是一个特会逼逼（N+1 Problem）、只暴露单一数据端点、提供图状数据（Graph）的数据层范式。由 Facebook 所推广的它，比起 RESTful API 有很多难写的地方。本文将简述由 GraphQL 自动生成数据库请求的一些方案，并重点介绍常用的图论数据库查询语言 Cypher 是怎么从同构的 GraphQL 中生成出来的。

loli(id: $loliId) {
  properties {
    name,
    age,
    address(edge: ":address", addressId: $addressId) {
      properties {
        line
      }
    }
  }
}

↓

MATCH (loli:LOLI {id: {loliId}}) OPTIONAL MATCH (loli)<-[:address]->(address:address {addressId: {addressId}}) RETURN *

背景

GraphQL 的好处是它能使前端声明式地请求数据，降低 SAM 模式的前端工程中，数据请求类 Action 对单一数据流的污染。由此我们知道，通过应用 GraphQL，后端可以默默帮前端承担更多的活，有利于培养男人之间的友谊。但如果长此以往，前端是不忍心的。因此为了不让前端不忍心，后端可以采取一些方案由 GraphQL 自动生成数据库请求，除了可以在项目初期减轻开发压力，也能通过避免 N+1 问题来减轻数据库的压力。

总结

对内容有任何疑问，可以加 China GraphQL User Group 群 302490951 交流。比如有同志看我以前写了篇 Relay 的教程就问我 Relay 好不好用，我都知无不言：「难用啊，所以现在我改用 ApolloStack 了」

参考文献（以下文献基本都太监了）

Naive parser from graphql to cypher query.

An optimized neo4j query resolver for Facebook’s GraphQL

A Neo4j server extension that provides a GraphQL API to Neo4j