Circular Dependency Issue: Full-Stack ChiliCream with Blazor WebAssembly

[stevefan1999-personal]

I'm attempting to build a full-stack application using ChiliCream's Hot Chocolate GraphQL server with a Blazor WebAssembly frontend that consumes the GraphQL API via StrawberryShake. However, I've encountered a fundamental architectural challenge that creates a circular dependency during the build process.

The Problem

The issue manifests as a classic catch-22 scenario:

1. Client Dependency: The Blazor WebAssembly client needs to use StrawberryShake to generate strongly-typed GraphQL clients. This requires:

   • Access to the server's GraphQL schema (typically via the /graphql endpoint)
   • The schema to be available at build time for code generation
   • The server to be running or at least have its schema exported

2. Server Dependency: In a typical Blazor WebAssembly hosted setup:

   • The server project references the client project
   • The server needs to serve the compiled WebAssembly files
   • The server cannot build without the client being built first

This creates an impossible build order where:

• The client cannot build without the server's schema
• The server cannot build without the client's compiled output

Current Architecture

Solution Structure:
├── MyApp.Server (ASP.NET Core + Hot Chocolate)
│   └── References: MyApp.Client
├── MyApp.Client (Blazor WebAssembly + StrawberryShake)
│   └── Needs: Server's GraphQL schema at build time
└── MyApp.Shared (Common DTOs/Models)

Impact

This circular dependency prevents:

• Clean CI/CD pipeline setup
• Fresh clones from building without manual intervention
• Straightforward development workflow for new team members
• Standard dotnet build from working on the solution level

Question

Is there a recommended pattern or best practice for structuring a full-stack ChiliCream solution with Blazor WebAssembly that avoids this circular dependency? I'm looking for approaches that maintain the benefits of:

• Strongly-typed GraphQL clients via StrawberryShake
• Hosted Blazor WebAssembly deployment model
• Single solution/repository structure
• Automated build processes

Any guidance on architectural patterns, build configurations, or tooling that can help resolve this issue would be greatly appreciated. Perhaps there's a way to:

• Export the schema at build time before client compilation?
• Use a different project structure that breaks the circular reference?
• Leverage MSBuild tasks or other build-time solutions?
• Configure StrawberryShake to work with a schema file instead of a live endpoint?

Thank you for any insights or recommendations!