This brings together several opinions I have about how Blazor projects should be structured when supporting mixed WASM and Server components. It also adds several practical elements for real applications. Note also I'm using the new .slnx solution format.

• Domain has entity classes
  • Widget, a generic dummy table you can remove, but is there to demo a crud editing grid later
  • ApplicationUser has a TimeZoneId property, to demo a custom user property with some practical value
  • some low-level extensions for working with user info and Claims
• Service has business logic
  • the ApplicationDbContext
  • a special claims factory ApplicationUserClaimsPrincipalFactory. This is what makes the user's time zone available to the client app.
• Application with its
  • frontend Application.Client
    • see ApiClient
    • see Widgets for a working Radzen grid example and related components
    • see ApiEventHandler to trigger UI feedback when the API is working, along with
    • ApiEventUI which uses a loading spinner and error message Modal
  • backend Application
    • see API endpoint setup and
    • see DbSetApiMapping along with implementation ApiMapping, and lastly where used
    • time zone editing on the user profile manage page
• various Library projects are things that could be extracted to standalone packages, but are in the solution because they're still evolving:
  • ClientHelpers for low-level http client operations
    • CookieHandler.cs
    • a special AddHttpClient extension method that lets you setup an http client for WASM use, invoked
      • in the backend here
      • in the frontend here
  • Radzen.Components builds upon existing Radzen components, notably
    • GridControls.razor has standard crud controls
    • GridHelper.cs abstract class eliminates a lot of grid code boilerplate

Help From

• Dave Archer on some Blazor WASM auth stuff
• Meziantou on Blazor modals
• Jon Hilton's community for general support