Files
gerbeur/mod.ts
khannurien 4468438ba7 v4: every page and API URL follows one of two rules, written down in API.md — pages are a hierarchy where @name is a user and any other root word a category or an app page, tabs and views are plain segments and a default view is the bare path; API resources are /api/<plural>/<key>, a user's key being an id or @name, the caller's things under /api/me, media a sub-resource, lookups by another key a query filter. ~ is gone: the feed is /, /hot, /new, /journal, /follow and /music/hot, a profile /@bob with its overview and the tabs dumps, upvoted, playlists (her own only), follow (users, and /follow/playlists), invitees and manage (role and name, for user:manage), which replace the separate UserDumps, UserUpvoted and UserPlaylists pages; /settings holds the account (now with the username) and /manage the category manager, both linked from the user menu and one's profile. Dumps and playlists live under their owner, /@bob/dumps/<slug> and /@bob/playlists/<slug>, named by slug alone: migration 0021 re-slugs them to the bare slugify(title), unique per owner and kind (the oldest keeps it, clashes get -2), renames the categories whose slug v4 reserves (hot, follow, settings…), and rewrites this site's v3 links in dump notes, comments, chat, and playlist and profile descriptions. A slug changes only when edited, through the edit forms' new link field, which proposes slugify(title) as the title changes; a username changes from /settings or, for user:manage, from /@name/manage. Every slug or name left behind stays an alias of its item or user for good (dump_slug_aliases, playlist_slug_aliases, user_aliases), so old links redirect without chaining and nobody else can take one; slugs change 3 times a day per item, names once in 30 days, moderators exempt. An alias, or a name in another case, answers the item with its current path: the pages put it in their URL (useCanonicalPath, without fetching again), and the OG middleware answers a 301. shared/paths.ts builds and parses every page path, for the client's links, the emails' (digest-service lost its own builders and its id fallbacks, and links /follow and /settings) and the server's matchers (OG tags, self previews, backlinks, self-url); shared/slug.ts holds slugify and the format categories share. Dumps and playlists carry ownerUsername and a required slug, and notifications join their users' current names and their items' paths each time they are sent or read, so renames reach them and a deleted item's has no link. The API was renamed per the plan's table: POST /api/users and /api/sessions, /api/password-resets, /api/me (with settings, password, avatar, media-token, playlists?contains=, follow, feed?from=, notifications), /api/users/:key/{dumps,upvoted,playlists,follow/users,follow/playlists,invitees,avatar} and by path /api/users/:key/{dumps,playlists}/:slug, /api/dumps?url= and ?category=, /api/dumps/:id/{file,thumbnail,metadata}, /api/playlists/:id/cover, /api/remote/{preview,image,bandcamp,youtube} (one router), and /api/unsubscribe, the v3 POST /api/users/unsubscribe staying for the digests already sent. A stored default feed tab "followed" reads as "follow" once. dumps.slug and playlists.slug stay nullable, since SQLite can't add NOT NULL without rebuilding tables others reference; every writer sets them and unique (user_id, slug) indexes hold them. 254 backend tests (new: migration 0021 on a v3 fixture, slug aliases, swaps and rate limits, username renames, aliases and limits, reads by path and their privacy, the OG 301s, both unsubscribe paths, v4-shaped digest links with no ids, notification joins, shared paths and slugs) and 668 frontend tests (new: the profile's tabs and follow views, Settings, Manage, the link field, canonical URLs on the dump, playlist and profile pages, bare default feed paths) pass, and tsc, eslint, deno check, deno lint, deno fmt and doc:lint are clean; the migration was also run on a copy of the development database.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 16:08:59 +00:00

78 lines
4.1 KiB
TypeScript

/**
* Documents gerbeur, a small invite-only social platform for sharing links and
* files. The repository holds three parts: the backend in `api/`, the
* frontend in `src/`, and in `shared/` whatever crosses the wire between them.
* [Every module](./all_symbols.html) is listed by path, so the list groups
* them by part and layer.
*
* ## Backend, in `api/`
*
* An Oak server over SQLite answers the API and the WebSocket, and serves the
* built frontend. `api/main.ts` builds the application and listens. A request
* goes to a route, which parses it, calls services and answers. The services
* hold the logic and every SQL query, read rows through the model, and reach
* other sites only through `remote/`. Each folder holds one kind of module,
* and each file is named after its domain.
*
* - `routes/` holds the HTTP API, one router per resource. Each router's page
* lists its endpoints, with their method and path, who may call them, and
* what they do; `API.md` at the root sums them up, with the rule they all
* follow.
* - `middleware/` holds what runs around the routes, which is auth, errors and
* the Open Graph tags.
* - `services/` holds the logic and every SQL query, one module per domain.
* - `model/` holds each table's row type, guard and mappers.
* - `validators/` holds the guards of the request bodies.
* - `remote/` is the only place that fetches from other sites, and its
* `providers/` build the previews of each kind of site.
* - `mail/` renders each email, one template per email on a shared layout
* that takes every site style, its colors and fonts read from the themes'
* stylesheets, and `services/email-service.ts` sends them.
* - `lib/` holds the helpers that belong to no layer.
* - `db/` opens, creates and migrates the database, and cleans it up at
* startup. `db/migrations/` are applied in order, each once.
* - `config.ts` reads the settings from the environment, and `scripts/` holds
* the icon generator.
*
* ## Shared, in `shared/`
*
* The types and constants both halves use sit here, one module per domain.
* They are the API envelope, each domain's types and request bodies, the
* socket protocol, the validation limits, the role permissions, and the page
* paths and slugs (`paths.ts`, `slug.ts`) the client links with and the
* server matches. `shared/` imports nothing from either half. The server
* sends `Date`s, and the client reads the same types through `Wire<T>`, where
* every `Date` is an ISO string.
*
* Beside it, `locales/` holds one Lingui catalogue per language for the whole
* app: the interface's messages, and the emails' that `api/mail/i18n.ts`
* loads compiled. The interface writes its English in place (`t`, `Trans`)
* and Lingui keys the message by it. A message with a named id, which every
* email's is, along with the labels the interface shares with them, has its
* English in `locales/en.po` alone and the code names only the id; the build
* fails when a language lacks one.
*
* ## Frontend, in `src/`
*
* The React app is built with Vite and translated with Lingui. `main.tsx`
* mounts it, `App.tsx` holds the providers and the route table, and `i18n.ts`
* sets the language. A page reads the API and the socket through contexts and
* hooks, and draws with components, while utils hold what isn't React at all.
*
* - `pages/` holds one component per route, each naming its route, and the two
* guards that keep routes to signed-in or signed-out visitors.
* - `config/` holds the settings read at startup.
* - `contexts/` holds, for each domain, a `FooContext` with its state and the
* `FooProvider` that fills it.
* - `hooks/` holds every hook, and `components/` only components.
* - `utils/` holds every module that isn't React.
*
* Every layer but `pages/` and `config/` is split into the same domains (auth,
* category, chat, comment, dump, editor, feed, form, layout, player, playlist,
* profile, social, theme, ws, and shared for what belongs to no one domain), so
* the chat lives in `components/chat/`, `contexts/chat/`, `hooks/chat/` and
* `utils/chat/`.
*
* @module
*/