reduce server load using cache

Now let me compile the full analysis.

How Caching Concepts Apply to ERP Crystal MFG

Current State: No Caching Anywhere

The system has zero caching infrastructure — no IMemoryCache, no Redis, no [ResponseCache] attributes, no output caching, no static file cache headers. The only cache-like mechanism is a ConcurrentDictionary<string, string> in DapperContext.cs:18 for SQL server name lookups.

Every single request hits the database, regenerates PDFs/Excel from scratch, and re-fetches the same reference data (company info, system parameters) dozens of times.

Server-Side Caching: Applicability & Impact

Priority 1: GetCompanyMstInfo + GetSysParameterValue + GetStdInsNotes

These are called in every single controller that generates any report. They are read-only reference data queried from the same database. A pattern like:

// In a base controller or service
private async Task<CompanyMstInfo> GetCachedCompanyInfo(string dbname)
{
    var cacheKey = $"CompanyMstInfo_{dbname}";
    return await _memoryCache.GetOrCreateAsync(cacheKey, async entry =>
    {
        entry.SlidingExpiration = TimeSpan.FromMinutes(10);
        return await _ICompanyRepository.GetCompanyMstInfo(dbname);
    });
}

This alone would eliminate thousands of redundant DB calls per hour.

Priority 2: Content-Hash PDF Caching

Currently all PDFs use:

Random rnd = new();
var randomNumber = rnd.Next(1000000000).ToString().Trim();
var randomFileName = $"{randomNumber}.pdf";

This guarantees zero reuse. Instead:

// Deterministic filename based on input hash
var hash = Convert.ToHexString(SHA256.HashData(Encoding.UTF8.GetBytes(
    $"{dbname}-{invoiceId}-{date}"  // unique identifying parameters
)));
var pathFileName = Path.Combine(reportsBase, $"{hash}.pdf");
if (!File.Exists(pathFileName))
    document.GeneratePdf(pathFileName);  // Only generate if not cached
return File(System.IO.File.ReadAllBytes(pathFileName), "application/pdf", "invoice.pdf");

Priority 3: Output Caching for API Endpoints

Add UseOutputCache() in Program.cs and tag cacheable GET endpoints:

// Program.cs
builder.Services.AddOutputCache();
app.UseOutputCache();

// Controller
[HttpGet("{yearLabel},{dbname}")]
[OutputCache(Duration = 60, VaryByQueryKeys = ["*"])]  // 60-second cache
public async Task<ActionResult> InvoiceIndex(string yearLabel, string dbname)

This is ideal for the ~150+ GET endpoints that the Blazor front-end calls on every page load.

Client-Side Caching: Applicability & Impact

Client-Side Priority: Static File Caching (2-line fix)

Most impactful client-side change with minimal effort:

// Program.cs line 385 — change from
app.UseStaticFiles();

// to:
app.UseStaticFiles(new StaticFileOptions
{
    OnPrepareResponse = ctx =>
    {
        ctx.Context.Response.Headers.CacheControl = 
            new CacheControlHeaderValue { MaxAge = TimeSpan.FromDays(365), Public = true }.ToString();
    }
});

For Blazor Server specifically, the Blazor framework already handles caching of .dll and .wasm files through ASP.NET Core’s built-in static file versioning (_framework/blazor.server.js is cached by the browser by default). Adding explicit headers ensures this works consistently.

Why Blazor Server Limits Client-Side Caching

Because this is Blazor Server (not WASM), the UI rendering happens on the server. Every user interaction goes through a SignalR circuit. This means:

• Client-side caching cannot cache rendered HTML — UI is server-generated
• Client-side caching can only cache API response data to potentially skip some HTTP calls
• LocalStorage is the primary client-side tool (already used for session/grid state)
• Service Workers would intercept API calls to the backend, but the Blazor circuit itself must stay connected

Summary: Highest-Impact Caching Plan

Want me to proceed with implementing Priority 1 (in-memory caching for reference data) as a concrete first step?