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

proposal: allow the custom template for server code generation #3375

Closed
wants to merge 5 commits into from

Conversation

OldBigBuddha
Copy link
Contributor

Overview

I have made gqlgen possible to set custom templates for the server code generation that I previously proposed at #3371.

If you set the file or directory path to the template in config as below, code generation will be performed by referring to those files rather than the templates managed by gqlgen:

# Where are all the schema files located? globs are supported eg  src/**/*.graphqls
schema:
  - graph/schema/**/*.graphqls

# Where should the generated server code go?
exec:
  filename: graph/generated/autogen.go
  package: generated
  exec_template_dir: graph/template
  # you can specify a single template file
  # exec_template: graph/template/exec.gotpl

This change allows users who want to change the core logic of the server for exceptional use cases to continue to use the original gqlgen with only custom template preparation.

I have:

  • Added tests covering the bug / feature (see testing)
  • Updated any relevant documentation (see docs)

OldBigBuddha and others added 5 commits November 14, 2024 11:55
* wip; make exec templates injectable by configuration

* wip; allow multiple template files in one directory
* allow custom template for exec codegen with follwo-schema

* exec config check

* add test for exec config check

* wip; add test for GenerateCode()

* wip; add test for follow-schema
@coveralls
Copy link

Coverage Status

coverage: 60.584% (+1.0%) from 59.549%
when pulling d6e2037 on OldBigBuddha:patch
into aaf44f5 on 99designs:master.

@StevenACoffman
Copy link
Collaborator

While this is excellent work, and is a very useful example for people who want to experiment with alternative executions, I'm going to close this PR given that we found a less invasive way to provide people with control over the trade off between memory and speed.

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

Successfully merging this pull request may close these issues.

3 participants