Jak ten web dostaneme k návštěvníkům

Kdyby tě někde mělo přepadnout nutkání knihu zavřít a najmout někoho, kdo „tomu rozumí", bude to nejspíš tady. Tahle část je nejtechničtější. Ale v klidu. Nejde o to, abys uměl spravovat servery. Jde o to, abys poznal, kde se web může rozbít dřív, než na to přijde návštěvník.

V minulé části vznikla kostra. Víš, jaké typy obsahu máš, jak spolu souvisejí a kde žijí média. Teď se z té struktury musí stát hotový web. Někde se z ní vyrobí HTML. Někde to HTML poběží. Nějak se k němu připojí doména. A každá změna se musí dostat ven tak, aby šla zkontrolovat a případně vrátit zpátky.

První otázka nezní „bude web statický, nebo dynamický?". Otázka zní kdy vznikne výsledné HTML? Při buildu, na serveru při požadavku, nebo až v prohlížeči? Tohle rozhodnutí je rendering a hned určuje, co musí umět hosting.

Předgenerovaná statika potřebuje hlavně místo, odkud se soubory rychle doručí návštěvníkům. Serverové renderování potřebuje runtime, který HTML vytvoří pro konkrétní požadavek návštěvníka. A čisté skládání obsahu v prohlížeči je riziko pro veřejný obsah, protože crawler sice JavaScript umí, ale nechce na tvém webu trávit víc času, než musí. (A naopak to může být nejlepší volba pro interní aplikaci.)

Ať už je web statika, nebo běží na serveru, někde musí žít a odněkud se rychle doručit. To je hosting a CDN: místo, kde web bydlí, plus síť, která ho roznese blíž k návštěvníkům. A aby tě návštěvník vůbec našel, potřebuje hosting DNS, vrstvu, která přeloží jméno na adresu. Některé služby tyhle role spojují do jedné. Cloudflare třeba umí být DNS, cache i hostingová vrstva najednou.

Právě DNS bývá nudná, neviditelná vrstva, na kterou se při spuštění zapomene víc než na cokoli jiného. A když se rozbije, často nepadne web. Padne e-mail. Doména se převede jinam, zdědí výchozí nameservery, MX záznam zůstane na starém místě a pošta je několik dní nedoručitelná, zatímco web si vesele jede. Tahle past čeká přesně v den, kdy máš celej den schůzky.

A pak je tu pipeline, cesta, kterou se změna vůbec dostane z repozitáře na živý web. Nechceš totiž u deploye dělat chyby. Kdysi se to dělalo, že se člověk přihlásil na FTP a přepsal soubor přímo na živém serveru. Žádná historie, žádný náhled, žádná cesta zpět. Trošku podobné to je dneska, když na Cloudflare uděláte deploy přímo přes CLI od sebe z počítače. Git a CI/CD ten proces zkomplikují, ale zase díky tomu všichni v týmu ví, co aktuálně běží. Když nasadíš „skoro všechno" umí to totiž hodně bolet: Knight Capital v roce 2012 nasadila kód na sedm serverů z osmi a za 45 minut prodělala 440 milionů dolarů. U obsahového webu nepůjde o takové částky (uff!), princip je ale stejný. Buď je nasazená celá nová verze, nebo žádná.