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 routes
file 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 .extension
content-length
merging
+ 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 view
HASH
a pokúsi sa ho vyhľadať v resource
(viď poznámka)resource
, tak text v obsahu je nahradený textom z resource
resource
, 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.