Hostujte část webu zdarma u Google
Velké množství webů používá nějaký javascriptový framework. Ať už to jsou malé knihovny typu jQuery nebo Prototype, či velké a komplexní jako YUI nebo ExtJS, jejich přenos na klientský počítač nějaký čas a šířku pásma zabere. Existuje tu však možnost využít infrastruktury webových gigantů, jako je Google.
Nálepky:
Nápad nechat hostovat některé standardní části vlastního webu u cizího providera s velmi slušnou infrastrukturou není nijak nový ani nepochopitelný. Každý, kdo někdy zažil, byť i v malém, takzvaný Digg efekt, tedy náhlý nápor návštěvníků stránek, ví, že v takových chvílích se každý načítaný skript, každá ikonka, každý soubor se stylem počítá, a podobný nápor zájemců se velmi rychle změní z radostné události na cosi srovnatelné s DDoS útokem.
Je tedy jen logické vyčlenit některé „statické“ elementy na webové stránce (typicky obrázky, skripty, soubory se styly apod.) na jiný stroj, na kterém nemusí běžet např. žádný skriptovací jazyk, stačí jen lehký HTTP server. S rozšířením cloudových služeb a s tím, jak jsou stále dostupnější služby CDN, se objevila i možnost umístit tyto prvky na nějaký „cloudhosting“ – například Amazon S3 (např. Twitter takto ukládá profilové fotky, z českých serverů využívá ukládání na S3 třeba server Bloguje, který z CDN Amazonu linkuje stylopisy pro blogy).
Kromě elementů, které jsou „unikátní“ pro váš web (obrázky, stylopisy), lze použít tuto techniku i pro skripty (jen je potřeba dávat pozor na Same Origin Policy). Obzvlášť lákavá je tato myšlenka v případě nějakých standardních skriptů – tedy zejména javascriptových frameworků a knihoven.
Yahoo
Yahoo se před několika lety rozhodlo poskytnout svůj webový framework YUI (Yahoo User Interface) jako opensource. YUI se skládá z dvou hlavních částí: z JavaScriptové knihovny, která řeší některé aktivní prvky pro webové aplikace (widgety apod.), a z CSS frameworku, který se stará o „CSS reset“ a nastavuje pravidla např. pro grid či stylování formulářů.
Zajímavé na YUI je to, že si jej od verze 2.2, která vyšla v únoru 2007, nemusíte instalovat na vlastní server a vaši návštěvníci tedy nepřenášejí spoustu „zbytečných“ dat přes vaši linku. Lze totiž do dokumentu nalinkovat tyto knihovny přímo ze serverů Yahoo, a využít tak zdarma jejich CDN.
Už delší dobu se objevovaly pokusy využít obří infrastrukturu Googlu k něčemu podobnému. Byla používána např. služba Google Code nebo Google Pages. Google nakonec sám nabídl službu „hostování standardních javascriptových knihoven“ v rámci své služby AJAX Libraries API. V současné době můžete ze serverů Googlu přímo linkovat jQuery, jQuery UI, Prototype, Script.aculo.us, MooTools, Dojo, SWFObject, YUI, Ext Core a Chrome Frame.
Proč to dělat?
Takové řešení má své výhody. Výrazně sníží latenci, využívá paralelismus a zlepšuje cachování.
Snížení latence je důsledek toho, že Google (nebo Yahoo) využívají distribučních sítí (CDN), které mají své koncové body (uzly) po celém světě. Pokud bude vaše aplikace hostována v ČR a většina uživatelů bude přistupovat z ČR, pravděpodobně zrychlení nepocítí (možná naopak), ale ve chvíli, kdy začnou přistupovat uživatelé z celého světa, tak se stane geografická vzdálenost od vašeho (jediného) serveru úzkým hrdlem. CDN je tak velmi pohodlnou možností, jak dostat obsah blíž vašim uživatelům (nebo alespoň část).
S tím souvisí i paralelní načítání. Většina prohlížečů má omezen počet spojení pro každý server (je to jednoduchá obrana proti zaplavení serveru požadavky). Pokud je na stránce např. 40 objektů z jednoho serveru, nestahuje je všechny najednou, ale postupně (např.) ve čtyřech frontách. Pokud je na stránce nalinkovaný objekt z jiného serveru (třeba různé měřicí kódy), otevře si pro ně prohlížeč extra spojení a stahuje je zároveň. Pokud tedy nalinkujete JavaScriptové knihovny z Google, nebudou čekat ve frontě na váš server.
Zlepšení cachování souvisí s tím, jak prohlížeče ukládají soubory do cache: Pro každý zdrojový server zvlášť. Pokud tedy přijdete na pět serverů, které používají jQuery 1.4.2, budete mít v cache pětkrát identický soubor jquery-1.4.2.min.js a bude se pětkrát stahovat. Z hlediska cachovacího mechanismu v prohlížeči jde pokaždé o jiný soubor. Pokud by tyto servery používaly např. hostování u Google, stáhl by se jQuery jen při návštěvě prvního serveru, v ostatních případech by prohlížeč poznal, že se jedná o soubor, který v cache už je.
Nevýhody
Výhody jsou zřejmé: Větší rychlost a menší zátěž našeho serveru. Na druhé straně má takové řešení i nevýhody, které mohou být pro někoho banální, pro jiného nepřekonatelné – záleží na přístupu a aplikaci.
Nejzjevnější nevýhodou je závislost na cizím serveru. Tedy na tom, že bude dostupný vždy, když bude dostupný váš server. Což zrovna u velkých CDN bývá splněno. Další nevýhodou je, že jednoho krásného dne se může váš vybraný poskytovatel rozhodnout, a soubor přestane poskytovat.
Ano, to všechno se stát může. Taky se jednoho dne může stát, že Google vypne Mapy, a dvě třetiny mashupů přestanou fungovat… Otázkou je, jestli je toto riziko přijatelné. Pro někoho v žádném případě, pro někoho je banální a výše zmíněné výhody převažují.
Problémem, který není na první pohled zjevný, a o němž lidé, kteří neznají pravidla bezpečnosti, často ani netuší, je, že vložený JavaScript z cizího serveru má možnost dostat se k některým citlivým informacím nebo provádět jiné nekalosti (je to v podstatě „legální“ XSS). Jakýkoli skript, který vložíte do stránky, a nad nímž nemáte kontrolu, je bez diskusí bezpečnostní riziko. A platí to nejen pro výše zmíněné hostování knihoven, ale pro všechny možná počítadla, analytické kódy či widgety, které běží na serveru třetí strany. Otázka je, jestli je toto riziko akceptovatelné. Ale na ni si každý musí odpovědět sám. U firemního webu či webu velké organizace je něco podobného pravděpodobně nepřijatelné, u malého nadšeneckého webu na sdíleném hostingu by vadit nemuselo; naopak by se mohla projevit velmi výrazně výše zmíněná pozitiva.
Pro větší weby stojí za úvahu využít (samo sebou placené) alternativy komerční CDN a jejím prostřednictvím šířit statický obsah webu (obrázky, styly, knihovny, …)
Martin Malý
Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.
Jako další nevýhoda, resp. konkrétní příklad nedostupnosti serveru, může být blokování třeba Google serverů – viz Irán. Pak se dá zkusit použít fallback na lokální kopii JS. Tento problém je ale pro většinu webů patrně nepodstatný…
A jedna drobná připomínka – onen Digg efekt se původně jmenuje Slashdot efekt :-).
Pokud používám hostování jQuery nebo jiné knihovny na jiném serveru, udělam tu změnu až při spouštění na ostrou lokaci.
Velmi často vyvíjim aplikace a stránky offline a ze začátku jsem se divili, proč si nenačtu YUI reset CSS nebo jQuery.
Zajímavé. V té souvislosti mě napadá otázka: nechystá se ve světě standardů HTML/JS řešení podobné jako je ve Flashi – cachování knihoven na klientovi? Knihovnu hostuje kdokoliv, ale jakmile je jednou stažena, zůstává na klientovi a je použitelná i pro cizí aplikace (je digitálně podepsaná a díky tomu se na ní pak nevztahuje same-domain bezpečnostní omezení). To by mi přišlo užitečnější než hostování u jednoho giganta…
Hrůzostrašné chování Flashe v tomto ohledu snad nelze dávat jako příklad!
Podívejte se sám, co za informace o Vás Flash nashromáždil a pro jakoukoliv jinou aplikaci ve Flashi napsanou dál poskytne:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html
Flash je hrůza všech hrůz! (bezpečnost/soukromí a realizace runtimů/pluginů)
Tohle myslíte vážně nebo si jen děláte srandu?
Jak jste proboha přišel na to, že uvedené informace má k dispozici „jakákoliv jiná aplikace“? To je stejné, jako kdybyste napsal do Chromu „about:cache“ a začal šířit poplašnou zprávu, že toto má k dispozici jakákoliv HTML aplikace. :)
Stav předsudků o Flashi je na žalostnější úrovni, než jsem si myslel. Uvědomte si, že má-li se HTML a ostatní standardní technologie dostat na úroveň, kdy budou zajímavé pro RIA vývojáře, kteří jsou zvyklí na určitou úroveň z Flashe nebo Silverlightu nebo Javy (což bych si osobně přál), tak se musíte těchto předsudků zbavit a inspirovat se tím, co ve Flashi už dávno je vyřešené. Což se také v mnoha oblastech děje, ale zřejmě ještě ne ve všech (viz můj prvotní dotaz na cachování JS knihoven).
Zajímá-li vás konkrétně problematika bezpečnosti, můžete začít třeba tady:
http://www.adobe.com/devnet/flashplayer/articles/flash_player_9_security.pdf
Prosím však, abyste si to nejdříve přečetl, a pak nám můžete napsat, co konkrétně je „hrůza všech hrůz“.
Jak to, že mi může flashová „aplikace“ (viz. můj odkaz) vypsat výpis navštívených stránek s flashem? Jsou to data, ke kterým se může dostat nebo ne? (a rozhodně to jsou pro mne citlivá data)
… a dodám, že pro mne je Flash hrůza hrůz.
No protože to není obyčejná aplikace, kterou můžete napsat vy nebo já, ale speciální aplikace, analogická stránkám „about:blabla“. Tomu musíte zkrátka věřit – tak jako věříte tomu, že váš oblíbený browser neposkytuje citlivé informace o vaší historii či nastavení třetím stranám. Zkuste ostatně najít v API, kde byste se k takovým informacím mohl dostat. Jsem v šoku, že někdo žije v domění, že to je ve Flashi běžné. Opakuji – přečtete si o něco o security a privacy modelu Flash platformy. Je to podle mě skvěle navržená architektura, od které ostatně opisoval i Silverlight (viz třeba crossdomain policy soubory, které převzal kompletně i pro sebe jako standard). Mě zajímá, kdy budou k tomu všemu existovat i ekvivalenty v HTML/JS standardech.
No tak pádný argument, že k takovým informacím má při vývoji přístup jen Adobe a to toho nijak nezneužije a tomu že prostě musím věřit jsem snad ani nečekal.
A to nemluvím o tom, že v této kauze prezentovanému sledování nelze žádným způsobem zabránit. To se tyto údaje asi skladují omylem – když to nechce nikdo k ničemu použít.
Svůj názor už opakovat nebudu – stále je stejný.
Ale vždyť k tomu nemá přístup ani Adobe! To, na co koukáte na uvedené stránce, vidíte pouze vy a nikdo jiný. Vy máte zablokované myšlení tím, že daná flashová komponenta je vložena do stránky na adrese http://adobe.com/atd. Je to stejné, jako kdyby byl někde vložený HTML frame a v něm zobrazena stránka „about:cache“, už chápete?
Flash Player skladuje informace o navštívených aplikacích a vaše osobní nastavení soukromí pro tyto aplikace (kterým z nich povolíte přístup ke kameře, ukládání lokálních dat, atd.). Naprosto analogické ke cookies a dalším věcem, které ukládají browsery. Věříte Chromu, že to neposílá do Googlu, a Safari, že to neposílá do Applu?
Zacházení s cookies je snadno ovlivnitelné uživatelem, zacházení s mými informacemi ve Flashi nikoli.
Co který prohlížeč kam posílá se dá určit u těch, jejichž zdrojáky jsou k mání.
Pokud jde o to, jestli a které velké společnosti důvěřuji, pak žádné – ale ze zmiňovaných mi Adobe leží v žaludku zdaleka nejvíc a to nejen kvůli Flashi. (Jejich grafické programy používám už cca. 20 let a některé znám verzi od verze od počátku a opakuji, přestože lepší nástroje bohužel nejsou, tak mě hulvátství při jejich vývoji točí. Na vysvětlenou – patřím mezi uživatele označované zejména tím, jehož jméno se nevyslovuje, jako „ovce“. A vztah Adobe k jejich mateřské platformě je katastrofický. Jistou ilustrací stavu je mimo jiné právě kvalita implemetace Flashe na této platformě. Tuto problematiku tady ale nechci rozvíjet – víc OT vlákno by už asi nemohlo vzniknout.)
Omlouvám se za OT vlákno – končím.
Omlouvám se i panu Šimkovi, ale mě na svou víru neobrátí.
Zacházení s lokálně ukládanými daty můžete ve Flash Playeru ovlivnit stejně jako zacházení s cookies v browseru – viz právě ten settings panel, na který jste odkázal.
Nevím, o jaké mé víře píšete, ale mojí vírou jsou veškeré RIA technologie. Čím dřív bude použitelnou RIA technologií HTML5, tím lépe (pro vývojáře i pro producenty nástrojů – budete se divit, ale i pro Adobe). Ovšem to je zatím hudba budoucnosti a s klapkami na očích ještě dlouho bude.
Mějte se hezky a na _žádnou_ víru se nikdy neobracejte. :)
Já myslím, že flashem se dá zjistit daleko více věcí než jen historii a to, že se jedná o speciální aplikaci, která běží pouze z webu Adobe je nesmysl. viz.: http://browserspy.dk/fonts-flash.php
Pletete dvě věci dohromady.
1) Ano, seznam fontů, které má uživatel k dispozici, může zjistit jakákoliv vaše flashová aplikace. Stejně jako spoustu dalších informací – jestli máte kameru, jaké máte rozlišení, kolik máte barev, jaký máte OS… To jsou běžné věci využívané při tvorbě aplikací. Je to součástí API ActionScriptu.
2) O čem je řeč v tomto threadu – nastavení soukromí – co která aplikace může ukládat na váš disk, která aplikace má přístup ke kameře, apod. – a pochopitelně seznam aplikací, které jste navštívil (pro účely právě nastavování soukromí) samozřejmě vidíte pouze vy jako uživatel. Neexistuje API v ActionScriptu, kterým byste se na to dostal jako vývojář.
Zrovna jsem se dozvěděl, že jelikož asi víc lidí má mentální problém s tím, že ten settings panel vygenerovaný Flash Playerem je zobrazený v rámci stránky na adobe.com (což je proto, aby k tomu byla hezky pod tím online dokumentace), tak se uvažuje, že v budoucích verzích Flash Playeru to bude vyskakovat do nativního popup okna (podobně jako v Silverlightu). Vyjde to nastejno, ale pomůže to paranoidním jedincům.
Skvele navrhnuta architektura?
Tym myslite ten Flash, ktory dlhu dobu nemal 64-bit ekvivalent pre Linux a ten Flash, ktory pri obycajnom prehravani videa na YouTube ‚zhavi‘ moje CPU na 90% vykonu, pricom taky vykon CPU nie je potrebny ani pri BZ2 kompresii a sucasnom sifrovani dat do remote-zalohy? ;-) ;-)
Flash bol pokrokova myslienka v case, ked vznikal, ale ja sa modlim za co najskorsi nastup HTML5. V ziadnom pripade Flash neodporucam ani svojim klientom, pokial nahodou nechcu nejaku hru alebo extremne graficky (gycovo) spracovany web…
Skvěle navrženou architekturou nemyslím implementaci, ale skutečně architekturu, a konkrétně mluvím o bezpečnosti (viz dokument odkazovaný výše), nastavování soukromí a koncepci cachování a digitálního podepisování knihoven (čímž toto vlákno začalo). Také držím palce HTML/JS standardům, aby všechny tyto věci co nejdříve vyřešily, protože vývojáři jsou na ně z Flashe zvyklí a krok zpět nikdo nedělá rád.
Zajímavá myšlenka, digitálně podepsané JS knihovny by své výhody měly, ale ve světě HTML5 a dalších otevřených standardů bych tomu moc šancí nedával.
Tak to podepisování neznamená, že to nebude otevřené (stejně jako SSL neznamená, že člověk musí používat nějakou komerční CA, může si udělat svoji nebo používat třeba CAcert.org).
Spíš bych viděl potíž ve verzích – něco jako DDL hell – aplikaci odladím pro nějakou verzi knihovny a nebudu chtít riskovat, že moje aplikace nebude fugnovat, kvůli tomu, že uživatel má jinou verzi → takže budu chtít vynutit jednu konkrétní verzi knihovny. Jiná aplikace bude používat jinou verzi atd. V důsledku tam to třeba jQuery uživatel stejně nebude mít stažené jen jednou, ale několikrát, takže ta úspora až taková nebude (od každé knihovny X verzí, místo aby měl knihovnu pro každou aplikaci).
Inu myšlenka sdílených knihoven je zajímavá, ale nevím, jestli to někomu bude stát za to (řešit verzování, bezpečnost atd.). Spíš bych řekl, že ne, protože dnes lítá po síti tolik zbytečných megabajtů a gigabajtů, že nás ty řádově kilobajty JS knihoven nevytrhnou.
Ten problém verzí ve Flashi známe, ale lepší něco než nic (nedávno např. inicioval Tom Krcha dohodu v rámci české vývojářské komunity, abychom používali jednu konkrétní verzi Flex frameworku, dokud nebude nezbytně nutné přejít na novější). Ve světě JS je to zatím zanedbatelný problém, protože ty knihovny jsou relativně malé, ale vezměte si, až se rozšíří Canvas a vzniknou různé grafické knihovny, herní enginy…
Diky za uzitecny clanek, pane Maly.