Files
portfolio/docs/DIRECTUS_COLLECTIONS_STRUCTURE.md
denshooter e431ff50fc feat: Add Directus setup scripts for collections, fields, and relations
- Created setup-directus-collections.js to automate the creation of tech stack collections, fields, and relations in Directus.
- Created setup-directus-hobbies.js for setting up hobbies collection with translations.
- Created setup-directus-projects.js for establishing projects collection with comprehensive fields and translations.
- Added setup-tech-stack-directus.js to populate tech_stack_items with predefined data.
2026-01-23 02:53:31 +01:00

7.1 KiB

Directus Collections Struktur - Vollständige Portfolio Integration

🎯 Übersicht

Diese Struktur bildet alles aus deinem Portfolio in Directus ab, ohne Features zu verlieren.

📦 Collections

1. tech_stack_categories (Tech Stack Kategorien)

Felder:

  • id - UUID (Primary Key)
  • key - String (unique) - z.B. "frontend", "backend"
  • icon - String - Icon-Name (z.B. "Globe", "Server")
  • sort - Integer - Reihenfolge der Anzeige
  • status - String (draft/published/archived)
  • translations - O2M zu tech_stack_categories_translations

Translations (tech_stack_categories_translations):

  • id - UUID
  • tech_stack_categories_id - M2O zu tech_stack_categories
  • languages_code - M2O zu languages (de-DE, en-US)
  • name - String - z.B. "Frontend & Mobile"

2. tech_stack_items (Tech Stack Items)

Felder:

  • id - UUID (Primary Key)
  • category_id - M2O zu tech_stack_categories
  • name - String - z.B. "Next.js", "Docker", "Tailwind CSS"
  • sort - Integer - Reihenfolge innerhalb der Kategorie
  • url - String (optional) - Link zur Technologie-Website
  • icon_url - String (optional) - Custom Icon/Logo URL

Keine Translations nötig - Technologie-Namen bleiben gleich in allen Sprachen


3. projects (Projekte - Vollständig)

Felder:

  • id - UUID (Primary Key)
  • slug - String (unique) - URL-freundlicher Identifier
  • status - String (draft/published/archived)
  • featured - Boolean - Hervorgehobenes Projekt
  • category - String - z.B. "Web Application", "Mobile App"
  • date - String - Projektzeitraum (z.B. "2024", "2023-2024")
  • github - String (optional) - GitHub Repository URL
  • live - String (optional) - Live Demo URL
  • image_url - String (optional) - Hauptbild des Projekts
  • demo_video - String (optional) - Video URL
  • screenshots - JSON - Array von Screenshot-URLs
  • color_scheme - String - Farbschema des Projekts
  • accessibility - Boolean - Barrierefreiheit vorhanden
  • difficulty - String (Beginner/Intermediate/Advanced/Expert)
  • time_to_complete - String - z.B. "4-6 weeks"
  • technologies - JSON - Array von Technologien
  • challenges - JSON - Array von Herausforderungen
  • lessons_learned - JSON - Array von Learnings
  • future_improvements - JSON - Array von geplanten Verbesserungen
  • performance - JSON - {"lighthouse": 90, "bundleSize": "50KB", "loadTime": "1.5s"}
  • analytics - JSON - {"views": 0, "likes": 0, "shares": 0} (read-only, kommt aus PostgreSQL)
  • sort - Integer
  • date_created - DateTime
  • date_updated - DateTime
  • translations - O2M zu projects_translations

Translations (projects_translations):

  • id - UUID
  • projects_id - M2O zu projects
  • languages_code - M2O zu languages
  • title - String - Projekttitel
  • description - Text - Kurzbeschreibung
  • content - WYSIWYG/Markdown - Vollständiger Projektinhalt
  • meta_description - String - SEO Meta-Description
  • keywords - String - SEO Keywords
  • og_image - String - Open Graph Image URL

4. content_pages (Bereits vorhanden, erweitern)

Aktuell:

  • Für statische Inhalte wie "home-about", "privacy-policy", etc.

Erweitern um:

  • key - Eindeutiger Identifier
  • page_type - String (home_section/legal/about/custom)
  • status - draft/published
  • translations - O2M zu content_pages_translations

5. hobbies (NEU - für "When I'm Not Coding")

