Describe the bug Not able to generate Graphql Schema with openapi-to-graphql cli using Stripe's API OAS definition

To Reproduce Steps to reproduce the behavior:

1. install the openapi-to-graphql-cli
2. try generating schema by running: openapi-to-graphql https://api.apis.guru/v2/specs/stripe.com/2019-03-14/swagger.json

Expected behavior The graphql server starts with generated Stripe API schema

Actual result Getting the following error:

openapi-to-graphql https://api.apis.guru/v2/specs/stripe.com/2019-03-14/swagger.json(node:54348) ExperimentalWarning: The http2 module is an experimental API.
OpenAPI-to-GraphQL creation event error:  Cannot read property 'schema' of null

Additional context Up to date latest OAS Stripe's spec can be grabbed here: https://github.com/stripe/openapi/blob/master/openapi/spec3.json *same generation result as described above

After reading #80, here is a proposal on a way to handle callbacks and create corresponding subscription fields.

There is only one test for now, i would like your feedback to know if you agree with the choices made, before expanding test phases.

Signed-off-by: Edouard Maleix [email protected]

A simple question:

Openapi-to-Graphql sees some of the endpoints as mutations. However, these are not really mutations, they are queries. All these require a POST request to be sent instead of a GET, since they have several parameters and it's easier to transmit those in the request body.

Can I make Openapi-to-Graphql to handle these as Queries? Do I have to edit the generated GraphQL schema manually to achieve this?

Hi there 👋

First of all, thanks for the awesome library. We've been using it at @apideck-io with great success!

Recently we forked the repo because we needed granular control over the naming of certain schemas/operations. It's not always possible to use title fields or similar, since we have other tooling using those as well. We needed a way to customise naming specifically for GraphQL.

We came up with a solution using OpenAPI extensions. We think it could be useful to other users of openapi-to-graphql so we're contributing it back 🎉

Let me know if you're interested in having something like this, otherwise we'll keep it in our fork :smile:

Here's an API spec I used for testing: https://gist.github.com/elsmr/ac35f5dc7dbf7a42e60276f688955640. I also included the graphql schema output before & after.

There's also more features that could be added using this approach, for example a property whitelist for schemas etc.

Cheers

Hi! We have a problem about auto parsing snake_case to camelCase of schema fields. How we can disable this? We have fields of model for example "target_id" and don't want to parse to "targetId".

The same problem occurs when the reponse is JSON graphql type: {"DATA1": "something"}

parsed to:

{"dATA1": "something"}

Thanks

For http://v4.loopback.io/getting-started-oasgraph.html some things should be changed.

