content: demo presentation article (architecture, links, static-vs-database comparison)

2026-07-28 19:53:25 +02:00
parent c0edb2033d
commit 71b9808a11
1 changed files with 113 additions and 0 deletions
@@ -0,0 +1,113 @@
+---
+title: "Jak działa to demo: portal statyczny + CMS oparty o git"
+description: "Architektura rozwiązania, przydatne linki i porównanie klas rozwiązań: strona w 100% statyczna z graficznym edytorem treści vs CMS z własną bazą danych."
+date: 2026-07-28
+category: demo
+author: Cyfronet
+draft: false
+---
+
+Ten portal to **statyczne pliki HTML** generowane z plików Markdown trzymanych
+w repozytorium git. Redaktor dostaje **graficzny edytor w przeglądarce** —
+a mimo to w produkcji nie działa żadna aplikacja, żadna baza danych.
+Ten artykuł został napisany i opublikowany dokładnie tą ścieżką.
+
+## Jak to działa
+
+```
+ redaktor (przeglądarka)
+     │  edycja WYSIWYG + upload obrazów
+     ▼
+ Sveltia CMS  (/admin/ — statyczne pliki JS, zero własnego backendu)
+     │  zapis = commit przez API (logowanie OAuth)
+     ▼
+ Gitea  (repozytorium: treść w Markdown + obrazy)
+     │  poller sprawdza nowe commity (systemd timer, co ~10 s)
+     ▼
+ build w kontenerze  (Astro: Markdown → HTML, ~225 stron)
+     │  atomowa podmiana symlinka na nową wersję
+     ▼
+ nginx  — serwuje wyłącznie statyczne pliki
+```
+
+Publikacja jest automatyczna — zapis w edytorze po chwili sam pojawia się
+na stronie, bez żadnego ręcznego deployu. Każda zmiana to commit, więc
+**pełna historia treści i możliwość cofnięcia są w gicie za darmo**.
+
+## Gdzie co jest
+
+| Co | Gdzie |
+|---|---|
+| Portal | strona główna tego serwisu |
+| Edytor treści | `/admin/` (link „Content editor" w stopce) |
+| Gitea (repo `ctao/portal`) | port 3000 na maszynie demo |
+| Konto demo | użytkownik `ctao` (hasło u prowadzącego demo) |
+| Dokumentacja wdrożenia | katalog `deploy/` w repo: `README.md` (runbook) i `DEPLOY-LOG.md` (pełna historia decyzji) |
+
+Całość działa w podmanie na jednej maszynie: kontener Gitei, kontener nginx
+i jednorazowy kontener builda odpalany przez systemd timer.
+
+## Dlaczego strona statyczna
+
+```
+ CMS z bazą danych:                      to rozwiązanie:
+
+ internet ──► aplikacja CMS (PHP/Node)   internet ──► pliki HTML
+              + baza danych                           (nie ma czego zhakować,
+              + pluginy                                nie ma czego patchować)
+              ▲ wszystko publiczne,
+                wszystko trzeba patchować  edycja ──► git (tylko zalogowani)
+```
+
+- **Bezpieczeństwo**: publicznie wystawione są tylko pliki. Nie istnieje
+  panel admina dostępny z internetu, baza do wykradzenia ani runtime z CVE.
+- **Utrzymanie**: nie ma aplikacji, która musi być monitorowana i
+  aktualizowana pod presją łatek bezpieczeństwa. Do utrzymania zostaje git
+  (który i tak utrzymujemy) i krótki skrypt builda.
+- **Szybkość**: statyczny HTML to najszybsza możliwa strona — istotne też
+  dla SEO.
+- **Historia**: wersjonowanie treści to naturalna cecha gita, nie płatna
+  funkcja produktu.
+
+## Dwie klasy rozwiązań
+
+| | Statyczne + git-CMS *(to demo)* | CMS z własną bazą |
+|---|---|---|
+| Przykłady | Sveltia, Decap (+ Astro / Hugo / Eleventy) | Strapi, WordPress, Grav, TinaCMS |
+| Treść żyje w | plikach Markdown w gicie | bazie danych |
+| W produkcji działa | serwer plików | aplikacja + baza, non stop |
+| Utrzymanie | skrypt builda | patche, aktualizacje, backupy bazy |
+| Historia zmian | git, wbudowana | zależnie od produktu (bywa płatna) |
+
+Rzeczy, które „niby są super, a jednak szczypią" — zweryfikowane, nie z folderu
+marketingowego:
+
+- **Strapi** — historia wersji treści nie istnieje w darmowym self-hosted
+  (tylko płatne plany Growth/Enterprise). Wymaga stale działającego Node +
+  Postgresa i regularnych aktualizacji.
+- **WordPress** — największy ekosystem, ale i największa historia podatności
+  (głównie pluginy); publiczny panel logowania i PHP do ciągłego patchowania.
+- **Grav** (PHP, flat-file — „lekka" alternatywa) — poważne podatności RCE
+  w ostatnich latach; nadal wymaga serwera PHP wystawionego do internetu.
+- **TinaCMS** — edytuje Markdown, ale wymaga backendu: chmura Tina jest
+  darmowa tylko do 2 użytkowników, a self-hosting to własny serwer Node +
+  baza (Mongo/Postgres) + auth — wracamy do utrzymywania aplikacji.
+- **Ryzyko open-core**: funkcje potrafią wędrować do płatnych planów
+  (przykład wyżej). Przy plikach w gicie nie ma czego zamknąć za paywallem.
+
+## Brak lock-inu
+
+Każdy element jest wymienialny osobno, bo treść to czysty Markdown:
+
+- **Sveltia ↔ Decap** — ten sam format konfiguracji; podmiana = jedna linijka
+  `<script>`.
+- **Astro ↔ Hugo / Eleventy** — Markdown zostaje bez zmian, wymieniamy tylko
+  szablony.
+- **Gitea ↔ dowolny git** — GitHub, GitLab, cokolwiek.
+- Nawet rezygnacja z całego podejścia = eksport trywialny, bo treść od
+  początku leży w otwartym formacie w naszym repozytorium.
+
+Wniosek z tego demo: zaczynamy od najprostszego rozwiązania, które spełnia
+wymagania (graficzny edytor + bezpieczna, bezobsługowa strona publiczna),
+a complexity dokładamy dopiero wtedy, gdy pojawi się potrzeba, której to
+podejście nie obsłuży.