The DDN supergraph
The supergraph allows you to declaratively model your data and user permissions across multiple different data sources.
The engine as a query compiler
The supergraph engine generates expressive APIs for the supergraph, including GraphQL and the data API. The APIs support filtering, sorting, aggregation, and joins.
This is similar to how a relational database like Postgresql generates an SQL API from a schema definition.
The API is also highly performant as the engine optimizes the query plans and parallelizes execution across multiple data sources.
Permissions are defined declaratively as well, as predicates on the data and the user session. These constraints are compiled into the query plan as filters.
Metadata definition
Nodes in the supergraph are called Models or Commands.
Models represent entities of a particular type from a data source. For example, a table from a Postgres database or a collection from a MongoDB database. Models are the preferred way to model the data API in a supergraph, as the engine can generate the most expressive and performant APIs from them.
Commands are functions that can be called to perform actions on data. They can be used to annotate individual rows or cause mutations. For example, a SQL command to insert, update or delete data in a Postgres database; or a typescript function that can perform arbitrary computation and return a value.
Relationships can be defined between Models and Commands. Joins are pushed down into database query plans where possible or executed in batches.
Permissions are defined for each Model and Command. They can also use Relationships. For example, a permission on the a Post model might be defined as post.blog.collaborators.id includes session-user-id
Putting the pieces together
The engine serves the Supergraph API (GraphQL or the data API) and is configured by the Supergraph metadata.
The engine talks to different data sources via data source specific connectors. Connectors are HTTP servers that implement the Native Data Connector (NDC) API.
For example, the Postgresql connector is configured with the connection string and database schema where each table is turned into a Model. The Typescript connector is configured with Typescript functions each of which becomes a Command.
There are connectors for Postgresql, MongoDB, MySQL, Snowflake, BigQuery, and Clickhouse; for Typescript and Python functions; and for existing GraphQL and OpenAPI APIs. And quite a few more on the Connector Hub.
A better way to build an API
Once you use DDN to build an API there’s no going back.
Simply modelling your data replaces the tedium of writing, maintaining, and optimizing layers of API code.
Declaratively defined permissions turn out to be more robust: they’re easier to understand and audit, and are guaranteed to be consistently applied for any user supplied query.
Metadata is compiled during build time, eliminating entire classes of errors.
Different teams can own different Subgraphs (parts of the Supergraph) and can work independently without coordination, Supergraph builds ensure consistency. Teams can independently deploy and rollback their own Subgraphs without risking breaking the API.
A standardised API means consumers can focus on building value on top of the API instead of learning a new API for every data source and resource. Models and Commands offer unmatched discoverability.