Felder:

  • id - UUID
  • key - String (unique) - z.B. "self_hosting", "gaming"
  • icon - String - Icon-Name
  • sort - Integer
  • status - String
  • translations - O2M zu hobbies_translations

Translations:

  • id - UUID
  • hobbies_id - M2O zu hobbies
  • languages_code - M2O zu languages
  • title - String - z.B. "Self-Hosting & DevOps"
  • description - Text - Beschreibung des Hobbys

6. messages (Bereits vorhanden via Directus Native Translations)

Struktur:

  • Collection: messages
  • Felder:
    • key - String - z.B. "nav.home", "common.loading"
    • translations - Native Directus Translations
      • value - String - Übersetzter Text

🔄 Datenfluss

Aktuell (Hybrid):

PostgreSQL (Projects, Analytics) ←→ Next.js ←→ Messages (JSON Files)
                ↓
         Directus (Content Pages)

Nach Migration (Unified):

Directus (Projects, Tech Stack, Content, Messages, Hobbies)
    ↓
  GraphQL API
    ↓
  Next.js (mit Fallback Cache)
    ↓
PostgreSQL (nur für Analytics: PageViews, UserInteractions)

📊 Was bleibt in PostgreSQL?

Nur echte Analytics-Daten:

  • PageView - Seitenaufrufe
  • UserInteraction - Likes, Shares, Bookmarks
  • Contact - Kontaktformular-Einträge
  • ActivityStatus - Live-Status (Coding, Gaming, Music)

Warum?

  • Hohe Frequenz von Updates
  • Komplexe Aggregations-Queries
  • Privacy/GDPR (keine Content-vermischung)

🎨 Directus UI Benefits

Was du gewinnst:

  1. WYSIWYG Editor für Projekt-Content
  2. Media Library für Bilder/Screenshots
  3. Bulk Operations (mehrere Projekte gleichzeitig bearbeiten)
  4. Revision History (Änderungen nachverfolgen)
  5. Workflows (Draft → Review → Publish)
  6. Access Control (verschiedene User-Rollen)
  7. REST + GraphQL API automatisch generiert
  8. Real-time Updates via WebSockets

🚀 Migration Plan

Phase 1: Tech Stack

  1. Collections erstellen in Directus
  2. Daten aus messages/en.json & messages/de.json migrieren
  3. About.tsx auf Directus umstellen

Phase 2: Hobbies

  1. Collection erstellen
  2. Daten migrieren
  3. About.tsx erweitern

Phase 3: Projects

  1. Collection mit allen Feldern erstellen
  2. Migration-Script: PostgreSQL → Directus
  3. API Routes anpassen (oder Directus direkt nutzen)
  4. /manage Dashboard optional behalten oder durch Directus ersetzen

Phase 4: Messages (Optional)

  1. Alle keys aus messages/*.json nach Directus
  2. next-intl Config anpassen für Directus-Loader
  3. JSON-Files als Fallback behalten

💾 Migration Scripts

Ich erstelle dir:

  1. scripts/migrate-to-directus.ts - Automatische Migration
  2. scripts/sync-from-directus.ts - Backup zurück zu PostgreSQL
  3. lib/directus-extended.ts - Alle GraphQL Queries

Performance

Caching-Strategie:

// 1. Versuch: Directus laden
// 2. Fallback: Redis Cache (5min TTL)
// 3. Fallback: Static JSON Files
// 4. Fallback: Hardcoded Defaults

ISR (Incremental Static Regeneration):

  • Projects: Revalidate alle 5 Minuten
  • Tech Stack: Revalidate alle 1 Stunde
  • Content Pages: On-Demand Revalidation via Webhook

🔐 Security

Directus Access:

  • Public Read (via Token) für Frontend
  • Admin Write (via Admin Panel)
  • Role-based für verschiedene Content-Types

Was public bleibt:

  • Published Projects
  • Published Content Pages
  • Tech Stack
  • Messages

Was protected bleibt:

  • Drafts
  • Analytics
  • Admin Settings

📝 Nächste Schritte

Sag mir einfach:

  1. "Erstell mir die Collections" → Ich generiere JSON zum Import in Directus
  2. "Bau die Migration" → Ich schreibe Scripts zum Daten übertragen
  3. "Update den Code" → Ich passe alle Components & APIs an