Skip to content

Removing a ParseGraphQLConfiguration does cause server to return to default settings #6941

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

Closed
4 tasks done
185driver opened this issue Oct 13, 2020 · 4 comments · Fixed by parse-community/docs#772
Closed
4 tasks done
Labels
type:docs Only change in the docs or README

Comments

@185driver
Copy link

New Issue Checklist

Issue Description

If a change is made to a ParseGraphQLConfiguration using setGraphQLConfig(), and then the change is removed, the original (default) ParseGraphQLConfiguration does not return automatically. It must be reset by the developer.

Steps to reproduce

  1. Create a Parse Server instance and add a custom graphQLConfig similar to the example below.
  2. Note that the GraphQL Playground Docs tab shows that the get and find query aliases for the Item class are in use.
  3. Remove the custom graphQLConfig related code from the Parse Server instance and refresh the GraphQL Playground page.
  4. Note that the GraphQL Playground Docs tab continues to show that the get and find query aliases for the Item class are in use.
  5. Instead of removing the graphQLConfig related code as mentioned in step #3, change it to this (forces a reset of the previously-changed configuration settings):
const graphQLConfig = {
  classConfigs: [],
};
  1. Note that the GraphQL Playground Docs tab now show that the get and find queries for the Item class has returned to the default item and items query names, respectively.

Parse Server Instance Example:

const parseServer = new ParseServer({
  databaseURI: 'mongodb://localhost:27017/test',
  appId: 'APPLICATION_ID',
  masterKey: 'MASTER_KEY',
  serverURL: 'http://localhost:1337/parse',
});

const parseGraphQLServer = new ParseGraphQLServer(
  parseServer,
  {
    graphQLPath: '/graphql',
    playgroundPath: '/playground'
  },
);

const graphQLConfig = {
  classConfigs: [
    {
      className: 'Item',
      query: {
        getAlias: 'getItem',
        findAlias: 'findItems',
      },
    },
  ],
};

const setParseGraphQLConfig = async () => {
  await parseGraphQLServer.setGraphQLConfig(graphQLConfig);
};

setParseGraphQLConfig();

app.use('/parse', parseServer.app);
parseGraphQLServer.applyGraphQL(app);

Actual Outcome

The graphQLConfig settings do not automatically return to their default settings after removing custom changes.

Expected Outcome

The graphQLConfig settings should revert to their default settings automatically if no custom changes are applied.

Environment

Server

  • Parse Server version: 4.3.0
  • Operating system: Windows 10
  • Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): localhost

Database

  • System (MongoDB or Postgres): MongoDB
  • Database version: 4.2.8
  • Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): MongoDB Atlas

Client

  • SDK (iOS, Android, JavaScript, PHP, Unity, etc): GraphQL
  • SDK version: N/A

Logs

@davimacedo
Copy link
Member

It happens because setGraphQLConfig actually persists the configuration into the database. We plan to add to Parse Dashboard the capability of managing this configuration.

@185driver
Copy link
Author

Copy that, thank you. It felt like unexpected behavior to me, so I wanted to raise the issue. If instead it is expected behavior and won't be changed, I could submit a minor documentation mention of the behavior to the GraphQL guide if you thought that would be helpful. Otherwise, I can close this issue (or you can) if no action is planned or needed.

@davimacedo
Copy link
Member

Sure. It will be a good addition to the docs.

@davimacedo davimacedo added the type:docs Only change in the docs or README label Oct 13, 2020
@185driver
Copy link
Author

Oops, I used the wrong issue number in my PR so I'll just close this manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:docs Only change in the docs or README
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants