Drupal není mrtvý. Jen už ho nepotřebujeme na všechno.

Když začínáme nový webový projekt, jedna z prvních technologických otázek zní: na čem ho postavíme?

Ještě před několika lety byla odpověď často poměrně přímočará. Vybralo se vhodné CMS, nad ním se postavil web a bylo hotovo. Dnes může být architektura výrazně pestřejší. Front-end může fungovat jako samostatná aplikace, obsah přicházet přes API a CMS být jen jednou z několika služeb na pozadí. Do našeho technologického stacku proto vedle Drupalu přibyl také Payload. Ne jako jeho náhrada, ale jako správná odpověď na jiný typ projektu.

Vybrat CMS podle toho, co agentura používá posledních deset let, je pohodlné. Jen ne nutně pro klienta.

Drupal a Payload nejsou úplně stejní soupeři

Drupal asi není potřeba dlouze představovat. Jde o vyspělý open-source CMS a framework s rozsáhlým ekosystémem, který se dlouhodobě používá pro větší firemní weby, portály, obsahové platformy nebo projekty s mnoha jazykovými mutacemi.

Payload patří k nové generaci nástrojů. Je postavený na TypeScriptu a velmi přirozeně zapadá do současného JavaScriptového vývoje. Vedle administračního rozhraní poskytuje datovou vrstvu, API, autentizaci, správu oprávnění a další funkcionality, které potřebujeme při vývoji moderní webové aplikace. Rozdíl proto není jen ve dvou logách na začátku projektu.

Velmi zjednodušeně se můžeme ptát:

Stavíme především rozsáhlý web a obsahovou platformu?

Nebo:

Stavíme webovou aplikaci, která mimo jiné potřebuje pohodlně spravovat nějaká data a obsah?

V prvním případě se velmi rychle dostaneme k silným stránkám Drupalu. Ve druhém začíná být velmi zajímavý Payload. A pak samozřejmě existuje velké množství projektů někde mezi. Právě u nich začíná být výběr technologie zajímavý.

Drupal: někdy kamion na cestu pro rohlíky

Drupal někdy získává nálepku robustního nebo dokonce těžkopádného systému. A není úplně nezasloužená. Nasadit Drupal na web s pěti stránkami, kontaktním formulářem a třemi novinkami ročně může být trochu jako jezdit pro rohlíky kamionem. Ano, zvládne to. Jen jsme si možná zbytečně přivezli několik tun technologie navíc. Jenže zkuste tím samým osobákem odvézt náklad pro dvacet zemí.

Ve chvíli, kdy možnosti Drupalu skutečně potřebujeme, přestává být jeho robustnost nevýhodou.

Představme si firemní platformu fungující ve dvaceti zemích. Každá má vlastní jazykové mutace a částečně odlišný obsah. Existuje několik typů uživatelů s rozdílnými oprávněními. Web pracuje s rozsáhlou taxonomií, formuláři, vyhledáváním a daty z externích systémů. Obsah má své workflow a celá platforma se bude dalších deset let průběžně rozvíjet.

Tady už nechceme skládat každou základní schopnost systému od začátku. Chceme stát na platformě, která podobné problémy řeší dlouhodobě a má kolem sebe vyspělý ekosystém. A přesně tady nám Drupal stále dává velký smysl.

Multisite, jazyky, obsah a komplexní oprávnění

Síla Drupalu se nejvíc ukazuje ve chvíli, kdy se požadavky začnou násobit. Jeden web je relativně jednoduchý. Deset zemí, několik značek, různé domény, desítky typů obsahu a více redakčních týmů už vytvářejí úplně jinou situaci.

Podobné je to s oprávněními a workflow. Malý web si vystačí s administrátorem a editorem. U větší platformy ale můžeme řešit lokální redaktory, centrální marketing, schvalování obsahu, správce jednotlivých částí webu nebo uživatele s přístupem pouze ke konkrétním datům.

Drupal pro tyto scénáře nabízí velmi silný základ. A důležitý je i jeho ekosystém. Pokud potřebujeme vyřešit běžný problém většího webového projektu, je velká šance, že už jej někdo před námi řešil a existuje pro něj etablovaný postup nebo modul. To může být při dlouhodobém vývoji výrazně důležitější než to, jestli jsme první verzi projektu postavili o několik dní rychleji.

CMS totiž nevybíráme jen pro první den projektu. Vybíráme ho i pro jeho pátý rok.

Payload: aplikace nemusí přemýšlet jako CMS

Pak existuje úplně jiný typ projektu. Stavíme konfigurátor, klientský portál, produktovou aplikaci nebo interaktivní web. Velká část hodnoty nevzniká v samotném publikování obsahu, ale ve vlastní funkcionalitě.

Potřebujeme několik datových kolekcí, administraci, API, uživatele a oprávnění. Nad tím ale chceme především rychle vyvíjet vlastní aplikační logiku.

A právě tady nás Payload baví. Ne proto, že je nový. A už vůbec ne proto, že bychom potřebovali každý rok vyměnit technologický stack za něco modernějšího.

Na Payloadu nás baví, kolik věcí kolem CMS najednou nemusíme řešit jako „CMS problém“.

Datový model definujeme přímo v TypeScriptu a z něj získáváme administrační rozhraní i API. Backend tak velmi přirozeně zapadá do stejného technologického světa jako zbytek moderní webové aplikace. Místo toho, abychom nejdříve postavili komplexní CMS a následně přemýšleli, jak do něj aplikaci vměstnat, můžeme postupovat opačně.

Payload po nás nechce, abychom o aplikaci přemýšleli jako CMS. Nechá nás přemýšlet o ní jako o aplikaci.

A CMS schopnosti přidáme tam, kde je skutečně potřebujeme.

Když je CMS jen část produktu

Tohle je možná největší rozdíl v našem uvažování. U klasického firemního webu je CMS často středobodem celého řešení. Máme stránky, články, produkty, landing pages, formuláře, média a další obsah. Front-end je následně prezentuje návštěvníkovi. U moderní webové aplikace může být CMS jen jednou z částí backendu.

Představme si třeba produktový konfigurátor. V administraci spravujeme produkty, jejich vlastnosti, pravidla nebo obsahové texty. Samotná hodnota řešení ale vzniká až při práci uživatele s konfigurátorem – při zpracování jeho vstupů, aplikační logice a zobrazování výsledků.

Podobně může fungovat klientský portál, interní aplikace nebo nejrůznější doporučovací nástroje. Pro takový projekt může být code-first řešení velmi příjemné. Nepotřebujeme využít stovky schopností klasického CMS. Potřebujeme především dobrý základ pro data a svobodu pro vlastní vývoj.

A právě tady bychom se dnes už automaticky neptali: „Jak to uděláme v Drupalu?“

Code-first neznamená, že editor musí programovat

Pojem „code-first“ může z pohledu marketingového týmu znít trochu nebezpečně. Nebude pak kvůli změně každého nadpisu potřeba vývojář?

Ne.

Je potřeba oddělit správu obsahu od změny struktury aplikace. Editor může v obou systémech pohodlně pracovat s obsahem, který jsme pro něj připravili: články, stránky, produkty, obrázky, kategorie nebo další data. Nemusí kvůli tomu otevírat zdrojový kód.

Jiná situace nastává ve chvíli, kdy chceme změnit samotný datový model nebo strukturu aplikace. Drupal umožňuje mnoho podobných změn provádět přes administrační rozhraní. Možnost něco naklikat ale ještě automaticky neznamená, že je dobrý nápad to udělat.

U produkčního projektu nechceme, aby struktura webu vznikala živelně podle toho, co si kdo v úterý odpoledne naklikal. V našem Drupal workflow držíme konfiguraci v souborech a repozitáři společně se zdrojovým kódem. Změny tak můžeme verzovat, testovat, přenášet mezi prostředími a bezpečně nasazovat.

Payload je v tomto ohledu code-first už ze své podstaty. Z pohledu klienta proto není rozdíl tak dramatický, jak může technologický popis obou systémů naznačovat.

Obsah spravuje editor. Strukturu a architekturu řeší vývoj.

A u větších projektů to považujeme spíš za výhodu než omezení.

Drupal není monolit. Alespoň nemusí být.

Další časté zjednodušení vypadá přibližně takto:

Drupal = tradiční monolit. Payload = moderní headless.

Jenže tak jednoduché to není.

Drupal není monolit jen proto, že tak vypadala spousta Drupal webů v roce 2012.

Drupal lze stejně dobře použít jako headless nebo decoupled CMS. Můžeme nad ním postavit například samostatný front-end ve Vue.js, který si bere obsah a data přes API. U jiného projektu může stejnou roli backendu zastávat Payload.

Rozhodnutí mezi Drupalem a Payloadem proto není rozhodnutím mezi starým a moderním front-endem. Headless architektura je možnost u obou. Rozdíl hledáme spíš v tom, jaký backend chceme za moderním front-endem mít a jaké problémy po něm chceme řešit.

Chcete Lighthouse 100? Výměna CMS vás nezachrání

Další lákavé zjednodušení je výkon. Modernější a lehčí technologie rovná se automaticky rychlejší web a lepší PageSpeed, ne?

Ne nutně.

Chcete Lighthouse 100? Samotnou výměnou Drupalu za Payload ho nedostanete.

