You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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.
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.
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
andqs
options (breaking)Related: N/A
These options are redundant as we have the
requestOptions
option. However, therequestOption
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 likeallOf
,anyOf
, andoneOf
.Low priority
Operation blocklist/allowlist
Related: #281, #340
An option that would allow you to control which API operations will be translated by OtG.
The text was updated successfully, but these errors were encountered: