基于GraphQL的数据网关实现

本文探讨了在项目背景中使用GraphQL作为数据查询协议的优势和痛点,如实体唯一命名和schema管理问题。通过集成Apollo配置管理平台,实现了动态加载schema,解决了版本更新问题。数据网关提供统一的数据查询协议和接口调用,支持权限管理,降低了维护成本。
摘要由CSDN通过智能技术生成

项目背景

后端开发经常会面临的一个问题是数据存储,和数据管理。不论你是用的mysql,oracle,cassandra,postgres,mongo等等,要查询这些数据存储介质必须为每一个数据源开发或者集成相对应的中间件。而随着我们的项目增多,或者存储介质的迁移变动时,我们不得不面临代码重构,甚至重做的问题,这其间会产生大量的时间成本和人力成本。GraphQL正是在这种背景下诞生的,它定义了一套schema查询语法,可以很直观的展现数据层级,有着强类型校验,也有着弱类型扩展。它本身只是定义客户端与数据源之间存取数据的协议,通过协议转换最终访问数据存储介质。

GraphQL使用痛点

使用GraphQL来处理数据查询能给我们的项目管理和迭代功能上带来诸多便利,但真正使用起来确实存在一些痛点,主要有以下几个方面:

  1. 实体唯一命名。实体在我们数据存储场景下的定义一般都是表结构,通用场景下,一个数据库包含多张表,那多个数据库之间表名可能会有重名情况。那有人就要说了可以数据库名+表名来唯一命名。但是如果是多个数据库集群呢,连接名称+数据库名+表名才能定义唯一实体。(可能有人会反驳了,那我们可以定义多个环境分别访问后端存储。如果有需求是将测试环境数据迁移至线上环境呢)
  2. schema管理,包括分组,动态加载。如上1所诉,我们定义好了唯一实体,那自然会涉及到schema的分组,和动态加载,这些问题不解决,只要有字段删减或者重命名,就需要重新发版本来同步更新配置
  3. Query,Mutate语法,在编程方面没有JSON格式便利。字符串拼接也可以解决,但要用这种方式来应用对项目代码管理来说将是灾难。

数据网关功能点描述

  1. 统一的数据查询协议,客户端只集成一套数据协议即可访问任何数据存储介质。
  2. 统一的接口调用。REST API 或者 RPC
  3. 区分项目访问数据的权限。
  4. 通过Apollo命名空间管理配置,并能自动加载schema,无需手动发版本更新

Schema配置管理

Apollo配置管理平台集成

通过springboot集成apollo,利用通知回调机制动态加载更新配置,无需重启在线服务。具体集成方案,参考如下链接
Apollo: link.

namespace命名规则和配置样例

  1. 命名规则: [连接名称]+[环境名称(dev/sandbox/online)].yaml
  2. 协议配置
protocols:
    mutation:
        createIndex: 
            params:
                - param: fields
                  type: TABLEDEFINITION
                  required: true
                - param: options
                  type: JSON
                  required: true
            ret: mutationRet
        insert: 
            params:
                - param: fields
                  type: TABLEDEFINITION
                  required: 
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值