Question

在GraphQL域中相对较新，我目前正在尝试将现有的REST API转换为GraphQL。来自REST系统，我一直试图遵循关于GraphQL的不同哲学，以便很好地理解不同的概念。在这一点上，请问一些问题。

就我的项目而言，目前，REST API已被设计为完全动态的（使用MongoDB和Symfony）。例如，我们使用ReflectionClass来使所有内容相似，并避免了控制器中的代码重复。关于新API，它将在nodeJS环境上运行。

所以，我的问题是：您认为在设计GRAPHQL API时是否可以想象出类似的逻辑？

经过一些研究，如果我很好理解，看来该系统非常依赖于静态模式概念（.gql文件），并让最终用户定义所有查询。全局架构或原型架构会是一个好主意吗？我的意思是定义一种继承或类似的继承方式。

重点在于，在将REST API转换为新的Graphql的实施测试期间，我不得不在Graphql（.gql）中用JS中的猫鼬重新定义每个模型，并定义相关的解析器。也许我错过了某些事情或做错了什么，但是在我的解析器中，复制/粘贴了很多字段（例如，对于dbref）。此外，当我考虑维护时，如果明天我们添加一个新字段怎么办？我们是否需要在猫鼬和Graphql中明确定义它？

您是否遇到了相同的问题或找到任何解决方法？我很乐意谈论和分享它！

谢谢

个人解析器示例：

Query: {
    //single person
    async person(obj, args, context, fieldASTs) {
        if (args.id) {
            const projection = mongoose.makeProjections(fieldASTs);

             return await person.findById({
                '_id': ObjectId(args.id)
            }, projection);
         }

        return null;
    },
    // all persons
    async persons(obj, args, context, fieldASTs) {
        const projection = mongoose.makeProjections(fieldASTs);

        return await person.find({}, projection);
   }
},
person: {
    async root(obj, args, context, fieldASTs) {
        if (!obj) {
            return null;
        }

        const projection = mongoose.makeProjections(fieldASTs);

        return await Person.findById({
           '_id': ObjectId(obj.root)
        }, projection);
    }
}

graphql模式

type Person {
  id:            ID
  created:       Date
  root:          Person
  name:          String
}

type Query {
   persons: [Person]
   person(id: ID): Person
}

GraphQL动态架构

0 个答案: