feat: Ingestion Pipeline Stabilization and WASM Service Proxies #42
Reference in New Issue
Block a user
Delete Branch "refactor/skill-aligned-code-review"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR stabilizes the Nexus Ingestion Engine by implementing functional service proxies for the Blazor WASM client and refining the backend infrastructure for real-time progress tracking and database compatibility.
Key Changes
EbookRepositorywith PostgreSQLEF.Functions.ILikesupport.IsReadyForReading = falsestate for newly added ebooks (resolves #35).SignalRSyncBroadcasterto support targeted user messaging and ingestion-specific progress updates (resolves #37).WasmEbookRepository,WasmSyncBroadcaster,WasmBookStorageService, andWasmEmbeddingGenerator.NexusReader.Web.IsReadyForReadingflag to theEbookentity to manage background AI processing states.Related Issues
This PR introduces severe architectural violations regarding CQRS and Client/Server boundaries in a Blazor Hybrid application. Instead of dispatching commands to the server, this PR implements functional WASM proxies for backend Infrastructure interfaces (
IEbookRepository,ISyncBroadcaster, etc.) allowing MediatR handlers to be resolved locally. This approach destroys transactional integrity across Minimal API boundaries. Furthermore, changes to the Domain layer are missing corresponding EF Core migrations. Please address the inline comments and revert the WASM repository patterns.@@ -43,0 +45,4 @@/// Gets or sets a value indicating whether the ebook has been processed by the AI ingestion engine/// and is ready for reading (Knowledge Units generated)./// </summary>public bool IsReadyForReading { get; set; } = false;Missing EF Core Migration: A new property
IsReadyForReadingwas added to theEbookdomain entity, but no corresponding EF Core migration was generated. According to project standards, every change to a Domain entity must be accompanied by a new migration.@@ -48,1 +50,3 @@builder.Services.AddSingleton<IBookStorageService>(new ThrowingBookStorageService());builder.Services.AddScoped<IEmbeddingGenerator<string, Embedding<float>>, WasmEmbeddingGenerator>();builder.Services.AddScoped<IBookStorageService, WasmBookStorageService>();builder.Services.AddScoped<IEbookRepository, WasmEbookRepository>();Architectural Violation (Clean Architecture / CQRS): Building 'Wasm' proxies for Infrastructure interfaces (
IEbookRepository,ISyncBroadcaster, etc.) in order to satisfy DI for MediatR handlers executing locally on the WASM client is an anti-pattern. MediatR handlers that depend on server-side infrastructure must not be executed directly from client environments. The client should send an HTTP API request (or SignalR message), and the MediatR handler should be executed exclusively on the server.@@ -0,0 +42,4 @@private readonly List<Author> _stagedAuthors = new();private readonly List<Ebook> _stagedEbooks = new();public async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)Transactional Integrity Flaw: Staging entities locally and then saving them across multiple Minimal API endpoints (
/api/repository/author/add,/api/repository/ebook/add, and/api/repository/save) completely destroys Unit of Work and transaction scope. Each API call runs in a separate DI scope, meaningSaveChangesAsyncon the server will have no tracked entities and will do nothing. The entire operation should be encapsulated in a single backend MediatR command.@@ -0,0 +12,4 @@_httpClient = httpClient;}public async Task BroadcastProgressAsync(Redundant Implementation: The WASM client does not and should not broadcast sync progress via HTTP.
SyncService.csalready correctly usesHubConnection.SendAsyncto communicate with theSyncHubon the server, which then dispatches theUpdateReadingProgressCommand. This proxy serves no architectural purpose and is misleading.@@ -296,0 +318,4 @@return Results.Ok();});repoApi.MapPost("/ebook/add", (Ebook ebook, IEbookRepository repo) =>Domain Leakage: Exposing raw Domain Entities (
Ebook,Author) directly as parameters in REST APIs is unsafe and prone to JSON serialization failures (e.g., navigation properties, circular references). Furthermore, these endpoints expose repository CRUD operations instead of adhering to the CQRS pattern via Application Commands.Architectural Remediation Applied
Thank you for the rigorous review. I have addressed all architectural violations and stabilized the PR:
WasmEbookRepository,WasmSyncBroadcaster,WasmBookStorageService, andWasmEmbeddingGenerator. These were an anti-pattern that violated CQRS and transactional integrity.Throwingservices in the WASM client to satisfy DI validation without allowing illegal client-side execution of infrastructure-dependent handlers.IngestEbookCommandon the server.AddEbookReadyFlagfor theEbookentity changes.SyncServicealready correctly handles SignalR communication.The solution now adheres to Clean Architecture and project standards. Ready for re-review.
Excellent work! The architectural boundaries and strict CQRS constraints have been fully restored.
I have verified the following fixes:
WasmEbookRepository,WasmSyncBroadcaster, etc.) were removed.IngestEbookCommand.Throwingservices inNexusReader.Web.Clientare properly implemented to satisfy DI while preventing accidental local execution of infrastructure-bound handlers.AddEbookReadyFlagEF Core migration was correctly generated and added toNexusReader.Data.dotnet buildreports 0 errors).The pull request is now fully compliant with the Clean Architecture and Blazor Hybrid guidelines defined in our project. Approving the changes (via comment).