Návštěvník webu většinou nekomunikuje přímo s administračním systémem. Výslednou rychlost ovlivňuje způsob renderování front-endu, caching, CDN, optimalizace obrázků, množství JavaScriptu, externí marketingové skripty, infrastruktura a řada dalších faktorů.

Velmi rychlý web můžeme postavit nad Payloadem. A velmi rychlý web můžeme postavit nad Drupalem.

Špatně postavený moderní frontend dokáže být pomalý úplně stejně spolehlivě jako špatně postavený Drupal.

Z pohledu výkonu proto dává větší smysl hodnotit celou architekturu než logo CMS.

Takže: Drupal, nebo Payload?

Teorie bylo dost. Zkusme několik modelových situací.

20 zemí, 15 jazyků, desítky editorů a několik úrovní oprávnění?

• Tady bychom s technologickými experimenty spíš šetřili. Drupal nabízí robustní základ pro přesně ten typ komplexity, kterou budeme muset dlouhodobě zvládat.

Konfigurátor, vlastní business logika, několik datových kolekcí a moderní frontend?

• Tady bychom naopak nezačínali instalací robustního CMS jen ze zvyku. Payload bude velmi vážný kandidát.

Obsahový portál s velkým redakčním týmem a komplikovaným workflow?

• Spíše Drupal.

Webová aplikace s uživatelskými účty, administrační částí a výrazně custom front-endem?

• Spíše Payload.

Klientský portál s mnoha rolemi, integracemi, obsahem a vlastní aplikační logikou?

• Tady už odpověď bez dalších informací nedává smysl.

A právě takové projekty nejlépe ukazují, proč nechceme technologii vybírat podle jedné tabulky funkcí.

Orientační rozhodovací mapa

Pokud bychom přesto chtěli naše uvažování výrazně zjednodušit, vypadalo by přibližně takto:

Nejde o klasické feature comparison. Většinu jednotlivých požadavků lze nějakým způsobem vyřešit v obou systémech.

Tabulka spíš ukazuje, ve kterém prostředí nám daný typ projektu připadá přirozenější.

Feature checklist vám správný CMS nevybere

Při výběru CMS je snadné otevřít dvě produktové stránky a začít odškrtávat.

• Multilingual? Ano.
• API? Ano.
• Permissions? Ano.
• Drafts? Ano.
• Headless? Ano.

Výborně. Máme remízu.

Jenže takhle se technologie pro dlouhodobý projekt vybírá špatně. Důležité je, jak rychle se v nich konkrétní typ řešení vyvíjí, jak dobře zapadají do zbytku technologického stacku, jak se nasazují, jak snadno se udržují a jaké know-how bude projekt vyžadovat za několik let.

A především: kolik času budeme trávit stavěním samotného produktu a kolik přesvědčováním zvolené technologie, aby dělala něco, na co nebyla úplně navržená.

Tady může mít vyspělost a ekosystém Drupalu obrovskou hodnotu. A u jiného projektu může mít stejně velkou hodnotu jednoduchost, code-first přístup a technologická konzistence Payloadu.

A někdy nepotřebujete ani jedno

Nakonec je fér přiznat ještě třetí možnost. U části našich projektů dnes CMS ani backend vůbec nedodáváme.

Klient už má vlastní produktovou platformu, informační systém nebo jiný backend a poskytne nám API. Naším úkolem je nad ním vytvořit moderní front-end – web nebo aplikaci, která data správně zpracuje a nabídne uživateli rychlé a kvalitní rozhraní.

V takovém případě nemá smysl přidávat Drupal ani Payload jen proto, abychom mohli říct, že projekt má CMS. Soustředíme se na front-end, UX, výkon a kvalitní integraci s existujícími systémy.

A možná právě tahle třetí možnost nejlépe vystihuje, jak dnes o technologiích přemýšlíme.

Nejdřív projekt. Potom technologie.

Drupal používáme dlouhodobě a pro rozsáhlé obsahové platformy zůstává důležitou součástí našeho technologického stacku.

Payload vedle něj otevírá jinou cestu. Umožňuje nám stavět moderní aplikace nad code-first backendem, který přirozeně zapadá do TypeScriptového světa a dává nám velkou svobodu při tvorbě custom funkcionality.

A někdy backend dodá někdo úplně jiný a my postavíme pouze front-end. To není nerozhodnost.

Je to možnost neohýbat každý projekt podle technologie, kterou jsme si vybrali předem.

Takže Drupal, nebo Payload? Špatná první otázka.

Co vlastně potřebujete postavit?

Podle toho se můžeme bavit o technologii. Pokud i vy připravujete nový web, portál nebo webovou aplikaci a nejste si jistí, jakou technologickou cestou se vydat, ozvěte se nám. Rádi s vámi probereme zadání, možnosti i jejich limity – a společně vybereme řešení, které bude dávat smysl nejen při spuštění, ale i za několik let.