i løbet af de sidste to år har jeg hørt udtrykket isomorfe Internetapps nævnt på en positiv måde oftere og oftere. Også i løbet af denne tid, jeg har gjort nogle tænker mig om teknikken. Min konklusion er, at isomorfe Internetapps er noget, der ikke vil tilføre værdi for mig eller de typiske organisationer, jeg arbejder for. Flere ting har ført mig til denne konklusion.
men før jeg lister årsagerne, lad mig først understrege, at jeg tror isomorfe javascript-biblioteker (dvs.lodash.js) er fantastisk. Jeg tror også, at isolerede isomorfe komponenter kan være værdifulde, for eksempel en live opdateret aktiemarkedsindikator.
årsagerne til, at jeg ikke tror, at isomorfe apps er værdifulde for mig eller de organisationer, jeg arbejder for, er:
- internetserveren kan nu kun skrives i javascript
- isomorfe Internetapps kan aldrig være progressiv forbedring for ikke-trivielle apps
- blokering vs ikke-blokerende datastrøm
- time-to-interaction and the Uncanny Valley
- mobile enheder fryser under parsing af javascript
- dine bedste udviklere har nu travlt med ikke at producere værdi
jeg vil starte med en definition af isomorfe internet apps. En isomorf app er en app, hvor programkoden ikke har nogen viden om, hvor den køres. I stedet opbevares denne viden i infrastrukturkoden og gør det muligt for applikationen som helhed at køre på både klientsiden og serversiden.
- internetserveren kan nu kun skrives i javascript
- isomorfe Internetapps kan aldrig være progressiv forbedring for ikke-trivielle apps
- blokering vs ikke-blokerende datastrøm
- Time-to-interaction og Uncanny Valley
- Mobile enheder fryse under parsing af javascript
- dine bedste udviklere har nu travlt med ikke at producere værdi
- Resume
- anerkendelser
internetserveren kan nu kun skrives i javascript
hvis klientkoden og serverkoden er den samme (og klienten kan i dag kun fortolke javascript), så er vi begrænset til kun at bruge javascript på serveren. Jeg kan godt lide node.js meget, men jeg synes, det er bedre at være åben for alternativer i fremtiden, i mit perspektiv.
isomorfe Internetapps kan aldrig være progressiv forbedring for ikke-trivielle apps
JavaScript på klientsiden har adgang til en maskine i hukommelsestilstand, der giver mulighed for et finkornet niveau af interaktion med en meget lav latenstid (under millisekunder). Det samme gælder ikke for HTTP-tilstandsmaskinen, som drives af link klik og formularindlæg.
for mig er progressiv forbedring at starte med en baseline, der er tilgængelig for alle mulige enheder/bro.Serere, fra gammel til nuværende til fremtid. I praksis betyder dette en basislinje for gengivelse på serversiden. Forbedringstrinnet er en forretningsbeslutning om, hvor stedet/appen skal forbedres for at øge værdien. Med andre ord sker forbedringen i applikationskoden (specifik) og *ikke* i infrastrukturkoden (generel), bortset fra optimeringsteknikker som f.eks.
vejen for isomorfe Internetapps for at få progressiv forbedring er at tage denne finkornede in-memory state-maskine og “oversætte” den til kun at bruge links og formularer. De eneste tilfælde, Jeg kan se, hvor dette er muligt, er, hvor du ikke havde brug for fuld klientsidegengivelse i første omgang, men i stedet kunne stole på ovennævnte optimeringsteknikker og klientsidekomponenter til forbedring af oplevelsen (dvs.en kalenderkomponent til et inputfelt til en dato).
en variant af denne løsning er ikke at understøtte alle klient-side tilstand/overgang i server-side tilstand maskine. I dette tilfælde bør dette være en forretningsbeslutning, der skal afspejles i applikationskoden, hvilket gør applikationskoden miljøfølsom, hvilket strider mod ideen om isomorfe Internetapps.
vejen for isomorfe Internetapps for at få progressiv forbedring er at tage denne finkornede in-memory state-maskine og “oversætte” den til kun at bruge kun links og formularer.
blokering vs ikke-blokerende datastrøm
gengivelsessekvensen for serversiden og klientsiden er forskellige: serversiden blokerer, og klientsiden blokerer ikke.
Forestil dig, at vi skal gøre to anmodninger til nogle tjenester for at gøre en visning. Vi kan gøre disse anmodninger parallelt.
på serversiden, hvis den anden anmodning vender tilbage først, kan den gengive den del af svaret, men skal blokere for at sende disse bytes, indtil den første har gengivet og returneret den del af svaret tilbage til bro.sereren.
på klientsiden findes denne begrænsning ikke: de to svar kan håndteres og gengives uafhængigt.
jeg tror også, at ovenstående repræsenterer de enkleste eksempler. Forestil dig, at du har et træ af komponenter, hvor rodkomponenten er smart (se præsentations-og Containerkomponenter for en forklaring af smarte/dumme komponenter), efterfulgt af et par niveauer af dumme komponenter, og derefter mindst en bladkomponent, der er smart.
infrastrukturen har derefter brug for en måde at sikre, at smart leaf ‘ s Kontekst ikke går tabt, så vi mister kontrollen over den blokerende/ikke-blokerende udførelse, afhængigt af server/klienttilstand. En måde at løse dette problem på kan være at få hele programmet til at blive udført i en gratis monad, der repræsenterer udførelsen som data, der senere skal fortolkes. En anden løsning kan være at bruge en eller anden form for besøgsmønster og lade komponenter erklære, hvilke data de har brug for (svarende til Tutorial: håndlavede en isomorf Reduks-applikation (med kærlighed)). Sidstnævnte er sandsynligvis nemmest. Mit punkt er, at problemet med forskellige blokeringstilstande sandsynligvis er meget mere kompliceret, som man oprindeligt forestiller sig.
et alternativt design er at have en regel, der siger “kun rodkomponenten kan være en smart komponent”, svarende til hvordan du kan bruge IO monaden i Haskell, holde bladene rene og kun have bivirkninger på øverste niveau. Jeg synes, dette design er godt på serversiden, men ikke på klientsiden: en komponent på klientsiden skal være i stand til at indlæse sine egne data i mindst nogle scenarier, for eksempel vedrørende sociale medierelaterede komponenter. At have en regel, der aldrig tillader disse scenarier, virker meget uproduktivt.
Time-to-interaction og Uncanny Valley
med den isomorfe app-tilgang vil der være en tid, hvor brugeren ser grafiske elementer på skærmen, der ser ud til at være interaktive, men ikke er. med andre ord, tiden mellem, hvornår bro.sereren har gengivet serverresponsen, og når javascript hentes, analyseres og udføres. Dette kaldes “Uncanny Valley”eller” Potemkin Village”.
se dette kvidre og svarene for flere detaljer.
Mobile enheder fryse under parsing af javascript
på en “typisk” mobiltelefon, får du 1MS UI tråd stall per 1KB javascript, ifølge denne kvidre. Malte Ubl er teknisk leder af AMP-projektet, så jeg formoder, at han ved, hvad han taler om.
dine bedste udviklere har nu travlt med ikke at producere værdi
isomorfe apps er en tilgang, der kræver et højt udviklingsniveau. På mange områder (i det mindste i den vestlige verden) er det svært at finde og rekruttere højtuddannede udviklere. At vælge at udvikle isomorfe Internetapps tildeler disse udviklere til at gøre noget, som jeg sætter spørgsmålstegn ved, producerer enhver forretningsværdi overhovedet. Der er bedre måder at bruge deres tid på.
Resume
isomorfe apps begrænser dit sprog/platformvalg til kun at være javascript. Det har ambitionen om at give mulighed for progressiv forbedring, men det kan ikke levere. Det introducerer et højt niveau af teknisk kompleksitet på grund af forskellene i blokering/ikke-blokerende datastrøm. Det introducerer et tidsvindue, hvor tingene ser ud til at være interaktive, men ikke er (The Uncanny Valley). En stor mængde javascript fryser også mobile bro.sere, med tommelfingerreglen om, at 1 KB javascript betyder 1 ms stoppet UI-tråd. Og da det kræver et kompliceret programdesign, tager det værdifuld tid og kræfter fra dine bedste udviklere – der er bedre måde at bruge deres tid på.
endelig vil jeg understrege, at dine oplevelser kan være forskellige fra mine. Måske er der scenarier, hvor isomorfe apps er gode. Men de er ikke en sølvkugle til at bygge bro mellem fordele på serversiden og fordele på klientsiden, mens de ikke får nogen af ulemperne ved begge tilgange.
hvad synes du? Har du overvejet at “gå isomorf”? Har du nogen tanker om udfordringer og omkostninger? Hvordan håndterer du dem?
anerkendelser
tak til Oskar Vægstrl. Oskar gennemgik også dette indlæg-tak Oskar.
