6 Důvody isomorfní webové aplikace nejsou stříbrnou kulkou, kterou hledáte-blog.

během posledních dvou let jsem slyšel termín isomorfní webové aplikace zmiňované pozitivně stále častěji. Také během této doby jsem se trochu zamyslel nad technikou. Můj závěr je, že izomorfní webové aplikace jsou něco, co by pro mě ani pro typické organizace, pro které pracuji, nepřidalo hodnotu. K tomuto závěru mě vedlo několik věcí.

ale než uvedu důvody, dovolte mi nejprve zdůraznit, že si myslím, že isomorfní javascript knihovny (tj. lodash.js) jsou úžasné. Také si myslím, že izolované izomorfní komponenty mohou být cenné, například živý aktualizovaný ukazatel akciového trhu.

důvody, proč nevěřím, že izomorfní webové aplikace jsou cenné pro mě nebo pro organizace, pro které pracuji, jsou:

• webový server může být nyní zapsán pouze v JavaScriptu
• isomorfní webové aplikace nikdy nemohou být progresivní vylepšení pro netriviální aplikace
• blokování vs neblokování toku dat
• čas do interakce a záhadné údolí
• mobilní zařízení zmrazí během analýzy JavaScriptu
• vaši nejlepší vývojáři jsou nyní zaneprázdněni nevytvářením hodnoty

chci začít s definicí izomorfní webové aplikace. Isomorfní webová aplikace je webová aplikace, kde kód aplikace nemá žádné znalosti o tom, kde je spuštěn. Místo toho jsou tyto znalosti uchovávány v kódu infrastruktury a umožňují aplikaci jako celku běžet jak na straně klienta,tak na straně serveru.

webový server lze nyní psát pouze v JavaScriptu

pokud je kód klienta a kód serveru stejný (a klient dnes může interpretovat pouze javascript), pak jsme omezeni pouze na použití JavaScriptu na serveru. Mám rád node.js velmi, ale myslím, že je lepší být v budoucnu otevřený alternativám, z mého pohledu.

isomorfní webové aplikace nikdy nemohou být progresivním vylepšením pro netriviální aplikace

javascript na straně klienta má přístup k počítači v paměti, který umožňuje jemnozrnnou úroveň interakce s velmi nízkou latencí (sub-milisekundy). Totéž neplatí pro stavový stroj HTTP, který je poháněn kliknutími na odkaz a odesláním formuláře.

pro mě je progresivní vylepšení začít základní linií, která je přístupná pro všechna možná zařízení/prohlížeče, od starých po aktuální až po budoucí. V praxi to znamená základní linii Vykreslování na straně serveru. Krok vylepšení je obchodní rozhodnutí o tom, kde vylepšit web / aplikaci pro zvýšení hodnoty. Jinými slovy, vylepšení se provádí v aplikačním kódu (specifickém) a *ne* v kódu infrastruktury (obecném), s výjimkou optimalizačních technik, jako je pjax nebo turbolinks.

způsob, jak isomorfní webové aplikace získat progresivní vylepšení, je vzít tento jemnozrnný stavový stroj v paměti a „přeložit“ jej tak, aby používal pouze odkazy a formuláře. Jediné případy, kdy vidím, kde je to možné, je to, že jste v první řadě nepotřebovali úplné Vykreslování na straně klienta, ale místo toho se mohli spolehnout na výše uvedené optimalizační techniky a komponenty na straně klienta pro zlepšení zážitku(tj. komponenta kalendáře pro vstupní pole pro datum).

variantou tohoto řešení je nepodporovat každý stav/přechod na straně klienta ve stavovém stroji na straně serveru. V tomto případě by se mělo jednat o obchodní rozhodnutí, které musí být zohledněno v kódu aplikace, což činí prostředí aplikačního kódu citlivým, což je v rozporu s myšlenkou Izomorfních webových aplikací.

způsob, jak izomorfní webové aplikace získat progresivní vylepšení, je vzít tento jemnozrnný stavový stroj v paměti a „přeložit“ jej tak, aby používal pouze odkazy a formuláře.

blokování vs neblokující tok dat

sekvence Vykreslování pro web na straně serveru a web na straně klienta se liší: bloky na straně serveru a na straně klienta neblokují.

Představte si, že musíme udělat dva požadavky na některé služby, abychom vykreslili pohled. Tyto požadavky můžeme dělat paralelně.

na straně serveru, pokud se druhý požadavek vrátí jako první, může vykreslit tuto část odpovědi, ale musí blokovat odesílání těchto bajtů, dokud první vykreslí a nevrátí tuto část odpovědi zpět do prohlížeče.

