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

• the reusability of data structure definitions
• the expressivity of the schema language
• the developer experience

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:

• Rich validation rules
• 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.

Agenda:

• Introduction à GraphQL
• Pourquoi a-t’on besoin de valider les payloads des APIs et des Événements?
• Pourquoi ca ne marche pas avec les technologies classiques (json-schema par exemple)
• Presentation du projet Nav Schema Architecture (FOSS)

Important:
La soirée est organisée en ligne, grâce au soutien de la fondation Eclipse et notamment du projet Jakarta EE.

Pour participer, cliquer sur le bouton suivant : Participer à la visio-conférence

Programme