Server Side Includes je technologie z 90tých let, kdy byla implementována do NCSA HTTPd serveru. Je to v podstatě takový předchůdce PHP. Zde zkusím popsat důvody, proč takovou takovou technologii použít.
V tomto článku se záměrně budu stranit všem CMS a jiným systémům, které hůře či lépe, snadněji či komplikovaněji, umí obsloužit problém, který SSI řeší. Nepočítám tak s uceleným systémem, který generuje výsledné HTML stránky při vyžádání, i kdyby k tomu používal cache.
Zaměřuji se také na vlastním řešení, resp. hostovaném na vlastním serveru. Záměrně tedy ignoruji služby, placené i zdarma, který podobný problém řeší.
Server Side Includes, zkráceně SSI je velmi jednoduchý způsob, jak skládat stránky na stranu serveru. Typicky, kdy všechny stránky mají jednotnou hlavičku a patičku, a není tak nutné mít každou stránku na serveru uloženou celou, ale jen její část. Při změně hlavičky, nebo patičky, pak stačí upravit jen příslušný soubor. SSI však obsahuje i jednoduchý způsob skriptování. Zná podmínky, a umí pracovat s některými hodnotami. Lze tak vytvořit stránku, která mění svůj obsah na základě data, nebo prohlížeče.
Zajímavá je podobnost s příběhem programátora Rasmuse Lerdorfa, autora PHP, tedy PHP Hypertext Preprocessoru. PHP na svém počátku dělalo vlastně to samé, a vzniklo z podobného důvodu. Zda Rasmus o SSI neslyšel, nebo mu bylo nedostatečné netuším.
SSI umí volat i programy na straně serveru, což je samozřejmě problematická záležitost, ale umožňuje to do stránky vložit výstup libovolného programu.
I dnes se najdou stránky, které jsou převážně statického obsahu. Tedy v dobách, kdy se dynamičnost stránek přesouvá na stranu prohlížeče. To co se na stránkách mění, jsou často jen hlavičky nebo patičky, které jednou za čas mají jiné logo, datum, copyright nebo odkaz na další stránku.
Pokud pomineme výše zmíněný systém na správu obsahu, který umí ve své mašinérii procesů generovat výsledné HTML, existují v podstatě dvě možnosti:
Generovat HTML na straně serveru pomocí CGI, SSI, PHP, Pythonu, Lue nebo jiným systémem.
Před-generovat si stránky při změně a nahrávat všechny změněné soubory na server.
V případě, že jde o malé osobní stránky, a jejich počet je limitně omezený, je druhé řešení schůdné. V případě ale, že by šlo o blog plný článků, nebo nějakou Wiki, či jiný rozmanitý web, aktualizovat větší množství stránek bude velmi náchylné na chybu.
Malé okýnko efektivity
Z hlediska vysokého výkonu, je mimochodem vydávání čistě statických hotových stránek velmi efektivní záležitostí, které většina webový serverů podporuje. Jde o speciální systémové volání sendfile, které v podstatě "přemapuje" soubor na disku na síťové spojení s klientem. Webový server tak odesílá data přímo z disku, aniž by je sám četl nebo dokonce analyzoval.
Je fér dodat, že toto systémové volání obsahuje systém Linux a FreeBSD, u ostatních buď není implementováno, nebo je obejito jiným způsobem.
Tak či onak, v případě SSI tato efektivnost padá, protože server musí obsah souboru analyzovat, a nad ním provádět patřičné operace. Znamená to, že generování obsahu na straně serveru bude vždy méně efektivní, než vydávání statických stránek.
V dnešní době vnímám několik směrů kterými se "programování", resp. sestavování webových stránek vyvíjí.
PHP
Jak jsem uvedl výše, šlo o v podstatě pokračování SSI. V dnešní době je ale PHP komplexní programovací jazyk s objekty a celou řadou rozšíření, které jsou pro webový vývoj potřeba. Kdysi se PHP, zejména na straně Apache serveru, startovalo jako součást nového procesu serveru. Dnes i díky paměťové náročnosti projektů, běží v samostatném procesu, a podporuje různé cachovací techniky. Systémy, které jsou v něm napsané dávno nevypadají jen jako obohacené HTML stránky o dynamický obsah.
PHP, stejně jako ostatní jazyky, má různé frameworky a šablonovací knihovny. A patří mezi stále velmi používané jazyky na celém světě, byť se poslední dobou programátoři orientují spíše jiným směrem.
Python
Python, sice není primárně určen pro tvorbu webů, ale jeho popularita stále roste. Podobně jako PHP, Python bylo možné provozovat na Apache serveru speciálním mod_python modulem. Ten ale už dávno není populární, byť stále existuje i pro nové verze Pythonu.
Naopak, Python stránky běží v paměti celou dobu jako tzv. WSGI aplikace. A z hlediska provozování Python stránek tak v podstatě (mima specifických konfigurací), zabírá místo v paměti ať už na stránky někdo chodí nebo ne. Nutno podotknout, že tento princip lze použít s většinou programovacích jazyků, které Vás pro tvorbu webu ani nenapadly.
JavaScript
O tzv. fullstack pozicích si myslím své, a rozebíral sem to např. zde. Nicméně, ano, zejména díky Node.js technologii je dnes běžné generovat HTML stránku na straně serveru. Výhodou je, že uživatel dostane stránku již s daty, na které se explicitně nemusí doptávat. A ano, k diskuzi může být, zda je lepší aby se sestavení stránky konalo na straně prohlížeče a na všechny data se pak explicitně doptával serveru samostatně, nebo zda je výhodnější mu tu stránku prostě sestavit.
Lua
Lua je zajímavý programovací jazyk, a možná to je mým zájmem o tento programovací jazyk, nebo tím, že Lua se jako skriptovací jazyk snadno a často implementuje do aplikací, ale tento jazyk má i na webu své místo. Protože podobně jako se jím dají skriptovat hry, k tomu je jazyk hojně využíván, dá se tímto jazykem skriptovat i konfigurace webového serveru Nginx nebo Lighttpd.
Vedle konfiguračních možností, samozřejmě lze generovat stránky pomocí tohoto jazyka všemi běžnými způsoby, známými z PHP nebo Python světa. Tedy jak běžící interpretr, nebo samostatná Lua aplikace. Lua jako interpretr je velmi malý, a protože je kompilovaný z ANSI C, není primárně objektový, což ale neznamená, že s objekty neumí pracovat.
Stran programování bych Lua jazyk spíše postavil mezi SSI a dnešní PHP, nicméně tím jazyk rozhodně nechci podceňovat!
Server Side Includes podpora je v serverech velmi rozmanitá. Jejich plná podpora by měla být v Apache serveru. Nginx obsahuje velmi slušnou podporu, a Lighttpd podporuje jen SSI komentáře v hlavní stránce, nevykonává tedy kód ve vnořených stránkách. Zajímavá je i podpora v uWsgi serveru, který slouží zejména jako HTTP brána pro aplikace v různých jazycích. Jeho podpora SSI se ale zdá být titěrná.
Každý server pak může, a často obsahuje nějakou část vlastních tagů, nebo naopak nějakou část z původních záměrně nepodporuje. Stejně tak má každý server vlastní konfiguraci SSI podpory.
Vedle standardních HTTP serverů, existují i různé implementace malých serverových aplikací, napsaných v různých jazycích. Otázka je, zda dává smysl implementovat SSI v jiném jazyku, zvlášť pokud dotyčný jazyk má vlastní, vyspělejší šablonovací nástroje. Určitě pro snazší hostování již existujících SSI stránek.
Pro své osobní stránky a několik privátních Wiki stránek, jsem zkoušel, plánoval, nebo již používám SSI. Byť je to z dnešního pohledu stařičká technologie, stále má své místo. Protože ale provozuji webové servery dle účelu, budu se nejspíš přiklánět k nějakému řešení generovat stránky na vyžádání komplexním nástrojem. A to zejména proto, že jsou některé mé stránky generovány z Restructured Textu, případně z MarkDownu.
© 2023 Ondřej Tůma McBig. Ondřej Tůma | Based on: Morias | Twitter: mcbig_cz | RSS: články, twitter