自从可扩展数据结构（XML、JSON、YAML...）开始大规模使用以来，消息和事件负载验证一直是一个相当棘手的问题。事实上，自DTD的美好时光以来，几乎没有取得任何进展。
Schema 语言并不新鲜，有几十种：SQL、XML Schema、json-schema、Protobuf、GraphQL……
Schema 语言关键是:完全能够表达数据模型或消息格式，但大多数不能同时表达两者，这就是问题所在：
例如，给定的数据实体可能有 5 个必填字段被认为是有效的。但是，当消息携带该实体时，它可以传达任意数量的属性。相反，属性在数据模式中可能是可选的，但在特定上下文中，消息模式可能需要该属性。您需要两组不同的语义来表达数据模型Schema和携带该数据模型实体的消息格式。
GraphQL 提供了一组独特的语义和工具，可以轻松创建Schema架构：
- Schema语言
- 一种具有“投影语义”的查询语言
- 用于注释架构或查询语言的自定义指令
- 两种语法的解析器
- 具有语法着色、验证功能的现代编辑器...
- 文档生成器
本质上，剩下要做的就是实现模式生成器，这些生成器将采用消息格式定义（如 GraphQL 查询）并生成其他模式语言，例如 Protobuf、json-schema、XML Schema 和特定语言的客户端库。
在 Nav，我们想到了使用该基础来开发我们的 Schema Architecture（它现在是一个 FOSS 项目）。它今天正在生产中使用，并且没有回头路。我们在微服务架构的所有节点上都得到了一致的验证，这是我们以前从未实现过的。当您将消息或事件定义与生成的模式和代码库进行比较时，开发收益是显著的。