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

This commit is contained in:
2026-07-28 19:53:25 +02:00
parent c0edb2033d
commit 71b9808a11
@@ -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.