Discussion: Future Plans for a "Code-First" Development Model?

[davide-zilio-domnia]

Hi Spring for GraphQL team,

First, thank you for the excellent work on this project. The deep integration with the Spring ecosystem is fantastic and provides a solid foundation for building GraphQL APIs.

We understand that spring-boot-starter-graphql was intentionally designed with a Schema-First philosophy, where the .graphqls schema file serves as the single source of truth and the contract for the API. This approach has clear benefits, especially in large, distributed teams.

However, in our development workflow, we often find that a Code-First approach offers significant advantages in terms of development speed and maintainability. Generating the schema directly from annotated Java code eliminates the need to keep two sources of truth (the schema and the Java DTOs/services) in sync, reducing boilerplate and preventing drift between the API contract and its implementation.

We are aware of third-party libraries in the ecosystem like GraphQL SPQR that provide this functionality.
The existence and popularity of these libraries show a strong interest in the Java community for the Code-First development model.

This leads to our question:

Has there been any internal discussion, or are there any long-term plans, to officially support a Code-First model directly within the spring-graphql project?

Having an official, tightly-integrated Code-First option would be a powerful feature for many developers and teams who prefer this paradigm, allowing them to stay within the official Spring project ecosystem without needing third-party wrappers.

We would be very interested to hear the team's thoughts on this topic, your reasoning behind the schema-first choice, and your vision for the future of the project in this regard.

Thank you for your time and for all your great work on the Spring Framework.

[bclozel]

Hello @davide-zilio-domnia and thanks for reaching out.

This was discussed quite early in the project with #111 and at the time we came to the conclusion that we were writing this project "schema first" in mind and that we didn't want to invest in that area. Since then, we didn't get any contribution nor questions from library maintainers on using spring-graphql as infrastructure for building a code first approach. I see that GraphQL SPQR has an issue about this, but no news so far.

In the meantime, we double down on the schema first approach with a few features, including the schema mapping inspection feature. This should help a lot when it comes to keeping schema and implementation in sync, especially for small schemas.

We do allow applications and libraries to hook into the schema process building and contribute to the schema. But I don't think the existing annotation model would get us really far for generating even simple schemas, because of the following aspects:

• nullability support would not work right now (but could work with the upcoming generation with @ArgumentValue and better nullability detection
• Unions and interfaces
• Documentation
• Functional registration of data fetchers and data loaders
• more...

I would argue that schema design is an important step in the overall design of the application, for small/large teams and services. The concepts described, flexibility for evolution and overall design is as much as important as API design for a library developers would use. The GraphQL schema is front and center. We do acknowledge that writing records and DTOs matching the schema can be boilerplate, so we are compatible with the DGS codegen build plugin to make things easier.

Thanks!