Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for graphql mutation #231

Open
Ali-iotechsys opened this issue Nov 10, 2022 · 7 comments
Open

add support for graphql mutation #231

Ali-iotechsys opened this issue Nov 10, 2022 · 7 comments

Comments

@Ali-iotechsys
Copy link

Hello, thank you for providing this tool.
I have tried to generate api from graphql query and mutation, the example is available: link. I have found the tool currently generates api from graphql mutation rendered as GET endpoints, not as POST (or PATCH) as expected. I understand the tool currently can only support geaphql query. It would be nice feature to have mutations supported too. Thanks again for your contribution.

@schwer
Copy link
Owner

schwer commented Nov 14, 2022

Do you have an example schema, mutation and expected openapi output?

@Ali-iotechsys
Copy link
Author

Thanks for getting back to me.
Yes I have example schema and query file (included few mutations):
https://github.com/Ali-iotechsys/graphql-to-openapi/tree/dockerise-branch/example

Also, I have added an expected api file in the same directory.

@schwer
Copy link
Owner

schwer commented Nov 17, 2022

Good news: this the only issue in the queue.
Bad news: I cannot make any guarantee around completion time estimate 😄 .

@Ali-iotechsys
Copy link
Author

No worries at all, thanks :)

@kolypto
Copy link

kolypto commented Mar 29, 2023

In fact, it almost works :)

The schema, with a Query and a Mutation:

type Query {
  getUser(id: ID!): User!
}

type Mutation {
  saveUser(user: UserInput!): ID
}

type User {
  id: ID!
  name: String!
}

input UserInput {
  name: String!
}

And the queries:

query getUser ($id: ID!) {
  user: getUser(id: $id) { id }
}

mutation saveUser ($user: UserInput!) {
  userId: saveUser(user: $user)
}

Produce the following OpenAPI spec:

#...
paths:
  # query getUser(...)
  /getUser:
    get:
      parameters:
        - name: id  # arguments: ($id: ID!)
          in: query
          required: true
          schema:
            type: string
      responses:
        "200":
          description: response
          content:
            application/json:
              schema:
                type: object
                properties:
                  user:  # Response field. Renamed.
                    nullable: false
                    properties:
                      id:  # Response field
                        type: string
                        nullable: false
                    type: object
  # mutation: saveUser
  /saveUser:
    get:   # GET method. Should be POST
      parameters:  # arguments. In query. Should be in POST body
        - name: user
          in: query
          required: true
          schema:
            type: object
            properties:
              name:
                type: string
                nullable: false

      responses:
        "200":
          description: response
          content:
            application/json:
              schema:
                type: object
                properties:
                  userId:  # response field, renamed
                    type: string
                    nullable: true

It works. With two small issues:

  • the mutation should be a POST :)
  • the parameters should go into the POST body

@Ali-iotechsys
Copy link
Author

Ali-iotechsys commented Mar 29, 2023

Mutations in GraphQL can be add/remove/update operations, the issue (I think) is how to guide the code generation to generate the correct REST API verbs (POST/DELETE/UPDATE or PATCH)?

@schwer
Copy link
Owner

schwer commented Apr 2, 2023

So it's not always obvious whether a mutation should be a POST, PUT or DELETE. One option is to allow the parser to use annotations/directives in the graphql schema (prefixed by@ I think), to indicate the desired method name. Or perhaps a convention in the naming of the operations could be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants