Architecture

Thanks to the end-to-end encryption, kittehlist provides a large amount of functionality in the frontend. The backend necessarily gets relegated to a database mediator role unlike in other applications:

• authentication and access control for lists
• live list updates between all connected clients

Web server path system

• Static files: All paths under /static.
• REST API: All paths under /api. The API is versioned and the current version is found at /api/v1. (It is unlikely that we will support more than one API version at a time, but this prevents clients from accidentally misusing an API.)
• User-facing paths: Any other path; basically all of them serve HTML.

Frontend-backend-relationship

Frontend and backend communicate via a REST API. This API is intended to represent the whole kittehlist functionality, such that alternative frontends can be written against it. Some web pages directly perform backend logic on visit (e.g. /list/new which immediately creates a new list and redirects to it), others are largely static (e.g. any other list page, which serves the exact same HTML, all list-specific logic is implemented in the frontend which reads the URL).

On the HTTP server, the entire frontend lives under /static, with the exception of the special site.webmanifest file (used by convention and required by some PWA implementations). kittehlist will serve its own static files from the filesystem here.

Because the /static path is reserved for static frontend files, these files can instead be served by a CDN, load balancer, or reverse proxy, all with caching as usual for rarely-changing static files. This use case is explicitly supported and any issues with it will be fixed. While kittehlist does support caching, its overall static file implementation is probably less performant than tailor-made solutions.