# tibi-starter Starter Kit für SPAs(s) `;)` mit Svelte und TibiCMS inkl. SSR > **Neues Projekt aufsetzen?** → Skill `.agents/skills/tibi-project-setup/SKILL.md` ## Setup-Checkliste ```text [ ] Repository geklont und Remotes konfiguriert [ ] __PROJECT_NAME__ in .env ersetzt (kebab-case) [ ] __TIBI_NAMESPACE__ in .env ersetzt (snake_case) [ ] __NAMESPACE__ in api/config.yml und frontend/.htaccess ersetzt [ ] Keine verbleibenden __*__-Platzhalter (mit grep prüfen) [ ] App.svelte hat mit [ ] ADMIN_TOKEN in api/config.yml.env gesetzt [ ] yarn install && yarn upgrade ausgeführt [ ] make docker-up gestartet [ ] Website erreichbar unter https://{PROJECT_NAME}.code.testversion.online/ [ ] yarn validate zeigt 0 Fehler und 0 Warnungen [ ] yarn build und yarn build:server erfolgreich ``` ## Architektur Via Svelte wird eine SPA (Single-Page-App) programmiert. Der Code wird einmal für den Browser aufbereitet und außerdem für den Server kompiliert und transpiliert. Der Server-Code wird in einem tibi-server SSR-Hook eingebunden und generiert fertiges HTML anhand der aktuellen Route — für SEO und optimierte Ladezeiten. Die Navigation innerhalb der App löst nur API-Aufrufe aus, ohne jedes Mal SSR anzustoßen. Ein Cache in der `ssr`-Collection minimiert die SSR-Last. **SSR-Details:** - `<title>` und `<meta description>` kommen über `<svelte:head>` aus `App.svelte` → SSR injiziert sie in den `<!--HEAD-->`-Platzhalter von `spa.html` - `<html lang>` wird vom SSR-Hook (`api/hooks/ssr/get_read.js`) anhand der URL-Sprache gesetzt - SSR-Bundle wird mit `yarn build:server` erstellt und landet in `api/hooks/lib/app.server.js` **Weiteres Build-Target:** ```sh yarn build:admin # Admin-Module ```