Regardless of the schema language, there are three key problems in a schema architecture:

the reusability of data structure definitions

Nav is a Small Business Lending platform built on a polyglot microservice architecture, complemented by an event bus. It is essential for us to develop a consistent way to validate our message payloads (APIs and events) across all microservices. Considering that it has one of the best DevX in the industry, we got the idea to use GraphQL as a schema language without any runtime component. After all, a GraphQL query describes the payload requested by a client, so why not use the same syntax to create a message definition and generate client-side and server-side validation code?

Nav’s Schema Architecture has been used in production since last September and we can already see some of the key benefits:

A consistent set of validation rules regardless of the language (Golang, Python, Ruby and JSON-schema).

An intuitive DevX that allows us to onboard engineers very quickly

A communication mechanism that conveys easily and precisely reusable data types across all payloads

A massive productivity gain with a 10-20X compression factor between the payload definition and the amount of generated code

These benefits proved to be very useful in the implementation of our event-driven architecture. We are now using for gRPC and protobuf as well.

A GraphQL-based Schema Architecture for Microservices