Automatic server-side endpoint caching

[kran6a]

Endpoints could be used as a zero-effort memoization mechanism.

Take for example the endpoint /scores/[timestamp].json.ts. It fetches data from a DB and returns an array of scores of an user up to an specific snapshot timestamp. Since a past score cannot vary we could place a cache-control: public, immutable header in the endpoint.

Now lets say we have another endpoint, /users/[username].json. This endpoint fetches data from a DB and returns some user data plus the most recent score snapshot.

Right now we have two trivial options to implement these endpoints:

1. Make separate and unrelated DB queries for each endpoint
2. Reuse the /scores/[timestamp].json.ts get handler by importing it from /users/[username].json

Option 1 is more performant since it results in a single DB query but it cripples reusability.
Option 2 requires less code but makes 2 DB calls to what could be a repurposed PATA hard disk attached to a raspberry pi through the GPIO interface using a 54Mbit Wi-Fi adapter.

If we make fetch behave like it does in the browser, where endpoints returning appropriate cache-control headers are cached on disk/ram, we could get option 2 to be as fast as option 1 most of the times.

That way the developer do not need to import the scores endpoint from the user endpoint and then figure out a caching mechanism.
We can defer the caching to fetch and just call fetch('/scores/1642822458121.json') which will look for a cached response before actually hitting the endpoint.

This caching approach is also very useful when dealing with immutable data or graph-like structures since you can pull subgraphs from a local cache instead of relying on the DB server without needing to write any extra code or abstractions. It also favors modular APIs and make them highly maintainable since if I wanted to change how the scores are served I would only need to modify the SQL statement on a single line of code instead of on every endpoint that fetches something related to it (say the user, a score comparison among the user and their friend list, leaderboards of different kinds, a match result, a live match data, …).

Cache parameters (memory and disk quotas, vacuum strategy, disk cache path, …) could be configured in svelte.config.js.