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

[FR] Look for default .graphql cached schema file #4896

khalwat opened this issue Sep 7, 2019 · 0 comments


Copy link

commented Sep 7, 2019

Many editors with GraphQL plugins (PhpStorm, VS Code ) and GraphQL "playgrounds" allow you to give them a default .graphql schema file for auto-completion purposes. It's just a shortcut to having to rebuild the entire schema.

Since right now the Craft CMS GraphQL implementation doesn't build the full schema unless devMode is on, having such a default file would be useful:

        try {
            $devMode = Craft::$app->getConfig()->getGeneral()->devMode;
            $schemaDef = $gqlService->getSchemaDef($schema, $devMode);
            $result = GraphQL::executeQuery($schemaDef, $query, null, null, $variables, $operationName)
        } catch (\Throwable $e) {
            throw new GqlException('Something went wrong when processing the GraphQL query.', 0, $e);

        return $this->asJson($result);

The idea is that people could use the graphql console command to dump the schema, and then GraphiQL, various editors, etc. could then utilize it for auto-completion purposes without having to get the full schema back from Craft for the API.

In addition, support for graphql-config would be wonderful.

As @pauloelias said:

In addition to the 👍 I would also like to say this will be a huge help to our workflow since our headless CMS does not have devMode enabled. We still need to be able to test queries with the most up-to-date schema and I'd prefer not to have to fork this (now) huge database to a staging environment every time we update content models.

When we run headless we only spin up temporary review apps for each release but we don't need a long-running staging server in between releases because we don't need to worry about any frontend twig templates breaking.

Related: #4834

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.