- Repo contains an Azure Functions API in
Catalog.API. - Shared EF Core DAL/BLL lives in
ePubAnalyzer.Shared. - Active frontend is Next.js in
Catalog.Next/catalog. Catalog.NGis an older Angular frontend and was not touched for this round.ePubAnalyzer.Sharednow multi-targetsnet7.0andnet10.0so the legacy Azure Function can stay onnet7.0while the analyzer runs on .NET 10.
- The Next app was reading Postgres directly through Prisma rather than calling the Azure Functions API for catalog reads/writes.
- The legacy analyzer/console app previously had an optional API mode, but it now uses direct database access only.
- The catalog page loaded the full book dataset client-side after mount and filtered in the browser.
- The list query pulled full rows, including large text fields such as
Description, even though the overview only needed summary fields. - The book detail page queried the same record twice: once in
generateMetadata()and once again in the page itself. - Prisma client creation was not guarded with the standard singleton pattern, which can increase connection churn in dev/server reload scenarios.
- The C# API used read-then-save flows for partial updates, causing extra database roundtrips for simple status edits.
EpubAnalyzer.slncurrently references a missing project:Catalog.KO/Catalog.KO.csproj.
- Next Prisma layer:
- Added a singleton Prisma client in
Catalog.Next/catalog/lib/prisma.ts. - Added cached catalog-summary reads and cached book-detail reads in
Catalog.Next/catalog/lib/bookrepository.ts. - Consolidated the Next app into its own direct database API under
Catalog.Next/catalog/src/app/api/books/.... - Reads and writes in the Next app now clearly go through Next route handlers backed by Prisma, not through
Catalog.API. - Catalog summary now selects only:
BookIDTitleAuthorReadStatusDescriptionMediumStatusNrOfPages
- Added a singleton Prisma client in
- Next cache invalidation:
- Write route handlers now call
revalidateTag('books')andrevalidateTag('book:{id}').
- Write route handlers now call
- Frontend rendering:
/booksnow renders from a server-side cached fetch instead of client-side boot fetches.- Filtering is still instant in the browser, but it works against the lighter summary payload.
- Added a redesigned landing page, header, catalog view, and refreshed detail page styling.
- C# API:
- Added
AsNoTracking()to read queries inePubAnalyzer.Shared/DAL/BookRepository.cs. - Replaced read-then-update patterns for read badge/status/availability updates with direct attached-entity partial updates.
- Replaced detail merge flow in
BooksFunctionwith repository-driven partial detail updates to avoid the extra read.
- Added
Catalog.API/Catalog.API.csprojbuilds successfully.Catalog.Next/catalogpasses./node_modules/.bin/tsc --noEmit.npm run buildfor the Next app is currently blocked in this environment by Prisma engine download/network access.- Full solution build via
dotnet build EpubAnalyzer.slnfails because the solution still references missingCatalog.KO/Catalog.KO.csproj.
- If DB load is still high, add database indexes for the actual query patterns, especially on:
BookIDReadStatusAuthorTitle
- Consider moving the Next write API to batch/optimistic UI flows if users do many successive edits.
- If the catalog grows a lot, replace client-side filtering of the summary dataset with server-side search parameters and pagination.
- If you want consistent mutation behavior across clients, decide whether Next should remain the primary app API or whether reads/writes should be routed back through
Catalog.API. - If
Catalog.APIis no longer needed for the web catalog, the next cleanup step is to remove any deployment/runtime dependency on it from infrastructure and documentation. - The analyzer no longer needs
ApiLocationorUseApi; onlyConnectionStringis required inSecrets.cs.
- The worktree was already heavily dirty before these edits. Avoid broad cleanup or line-ending normalization without an explicit request.
Catalog.Next/catalog/.envexists and is untracked; treat it as local environment state.