OpenAPI-to-GraphQL Roadmap #342
Description
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)
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
An option that would allow you to control which API operations will be translated by OtG.