In apollo3 should me schema and query look like th...

# apollo-kotlin

[Colton Idle]

In apollo3 should me schema and query look like this in the file tree? Or should I be moving it under a package? like src/main/graphql/com.example.myapp?

[bod]

Leaving them directly in graphql works fine 🙂

[bod]

but if you put them under subfolders, they will also be picked up

[Stylianos Gakis]

We simply keep them on the same package structure as the rest of the project is https://github.com/HedvigInsurance/android/tree/6e5da1440646077a96dfa0109541243bc20d2d73/apollo/src/main/graphql/com/hedvig/android/apollo take a look at this for example.
An important note is that the directory com.hedvig.android.apollo has schema.graphqls right there, and then there’s yet another subfolder called graphql which contains all the queries etc. This makes it easier in the IDE (pic attached) to differentiate where the schema is and where everything else is. Also gitignoring the schema.graphqls anyway, since there’s no reason to share that. Running ./gradlew :apollomodule:download<ServiceName>ApolloSchemaFromIntrospection locally should download the latest and greatest anyway. It’s noise in PRs otherwise 😊

[Colton Idle]

very interesting! thanks all.

[Colton Idle]

i guess I was curious how it tied into this

[Colton Idle]

and whether or not they had to match or anything

[bod]

just a note that keeping revisions of your schema in git is sometimes useful (reproducible builds!)

[Stylianos Gakis]

The packageName is https://github.com/apollographql/apollo-kotlin/blob/a875f843de6345ba171d2370a17770[…]src/main/kotlin/com/apollographql/apollo3/gradle/api/Service.kt for what the generated code will print afaik?

[bod]

@Colton Idle packageName controls in which package the generated code will land, but it doesn't need to be in sync with where the .graphql files are

[Stylianos Gakis]

Good point Benoit, it’s true that without it we can’t really build older versions of our code which had a different schema to it. Hmm this does make me think maybe I am wrong for git-ignoring it, and we should just add it back, but ignore the (sometimes) big and annoying diffs on some PRs. I think that does indeed sound like a better solution

[Colton Idle]

thanks for teaching! learned a bunch in this thread!

[Colton Idle]

jumping into graphql after years of rest is intimidating! thank you all for answering my questions!

[Stylianos Gakis]

This channel is my favorite one here, I’ve had a incredible number of questions of my own answered here, and now I can finally answer other people’s questions too, so you’ll be tired of seeing my face here, be ready 😂

[agrosner]

absolutely only recommend checking in the schema to git. especially depending on your company and if they allow breaking changes easily to the schema. It gives you a good history of schema changes in your app over time.
also can easily be automated with CI cron jobs to pulll in latest

[ephemient]

You can ignore diffs to those files in the GitHub interface by setting linguist-generated as per https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github

[Stylianos Gakis]

I had no idea this existed, thanks so much!