-
Notifications
You must be signed in to change notification settings - Fork 312
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
Modify fragment location for GraphQl Tests #1092
Comments
Hi @emaarco , thanks for this detailed report. I think we already allow the
I think that part was partially intentional. The feature request in #964 was focusing on testing support and I don't think we support fragments with our non-test client right now. I guess you tried using fragments with the |
hi @bclozel - thank you for your fast response! :) I saw in
To answer your question about my current usage (if I have understood it correctly): My use of fragments is focused solely on requests coming from the frontend to the backend.
My goal is to provide the fragments in a more general-purpose folder to make them reusable beyond testing contexts. I feel that this could be beneficial not only for my project but potentially for others as well. Thus i decided to open this request to discuss this :) |
@bclozel - I was able to create a custom GraphQl tester. Do you have the feeling that there is some point in the documentation where you could add how to solve such a use case? I think that would have saved me a lot of time in solving the problem. Otherwise I think you could close the issue :) With such a tester, I am now able to save fragments in a separate folder. @Configuration
class GraphQlTestConfiguration {
@Bean
@Primary
fun customGraphQlTester(
executionGraphQlTester: ExecutionGraphQlService,
): GraphQlTester {
val customDocumentSource = documentSource()
return ExecutionGraphQlServiceTester.builder(executionGraphQlTester)
.documentSource(customDocumentSource)
.encoder(Jackson2JsonEncoder())
.decoder(Jackson2JsonDecoder())
.build()
}
private fun documentSource(): DocumentSource {
val resources = listOf(ClassPathResource("graphql-test/"), ClassPathResource("graphql-fragments/"))
return ResourceDocumentSource(resources, ResourceDocumentSource.FILE_EXTENSIONS)
}
} The complete code can be found here If anyone can think of a simpler solution, I would appreciate your feedback! :) |
📋 Summary
I suggest modifying how file-based GraphQL fragments are handled in tests by allowing fragments to be sourced from a dedicated
graphql-fragments
folder rather than the currentgraphql-test
folder.🛑 Problem Statement
Currently, Spring GraphQL requires file-based fragments for tests to be placed in a
graphql-test
folder, which limits their use as a central resource.In our platform, we have multiple backend services, each with GraphQL APIs that often return similar types like
Task
orUser
. Clients frequently request these entire objects, which leads to duplicated code across many queries and mutations. For example, every time we need aUser
object, we manually list all attributes, which is cumbersome and error-prone.GraphQL fragments solve this problem by letting us define shared structures once, reducing repetition. However, since fragments aren't part of the GraphQL Schema Definition Language (SDL) and can't be accessed via introspection, clients must also define them separately, leading to duplication between backend and frontend code.
To address this, we want to create a central fragment registry in a backend service that all clients can use (f.ex. by synching them). This ensures consistency and keeps the backend as the single source of truth.
The current restriction to
graphql-test
is misleading, as it implies the fragments are test-only, rather than globally reusable.🔍 Example
Consider the following example of a GraphQL fragment that defines a fragment for a
User
:Below is a test that makes use of this
UserDetails
fragment. Theuser.fragment
file referenced must be placed in agraphql-test
folder:💡 Proposed Solution
Allow file-based fragments to be placed in a
graphql-fragments
folder instead ofgraphql-test
. This will better support the idea of a central fragment registry that can be used across both backend services and clients.🚀 Benefits
🤝 Contribution
I am willing to contribute to this feature and have already designed a first implementation to check if this approach is possible. If you are considering the implementation, I am happy to further refine it based on your feedback.
💬 Feedback Request
I would greatly appreciate your feedback on this suggestion. Do you see any challenges or alternative approaches that could better support this use case? Please let me know your thoughts, and I'd be happy to discuss this further.
The text was updated successfully, but these errors were encountered: