
Možno sa inšpirujete nejakou funkčnosťou v tomto blogu a možno naopak - napíšete mi, ako by ste to riešili vy a prečo. Vždy existuje niekoľko spôsosob ako urobiť/implementovať rôzne veci a ja pevne verím, že som nevybral ten najhorší spôsob. Pre neznalých v Node.js len uvediem, že každá Node.js web aplikácia obsahuje sama-v-sebe vlastný webový server.
Každý request podlieha na začiatku jeho spracovania malej analýze. Framework podľa URL adresy overuje, či sa jedná o súbor alebo o klasické trasovanie. Overí to veľmi jednoducho cez regulárny výraz, len skontroluje, či URL adresa obsahuje súborovú koncovku s maximálnou dĺžkou 8 znakov (dá sa to zmeniť) príklad: /img/logo.jpg alebo /app.manifest. Ak sa potvrdí, že sa jedná o statický súbor, tak framework pristupuje k takémuto requestu úplne inak.
Spracovanie statického súboru:
file routesfile routes a vyhodnotenej vyvolá akciu a ďalej už nepokračujecache, či sa tento súboru už spracovalmapping a content-type súboru podľa jeho .extensioncontent-lengthmerging + compression (len .js, .css, .html) a resizing (len obrázky)merging, compression, či resizing tak framework spracovaný súbor uloží do /tmp/ adresáracontent-type, či súbor podlieha GZIP kompresii (ak je povolená)Cachovanie je hlavne kvôli rýchlosti a efektivite, takže podľa relatívnej URL adresy sa dá veľmi rýchlo overiť, či súbor bol spracovaný alebo nie a akú má veľkosť. Framework cache resetuje každých 7 minút (dá sa to zmeniť v configu). Zabudol som poznamenať, že v prípade resize and merge sa súbory z /tmp/ adresára nemažú a framework ich po resetovaní cache znova nespracúva (len overí či existujú v /tmp/ a ak neexistujú spracuje ich znova). V celom mechanizme je ešte implementovaná HTTP cache, či streamovanie cez content-range.
Spracovanie statických súborov sa dá v config vypnúť a zašiel som ešte trošku ďalej - v prípade, že chcete na statické súbory používať napr. NGINX a zároveň používať v Total.js napr. merging, tak framework obsahuje funkciu F.snapshot(relative_url, filename), ktorá dokáže interne vytvoriť request a zároveň jeho obsah uloží do súboru na hocijaké miesto na disku.
Pri návrhu view engine som čerpal trošku inšpiráciu z ASP.NET MVC - Razor Engine, ale dovolím si povedať, že som ho urobil sofistikovanejšie ako v tej dobe bol Razor Engine (o tom inokedy). Pri vyvolaní render view sa dejú naozaj čudné veci:
views/index.html (príklad):
View Engine načíta obsah súboru do pamäti a následne začína jeho analýza:
@(Title) v celom obsahu z viewHASH a pokúsi sa ho vyhľadať v resource (viď poznámka)resource, tak text v obsahu je nahradený textom z resourceresource, tak algoritmus ponecháva aktuálny textview engine compiler, ktorý oddelí statický text od dynamických hodnôt@{title}function a skompiluje vyparsovaný obsahRELEASE mód, tak výsledok kompilácie (funkcia) sa uloží do cache po dobu 7 minút (dá sa to zmeniť)Hodnoty v cache statických textov:
Framework vytvorí zkompilovaný view pre každý jazyk v akom bol volaný, takže pokiaľ nie je request na daný view, tak view sa nekompiluje. Celý algoritmus je trošku sofistikovanejší, ale na predstavu vyššie uvedený popis absolútne stačí.
Poznámka: HTML minifikácia minifikuje aj inline <script> a inline <style>.
Niekedy v blízkej budúcnosti sa budem snažiť opísať ešte generovanie dynamického obsahu, ktoré obsahuje tiež sofistikované algoritmy. Hlavne popíšem ako funguje middleware, authorization, cache pre routes, aplikovanie flagov, spracovanie binárnych dát (rozujem upload) až po vyvolanie controllera.