graphql-engine/dc-agents/reference
David Overton 346804fc67 Support nested object fields in DC API and use this to implement nest…
## Description

This change adds support for nested object fields in HGE IR and Schema Cache, the Data Connectors backend and API, and the MongoDB agent.

### Data Connector API changes

- The `/schema` endpoint response now includes an optional set of GraphQL type definitions. Table column types can refer to these definitions by name.
- Queries can now include a new field type `object` which contains a column name and a nested query. This allows querying into a nested object within a field.

### MongoDB agent changes

- Add support for querying into nested documents using the new `object` field type.

### HGE changes

- The `Backend` type class has a new type family `XNestedObjects b` which controls whether or not a backend supports querying into nested objects. This is currently enabled only for the `DataConnector` backend.
- For backends that support nested objects, the `FieldInfo` type gets a new constructor `FINestedObject`, and the `AnnFieldG` type gets a new constructor `AFNestedObject`.
- If the DC `/schema` endpoint returns any custom GraphQL type definitions they are stored in the `TableInfo` for each table in the source.
- During schema cache building, the function `addNonColumnFields` will check whether any column types match custom GraphQL object types stored in the `TableInfo`. If so, they are converted into `FINestedObject` instead of `FIColumn` in the `FieldInfoMap`.
- When building the `FieldParser`s from `FieldInfo` (function `fieldSelection`) any `FINestedObject` fields are converted into nested object parsers returning `AFNestedObject`.
- The `DataConnector` query planner converts `AFNestedObject` fields into `object` field types in the query sent to the agent.

## Limitations

### HGE not yet implemented:
- Support for nested arrays
- Support for nested objects/arrays in mutations
- Support for nested objects/arrays in order-by
- Support for filters (`where`) in nested objects/arrays
- Support for adding custom GraphQL types via track table metadata API
- Support for interface and union types
- Tests for nested objects

### Mongo agent not yet implemented:

- Generate nested object types from validation schema
- Support for aggregates
- Support for order-by
- Configure agent port
- Build agent in CI
- Agent tests for nested objects and MongoDB agent

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7844
GitOrigin-RevId: aec9ec1e4216293286a68f9b1af6f3f5317db423
2023-04-11 01:30:37 +00:00
..
src Support nested object fields in DC API and use this to implement nest… 2023-04-11 01:30:37 +00:00
.gitignore Replace Haskell DC Reference Agent with TypeScript DC Reference Agent in HSpec tests 2022-06-23 08:09:46 +00:00
.nvmrc Move Typescript types for Data Connector agent into their own package 2022-09-05 06:09:23 +00:00
Dockerfile Replace Haskell DC Reference Agent with TypeScript DC Reference Agent in HSpec tests 2022-06-23 08:09:46 +00:00
package-lock.json Support nested object fields in DC API and use this to implement nest… 2023-04-11 01:30:37 +00:00
package.json Support nested object fields in DC API and use this to implement nest… 2023-04-11 01:30:37 +00:00
README.md Implemented datasets support in Data Connector agent test suite 2023-01-30 07:00:26 +00:00
tsconfig.json Replace Haskell DC Reference Agent with TypeScript DC Reference Agent in HSpec tests 2022-06-23 08:09:46 +00:00

Data Connector Agent Reference Implementation

This directory contains a barebones implementation of the Data Connector agent specification which fetches its data from static JSON files. It can be used as a reference implementation for testing, and as a reference for developers working on backend services.

Requirements

  • NodeJS 16

Build & Run

> npm install
> npm start

Docker Build & Run

> docker build . -t dc-reference-agent:latest
> docker run -it --rm -p 8100:8100 dc-reference-agent:latest

Dataset

The dataset exposed by the reference agent is sourced from https://github.com/lerocha/chinook-database/

More specifically, the Chinook.xml.gz file is a GZipped version of https://raw.githubusercontent.com/lerocha/chinook-database/ce27c48d9f375f81b7b68bacdfddf3c4458acc49/ChinookDatabase/DataSources/_Xml/ChinookData.xml

The schema-tables.json is manually derived from the schema of the data as can be seen from the CREATE TABLE etc DML statements in the various per-database-vendor SQL scripts that can be found in /ChinookDatabase/DataSources in that repo.

The datasets can be operated on via the /datasets resources as described in dc-agents/README.md.

Configuration

The reference agent supports some configuration properties that can be set via the value property of configuration on a source in Hasura metadata. The configuration is passed to the agent on each request via the X-Hasura-DataConnector-Config header.

The configuration that the reference agent can take supports two properties:

  • tables: This is a list of table names that should be exposed by the agent. If omitted all Chinook dataset tables are exposed. If specified, it filters all available table names by the specified list.
  • schema: If specified, this places all the tables within a schema of the specified name. For example, if schema is set to my_schema, all table names will be namespaced under my_schema, for example ["my_schema","Album"]. If not specified, then tables are not namespaced, for example ["Album"].

Here's an example configuration that only exposes the Artist and Album tables, and namespaces them under my_schema:

{
  "tables": ["Artist", "Album"],
  "schema": "my_schema"
}

Here's an example configuration that exposes all tables, un-namespaced:

{}