na straně klienta toto omezení neexistuje: obě odpovědi lze zpracovat a vykreslit nezávisle.

také si myslím, že výše uvedené představuje nejjednodušší příklady. Představte si, že máte strom komponent, kde kořenová složka je inteligentní (viz prezentační a kontejnerové komponenty pro vysvětlení inteligentních/hloupých komponent), následuje několik úrovní hloupých komponent a pak alespoň jedna listová složka, která je inteligentní.

infrastruktura pak potřebuje způsob, jak zajistit, aby se kontext smart leaf neztratil, takže ztratíme kontrolu nad blokováním / neblokováním v závislosti na režimu server/klient. Jedním ze způsobů, jak tento problém vyřešit, by mohlo být, aby byl celý program spuštěn ve volném monadu, což představuje provedení jako data, která mají být později interpretována. Dalším řešením by mohlo být použít nějakou formu návštěvnického vzoru a nechat komponenty deklarovat, jaká data potřebují (podobně jako tutoriál: ruční tvorba izomorfní aplikace Redux (s láskou)). Ten je pravděpodobně nejjednodušší. Jde mi o to, že problém různých režimů blokování je pravděpodobně mnohem komplikovanější, než si člověk zpočátku představuje.

alternativní design je mít pravidlo, které říká, že „pouze kořenová složka může být inteligentní komponentou“, podobně jako byste mohli používat IO Monad v Haskellu, udržovat listy čisté a mít pouze vedlejší účinky na nejvyšší úrovni. Myslím, že tento design je dobrý na straně serveru, ale ne na straně klienta: komponenta na straně klienta by měla být schopna načíst svá vlastní data alespoň v některých scénářích, například pokud jde o komponenty související se sociálními médii. Mít pravidlo, které tyto scénáře nikdy neumožňuje, se zdá být velmi neproduktivní.

Time-to-interaction a Uncanny Valley

s přístupem isomorfní webové aplikace, tam bude množství času, kdy uživatel vidí grafické prvky na obrazovce, která se zdá být interaktivní, ale nejsou. jinými slovy, čas mezi tím, kdy prohlížeč vykreslil odpověď serveru a když je javascript stažen, analyzován a spuštěn. Toto se nazývá „Uncanny Valley“ nebo „Potemkin Village“.

viz tento tweet a odpovědi pro více informací.

mobilní zařízení zmrazí během analýzy JavaScriptu

na „typickém“ mobilním telefonu získáte 1ms UI vlákno stání na 1KB javascript, podle tohoto tweetu. Malte Ubl je technický vedoucí projektu AMP, takže mám podezření, že ví, o čem mluví.

vaši nejlepší vývojáři jsou nyní zaneprázdněni nevytvářením hodnoty

isomorfní webové aplikace je přístup, který vyžaduje vysokou úroveň vývojových dovedností. V mnoha oblastech (alespoň v západním světě) je obtížné najít a najmout vysoce kvalifikované vývojáře. Volba vývoje Isomorfních webových aplikací přiděluje těmto vývojářům, aby udělali něco, o čem pochybuji, vytváří jakoukoli obchodní hodnotu vůbec. Existují lepší způsoby, jak využít svůj čas.

shrnutí

isomorfní webové aplikace omezuje výběr jazyka/platformy webového serveru pouze na javascript. Má ambici umožnit postupné zlepšování, ale nemůže to splnit. Zavádí vysokou úroveň technické složitosti kvůli rozdílům v blokování / neblokování toku dat. Zavádí časové okno, kde se věci zdají být interaktivní, ale nejsou (the Uncanny Valley). Vysoké množství JavaScriptu také zamrzne mobilní prohlížeče, s pravidlem, že 1KB JavaScriptu znamená 1ms zastaveného vlákna UI. A protože to vyžaduje komplikovaný návrh softwaru, vyžaduje to drahocenný čas a úsilí od vašich nejlepších vývojářů – existuje lepší způsob, jak využít svůj čas.

nakonec chci zdůraznit, že vaše zkušenosti se mohou lišit od mých. Možná existují scénáře, kdy jsou izomorfní webové aplikace dobré. Nejsou však stříbrnou kulkou pro překlenutí každé mezery mezi webovými výhodami na straně serveru a webovými výhodami na straně klienta, a zároveň nezískají žádnou z nevýhod obou přístupů.

co si myslíte? Uvažovali jste o“isomorfním“? Máte nějaké myšlenky o výzvách a nákladech? Jak se s nimi vyrovnáváte?

poděkování

Děkujeme Oskaru Wickströmovi a Per Ökvistovi za cenné diskuse na toto téma. Oskar také přezkoumala tento příspěvek-děkuji Oskar.