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

[compiler] Add GraphQL AST to Apollo Compiler Plugins #5709

Closed
martinbonnin opened this issue Mar 12, 2024 · 4 comments
Closed

[compiler] Add GraphQL AST to Apollo Compiler Plugins #5709

martinbonnin opened this issue Mar 12, 2024 · 4 comments

Comments

@martinbonnin
Copy link
Contributor

Description

Would be nice to expose the GraphQL AST to Plugin so that users could generate side data without having to parse the schema/operations twice

KotlinLang slack thread: https://slack-chats.kotlinlang.org/t/16651498/i-got-a-type-like-type-flow-id-id-currentstep-flowstep-progr#5519cac4-ca54-4d20-a7c4-16c52cd39871

@martinbonnin
Copy link
Contributor Author

@StylianosGakis I gave a shot as generating visitors for all Flow fields here: https://github.com/martinbonnin/log-current-step

Call ./gradlew build, which will run in order:

  • addGraphQLFields: adds the flowStep fragment automatically to every field of Flow type
  • generateVisitors: generate a GeneratedVisitors.kt file with code that can visit all the fields of Flow type for a given operation Name:
public fun interface Visitor {
  public fun visit(`data`: Any?, block: (FlowStep) -> Unit)
}

public val generatedVisitors: Map<String, Visitor> = mapOf(
      "getFlow" to Visitor { data, block ->
        data as GetFlowQuery.Data
        data.flowClaimBarNext.cast<FlowStep>().maybe(block)
      },
      "getNestedFlow" to Visitor { data, block ->
        data as GetNestedFlowQuery.Data
        data.nested?.flows?.forEach {
          it?.cast<FlowStep>().maybe(block)
        }
      },
    )
  • generateServiceApolloSources: to also generate the Apollo sources

TBH, it's quite the setup to avoid a bunch of manual boilerplate (related xkcd). Depending the size of your schema, it might or might not worth it. My guess is unless you have a huge schema and a large number of operations, it's not worth it.

@StylianosGakis
Copy link
Contributor

Wow thanks a lot for taking the time to show me how this can be done.
I will just be honest with you and admit that this is definitely quite a lot of setup, and for the use case I had in mind this would definitely make it much harder to reason with not just for me but especially for my colleagues. They'd hate me for it I'm sure 😅

But this is a great thing to have at hand to look at if I happen to find some similar use case. Thanks a lot for putting it all together and sharing it with me!

@martinbonnin
Copy link
Contributor Author

Ahah that's fair 👍 . I'll close this one for now. It's still there as reference.

Copy link
Contributor

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.

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

2 participants