OpenAPI-to-GraphQL Roadmap

[Alan-Cha]

OpenAPI-to-GraphQL Roadmap

To give more insight into the direction that we want to take OpenAPI-to-GraphQL and to encourage users to help contribute to our project and even become maintainers, we have compiled a number of issues that we would like to bring to the attention of our community.

We encourage users to actively partake in discussion, suggest other issues that should be highlighted, and to provide suggestions on how we should approach these issues.

High priority

Increase usage of information provided in an OpenAPI document

Related: #312

The OpenAPI specification allows to define a plethora of information on how exactly requests to an API should be made, for example when it comes to formatting the request body, complex URL parameters, or headers. We strive to tetach OtG to make use of as much of this information as possible to make generated resolver functions work out-of-the-box in more cases, and to make generated GraphQL schemas better reflect the exposed API.

Backwards compatibility

Related: #335

Generate data that can be consumed in order to ensure the generated GraphQL interface is consistent across different versions of OtG, e.g. mapping from schema to type name.

Expose more translation data

Related: #303

Provide more data about how the OAS is translated into the GraphQL interface.

Contextual sanitization

Related: #274

Currently, we put all sanitized/desanitized mappings into the same object. This can lead to conflicts. For example, field name mappings should be kept on a type to type basis, instead of storing all the mappings together.

Remove dependency for "request" module (breaking)

Related: #315, #268

The request module has been deprecated since Feb 2020 and an alternative should be used.

Deprecate headers and qs options (breaking)

Related: N/A

These options are redundant as we have the requestOptions option. However, the requestOption is related to the request module, which is deprecated.

Medium priority

Externalize OAS validation and translation

Related: #334

We currently use oas-kit to translate Swagger to OAS and to validate OASs. Translating / validating an OpenAPI Document can easily be done outside of OtG. This allows users to skip this operation if they don't need it, and removes dependencies from OtG.

Improve type identification

Related: #330

The function getSchemaTargetGraphQLType() should fail to account for JSON schema combining keywords like allOf, anyOf, and oneOf.

Low priority

Operation blocklist/allowlist

Related: #281, #340

An option that would allow you to control which API operations will be translated by OtG.