HugoPress reference site

Redakční tok, který končí commitem

Od konceptu přes náhled až po publikaci — jak vypadá každodenní práce redakce, když je za publikací Git.

Eva Křížová Eva Křížová 1 min čtení
Redakční tok, který končí commitem

Skvělá architektura je k ničemu, pokud se v ní redakci špatně pracuje. Proto jsme redakční tok HugoPressu postavili kolem tří jednoduchých stavů.

Tři stavy článku

  1. Koncept — autor píše v editoru, ukládá kdykoliv, nic se nepublikuje.
  2. Náhled — jedním kliknutím se obsah vyrenderuje a nasadí na náhledový web, identický s produkcí.
  3. Publikováno — schválený obsah se commitne do produkčního repozitáře a spustí se build.

Náhled = produkce

Náhled běží nad stejnou šablonou i stejným pipeline jako ostrý web. Co vidíte v náhledu, to dostanou čtenáři — žádná překvapení při nasazení.

Publikace jako commit

Publikace nezapisuje do databáze, ale commitne do Gitu. Díky tomu má každý vydaný článek:

  • autora a časové razítko commitu,
  • čitelný diff (co přesně se změnilo),
  • možnost vrátit se k libovolné starší verzi.

Když se obsah nezměnil, publikace se přeskočí — žádné prázdné commity.

Asynchronně, ať to neblokuje

Samotné sestavení a push běží na pozadí přes frontu zpráv. Redaktor klikne na Publikovat, dostane okamžitou zpětvazbu o stavu úlohy a může pokračovat v práci, zatímco worker dokončí build.

Tím se kruh uzavírá: pohodlný editor na vstupu, Git uprostřed, bleskový statický web na výstupu. Detaily doručení jsme rozebrali v článku Proč statický web vyhrává na hraně sítě.

Všechny články
Eva Křížová

Autor

Eva Křížová

Performance engineer, INTEVIA

Ladí doručování webu, měří Core Web Vitals a věří, že nejrychlejší dotaz je ten, který nikdy neproběhne.

Související články

Architektura Hugo Headless

Jak postavit headless CMS nad Hugem

Klasické monolitické CMS spojuje psaní obsahu, jeho ukládání i samotné vykreslování do jednoho běžícího procesu. To je pohodlné, dokud nezačnete řešit výkon, bezpečnost a škálování. Headless přístup tahle tři odpovědnosti rozpojí — a přesně na tom stojí HugoPress. Tři vrstvy, tři odpovědnosti Editor — autoři píší v blokovém editoru (Editor.js). Výstupem je čisté strukturované JSON, ne změť HTML z WYSIWYGu. Doménová vrstva — CMS převede bloky na hotové HTML pomocí BlockRenderingPipeline. Theme samotný o Editor.js vůbec neví. Doručení — vyrenderovaný obsah se zapíše jako content/<lang>/... a commitne do Gitu. Hugo z něj postaví statický web. Theme nezná Editor.js. Všechny renderery sedí na straně CMS — díky tomu je šablona hloupá, přenositelná a snadno testovatelná.

Číst dál
Výkon CDN Hugo

Proč statický web vyhrává na hraně sítě

Když uživatel otevře dynamickou stránku, server typicky sáhne do databáze, sestaví HTML a teprve pak odpoví. U statického webu je tahle práce hotová už během buildu — k requestu zbývá jen poslat hotový soubor. Co se ušetří Round-trip do databáze — neexistuje, obsah je už v HTML. Čas běhového prostředí — žádný PHP/Node proces na kritické cestě. Vzdálenost — soubor leží v CDN POPu pár desítek kilometrů od čtenáře. Měřitelný dopad Metrika Dynamicky Staticky na CDN TTFB ~280 ms ~25 ms LCP (medián) 2,4 s 0,9 s Náklady na request nezanedbatelné ~nula Nejrychlejší dotaz do databáze je ten, který se nikdy nemusí provést.

Číst dál
i18n Obsah Hugo

Dvojjazyčný web bez bolesti

Vícejazyčnost bývá ve většině systémů zdroj utrpení — duplicitní šablony, rozjeté překlady, rozbité odkazy mezi jazyky. Hugo to řeší překvapivě elegantně a HugoPress jen dotahuje pár detailů. Jeden layout, dva jazyky Data sekce žijí ve front matteru stránky, layout je sdílený. Stejná šablona layouts/blog/list.html čte .Params.* a vykreslí cs i en variantu — žádná duplikace logiky. Párování přes translationKey Stačí dát oběma verzím stejný translationKey: # content/cs/blog/_index.md translationKey: blog # content/en/blog/_index.md translationKey: blog Hugo z toho automaticky vyrobí dvojici a přepínač jazyků v hlavičce odkáže na správný protějšek. Když překlad chybí, přepínač elegantně degraduje na domovskou stránku druhého jazyka.

Číst dál