Data Flow
End-to-end data flow diagrams query, mutation, backend pipeline, error handling, and caching strategy.
Understanding how data flows through SCRIPE is essential for debugging and extending the system. This page traces data from a button click in the UI all the way to the database and back.
Query Flow (Read)
When a user views data (e.g., opening the Users page), the flow starts at the View, goes through the ViewModel, TanStack Query, Repository, API Service, and finally the backend API.
Mutation Flow (Write)
Backend Request Pipeline
Every backend request passes through 10 middleware components and 4 SCRIPE mediator pipeline behaviors before reaching the handler. This ensures consistent logging, authentication, authorization, validation, feature gating, and auditing.
Error Handling
Errors are handled at multiple levels. Each error source has a specific handler, response code, and frontend handling strategy.
| Error Source | Handler | Response Code | Frontend Handling |
|---|---|---|---|
| Validation failure | ValidationBehavior throws ValidationException | 400 Bad Request | Form field errors via Result.errors[] |
| Auth failure (no token) | JWT Middleware rejects | 401 Unauthorized | Redirect to /login |
| Auth failure (forbidden) | Authorization policy rejects | 403 Forbidden | Show permission error |
| Entity not found | Handler returns Result.Failure() | 404 Not Found | Show 404 page |
| Rate limit exceeded | Rate Limiter middleware | 429 Too Many Requests | Show retry message |
| Unhandled exception | Global exception handler | 500 Internal Server Error | Show generic error |
| Concurrency conflict | EF Core throws DbUpdateConcurrencyException | 409 Conflict | Retry with refresh |
Caching Strategy
The backend uses a two-level caching strategy: L1 (in-process IMemoryCache) and L2 (distributed Redis). The frontend uses TanStack Query's built-in cache with configurable staleTime.