From 8088a8bd8bced9127edcb2284b993332d291b443 Mon Sep 17 00:00:00 2001 From: Owen Jacobson Date: Thu, 31 Oct 2024 17:59:10 -0400 Subject: Limit background expiry to the API. Using requests to drive background work (expiring things, mainly) is a hack to avoid the complexity of background workers, but it's reaching its limits. In the live deployment at `hi.grimoire.ca`, we found that requests for the UI were taking 300+ milliseconds as the expiry process required database access. The DB there is slow, which is a separate issue, but also being accessed many times for little benefit. Since only the API is actually _affected_ by expiry, I've scoped the middleware down to just those endpoints. --- src/cli.rs | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'src') diff --git a/src/cli.rs b/src/cli.rs index 0659851..308294d 100644 --- a/src/cli.rs +++ b/src/cli.rs @@ -87,10 +87,6 @@ impl Args { let app = App::from(pool); let app = routers(&app) - .route_layer(middleware::from_fn_with_state( - app.clone(), - expire::middleware, - )) .route_layer(middleware::from_fn(clock::middleware)) .route_layer(middleware::map_response(Self::server_info())) .with_state(app); @@ -144,6 +140,17 @@ fn routers(app: &App) -> Router { ] .into_iter() .fold(Router::default(), Router::merge) + // Run expiry whenever someone accesses the API. This was previously a blanket middleware + // affecting the whole service, but loading the client makes a several requests before the + // client can completely load, each of which was triggering expiry. There is absolutely no + // upside to re-checking expiry tens of times back-to-back like that; the API is accessed + // more regularly and with less of a traffic rush. + // + // This should, probably, be moved to a background job at some point. + .route_layer(middleware::from_fn_with_state( + app.clone(), + expire::middleware, + )) .route_layer(middleware::from_fn_with_state(app.clone(), setup_required)), // API endpoints that handle setup setup::router(), -- cgit v1.2.3