As per a user comment (https://github.com/strongloop/loopback-next/issues/1762), for git clone it's more preferable to use the https link instead of the ssh link.

That would be a short term thing. As per https://github.com/strongloop/v4.loopback.io/issues/43 the Developer Experience of having to link a dependency is very poor. It's much more preferable to have the following:

npm i -g oasgraph
oasgraph ./openapi.json

and for production a user can install the dependency via package.json and build out a npm script as follows:

start: ./node_modules/oasgraph ./openapi.json

And then be able to run npm start

Lastly the getting started page is very all over the place and not a good guide to "get started" as it currently stands as it assumes a user has an app already.

A much better Getting Started would be to say that lets build on LoopBack's Getting Started ... or add a step to clone a project from LoopBack 4 as follows:

npm i -g @loopback/cli
lb4 example todo
cd example todo // You can even point to LB Documentation for this but it's better if it's all on 1 page. 
npm i oasgraph // After this is available via npm
npm start
// Visit /openapi.json and save to disk at './openapi.json' --> Maybe we can provide a script to pull it from server and save to disk?
Ctrl+C
// Add a command to package.json as follows:
> start:oasgraph: "./node_modules/oasgraph ./openapi.json"
npm run start:oasgraph
// Visit GraphQL Link

Hello guys,

The test/example_api.test.js is currently broken on master. Stack (npm run test):

`● Link parameters as constants and variables with request payload

expect(received).toEqual(expected)

Difference:

- Expected
+ Received

  Object {
-   "data": Object {
-     "postScanner": Object {
-       "body": "req.body: body, req.query.query: query, req.path.path: path",
-       "everythingLink2": Object {
-         "body": "http://localhost:3002/api/scanner/path_post_200_body_query_path_application/json_req.body: body, req.query.query: query, req.path.path: path_query_path_close",
-       },
-     },
-   },
+   "errors": Array [
+     [GraphQLError: Cannot query field "everythingLink2" on type "Scanner". Did you mean "everythingLink"?],
+   ],
  }

  286 |   }`
  287 |   return graphql(createdSchema, query).then(result => {
> 288 |     expect(result).toEqual({
      |                    ^
  289 |       data: {
  290 |         "postScanner": {
  291 |           "body": "req.body: body, req.query.query: query, req.path.path: path",

  at toEqual (test/example_api.test.js:288:20)

`

I recently reported in issue #92 that I now no longer produce an OAS in Swagger 2.0 format but now produce one in OpenApi 3.0.1 format. :

swagger.txt

Even though I seem to get better results with that, the results are still somewhat disappointing when using OASGraph to generate the schema and trying to use the generated OAS in GraphiQL.

The following problems still occur:

1. SearchOrders (and possibly others) is missing from the schema and docs even though it's in the Swagger.json file.

2. Also, as mentioned in issue #107 how can I get the docs to present the schema in alphabetical order?

Hi,

Im trying to use openapi-to-graphql to convert this OAS to graphql -https://app.swaggerhub.com/apis/OpenChannel/Market-API/2.0.25

I've download the schema and I'm using this command to process it:

openapi-to-graphql OpenChannel-Market-API-2.0.25-resolved.yaml

However, I'm getting multiple warnings as follows:

"warnings": [
    {
      "type": "MISSING_RESPONSE_SCHEMA",
      "message": "Operation GET /apps has no (valid) response schema. You can use the fillEmptyResponses option to create a placeholder schema",
      "mitigation": "Ignore operation."
    },
    {
      "type": "MISSING_RESPONSE_SCHEMA",
      "message": "Operation POST /apps has no (valid) response schema. You can use the fillEmptyResponses option to create a placeholder schema",
      "mitigation": "Ignore operation."
    },
    {
      "type": "MISSING_RESPONSE_SCHEMA",
      "message": "Operation GET /apps/{appId} has no (valid) response schema. You can use the fillEmptyResponses option to create a placeholder schema",
      "mitigation": "Ignore operation."
    } .......

,
  "numOps": 86,
  "numOpsQuery": 34,
  "numOpsMutation": 52,
  "numOpsSubscription": 0,
  "numQueriesCreated": 0,
  "numMutationsCreated": 0,
  "numSubscriptionsCreated": 0

I think the problem is related to the sections of the OAS file that look like this:

"responses": {
          "400": {
            "description": "Bad Request - Required parameters are missing, malformed or invalid"
          },
          "default": {
            "description": "OK",
            "schema": {
              "$ref": "#/definitions/AppPages"
            }
          }
        }
      },

i.e. the $ref statement and it not linking to the definitions section.

Is there anything I can do to resolve this ?

selectQueryOrMutationField: override the GQL type (mutation or query) of any operation. PR contains the logic, types etc.

Tests and docs are yet to be added.

Describe the bug We have POST and Delete operations that do not return any JSON responses and hence we do not define any response schema in the v2 OAS file in these particular cases. This causes warning in the console when we try to generate the wrapper using OASGraph.

"warnings": [ { "type": "MissingResponseSchema", "message": "Operation 'POST /v1/persons/{concern_role_id}/special_cautions' has no (valid) response schema. You can create placeholder schemas using the fillEmptyResponses option.", "mitigation": "Ignore operation" }, { "type": "MissingResponseSchema", "message": "Operation 'DELETE /v1/persons/{concern_role_id}/special_cautions/{special_caution_id}' has no (valid) response schema. You can create placeholder schemas using the fillEmptyResponses option.", "mitigation": "Ignore operation" }, { "type": "MissingResponseSchema", "message": "Operation 'POST /v1/outcome_plans/{outcome_plan_id}/attachments' has no (valid) response schema. You can create placeholder schemas using the fillEmptyResponses option.", "mitigation": "Ignore operation" },

............

I have tried setting the option "fillEmptyResponses: true" and this does substantially reduce the number of warnings especially Delete operations, but some still remain.

"warnings": [ { "type": "MissingResponseSchema", "message": "Operation 'POST /v1/persons/{concern_role_id}/special_cautions' has no (valid) response schema. You can create placeholder schemas using the fillEmptyResponses option.", "mitigation": "Ignore operation" }, { "type": "MissingResponseSchema", "message": "Operation 'POST /v1/outcome_plans/{outcome_plan_id}/attachments' has no (valid) response schema. You can create placeholder schemas using the fillEmptyResponses option.", "mitigation": "Ignore operation" },

........

Expected behavior Setting the option to fill empty responses should fill all REST resources with empty responses

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

Describe the bug Based on https://swagger.io/docs/specification/describing-responses/ (Empty Response Body) the definition for 204 should look like this:

{
  ...,
  "paths": {
    "/tests": {
      "get": {
        "tags": [
          "test-controller"
        ],
        "operationId": "getTests",
        "parameters": [...],
        "responses": {
          "200": {
            "description": "OK",
            "content": {
              "application/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "$ref": "#/components/schemas/Test"
                  }
                }
              }
            }
          },
          "204": {
            "description": "Empty list"
          },
          "502": {
            "description": "Invalid Response",
            "content": {
              "application/json": {}
            }
          },
          "504": {
            "description": "No Response",
            "content": {
              "application/json": {}
            }
          }
        }
      }
    }
  },
  ...
}

But in that case I get the following error:

{
  "data": null,
  "errors": [
    {
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
      },
      "locations": [
        {
          "column": 17,
          "line": 1
        }
      ],
      "message": "Response does not have a Content-Type header",
      "path": [
        "tests"
      ]
    }
  ]
}

There's indeed no Content-Type header since there's no Content.

To Reproduce Steps to reproduce the behavior: See above

Expected behavior No error should occur

https://medium.com/the-marcy-lab-school/what-is-the-n-1-problem-in-graphql-dd4921cb3c1a

I am trying to use nest object feature and it work well，but if we use it in list query, N +1 problem comes. Is there any way to solve the N + 1 problem when I use Nest Object?

Because in js typeof null === 'object' we need additional check, otherwise Object.entries(args[saneParamName]) will fail with:

TypeError: Cannot convert undefined or null to object

Describe the bug We're trying to expose a UK gov API with the following spec: https://api.publish-teacher-training-courses.service.gov.uk/api-docs/public_v1/api_spec.json

Unfortunately, they decided to implement it using the content type application/vnd.api+json.

Currently, the resolver code in this project is only ever treating application/json as a first-class citizen; after changing the spec to have a content type of application/vnd.api+json, the number of entries that appear in the query section reduce signficantly. Please start treating application/vnd.api+json and application/json as synonyms.

To Reproduce Steps to reproduce the behavior:

1. Download this file
2. Globally Replace 'float' with number, and save it as file spec.json
3. create the following index.js app:

const express = require('express')
const {graphqlHTTP} = require('express-graphql')
const {createGraphQLSchema} = require('openapi-to-graphql')
const oas = require('./spec.json');

async function main(oas) {
  // generate schema:
  const {schema, report} = await createGraphQLSchema(oas, {
    strict: false
  })

  // server schema:
  const app = express()
  app.use(
    '/graphql',
    graphqlHTTP({
      schema,
      graphiql: true,


    })
  )
  app.listen(3001)
}

main(oas)

4. create the following package.json file:

{
  "name": "gql",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.18.2",
    "express-graphql": "^0.12.0",
    "graphql": "^15.8.0",
    "openapi-to-graphql": "^2.6.3"
  }
}

5. Run the following:

npm install 
node index.js

6. Point a browser to http://localhost:3001/graphql
7. Run the following Query:

query{
  courseLocationListResponse (courseCode:"2N22",providerCode:"B20", year:"2020"){
    jsonapi{
      version
    }
  }
}

The response we get is the following:

{
  "errors": [
    {
      "message": "Operation GET /recruitment_cycles/{year}/providers/{provider_code}/courses/{course_code}/locations should have a content-type 'application/json' but has 'application/vnd.api+json' instead",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "courseLocationListResponse"
      ]
    }
  ],
  "data": {
    "courseLocationListResponse": null
  }
}

Expected behavior I'd expect the app to understand that application/json and application/vnd.api+json are compatible, and return the correct results.

Screenshots N/A.

Additional context Changing the spec.json file to use ''application/vnd.api+json" instead of "application/json" causes erratic behaviour, as the API does not understand this mime type.

The issue is likely to be resolved by loosening the if statement here to also treat ''application/vnd.api+json" in the same way: https://github.com/IBM/openapi-to-graphql/blob/master/packages/openapi-to-graphql/src/resolver_builder.ts#L809

Describe the bug Queries with query parameters that are array based doesn't work.

It boils down to this line: https://github.com/IBM/openapi-to-graphql/blob/89515187ed664370a9bbc1cd58f843412d20741c/packages/openapi-to-graphql/src/resolver_builder.ts#L1374

An array is also considered an object in JavaScript. The if statement needs to be flipped.