först av allt, du är troligen en vanlig användare av Single Page Applications (Spa) redan.
ensidiga applikationer är ett utmärkt verktyg för att göra otroligt engagerande och unika upplevelser för dina användare.
några exempel på en sida är Gmail, Google Maps, AirBNB, Netflix, Pinterest, Paypal, och många fler använder spa för att bygga en flytande, skalbar upplevelse.,
men i det förflutna Spa har lämnat marknadsförare ute i mörkret när det gäller att hantera innehåll. Lyckligtvis är det nu möjligt att para ihop ditt SPA med rätt CMS för att ge både utvecklare och marknadsförare den kontrollnivå de behöver.
Vad är ensidig ansökan?
enkelsidig applikation (SPA) är en enda sida (därav namnet) där mycket information förblir densamma och endast ett fåtal bitar behöver uppdateras åt gången.,
till exempel, när du bläddrar igenom din e – post kommer du att märka att inte mycket förändringar under navigeringen-sidofältet och sidhuvudet förblir orörda när du går igenom din inkorg.
SPA skickar bara vad du behöver med varje klick, och din webbläsare gör den informationen. Detta skiljer sig från en traditionell sida belastning där servern åter gör en hel sida med varje klick du gör och skickar den till din webbläsare.
denna bit för bit, klientsidan metod gör laddningstiden måste snabbare för användare och gör mängden information en server har att skicka mycket mindre och mycket mer kostnadseffektiv., En win-win.
Vad är enkelsidig applikationsarkitektur? Hur fungerar det?
applikationen på en sida är en webbapplikation eller webbplats som interagerar med användaren genom att dynamiskt skriva om den aktuella sidan, istället för att läsa in hela nya sidor från servern.
detta tillvägagångssätt ogiltigförklarar avbrott i användarupplevelsen mellan på varandra följande sidor, vilket gör att programmet beter sig mer som ett skrivbordsprogram.
på de flesta webbplatser finns det mycket upprepande innehåll.,
en del av det förblir densamma oavsett var användaren går (sidhuvud, sidfot, logotyper, navigeringsfält, etc), en del av det är konstant i bara ett visst avsnitt (filter barer, banners), och det finns många upprepande layouter och mallar (bloggar, självbetjäning, Google mail setup nämns ovan).
ensidiga Program dra nytta av denna upprepning.
låt oss säga att din syn på webbplatsen är en målning av ett hus och ett träd. Traditionella, flersidiga webbplatser målar hela bilden för dig på servern och skickar den till din webbläsare.,
Spa ger dig paint-by-numbers guider för Webbplatsen, inklusive de upprepade guider du sannolikt kommer att använda, och sedan rör rätt färg (data och innehåll) för att fylla i mallen.
hur som helst ser du samma träd, men Spas hastighet kommer in när du begär nytt innehåll – som att klicka på ”nästa”, filtrera resultat, öppna ett mail eller – i den här lilla metaforen – be om att se ett annat träd.
på en traditionell webbplats skulle din begäran om ett nytt träd få servern att måla om hela bilden och skicka tillbaka den.,
med en enda sida Program, servern säger ”Hej, jag har ett nytt träd för dig, men du har redan fått huset så bara lämna det samma”, sedan skickar du uppdaterade instruktioner för ett nytt träd och färgen för att göra det.
genom att överföra målningsarbetet (sidåtergivning) från servern till klienten (du) kan sidan skrivas om dynamiskt, istället för att gå igenom en hel omladdning.
Detta gör saker mycket snabbare.,
fördelar med ensidiga applikationer
det finns många fördelar med spalösningar som förbättrad applikationsprestanda och enhetlighet och minskad utvecklingstid och infrastrukturkostnader.
genom att separera presentationen från innehåll och data kan utvecklingsteam arbeta med olika hastigheter samtidigt som de fortfarande integreras för den övergripande lösningen. SPA är bra för att göra lyhörd design för mobil, skrivbord och surfplatta.,
Single Time File ladda varje HTML, CSS, JS
single Page ansökan, efter den första sidan belastning, servern inte skicka någon mer HTML till dig – du ladda ner allt rätt i början.
servern skickar en skalsida och din webbläsare gör användargränssnittet (UI).
då, när du klickar runt, skickar SPA tillbaka förfrågningar om data och markup, servern skjuter tillbaka de råvaror som behövs, och din webbläsare tar det och gör en Uppdaterad UI – utbytbara bitar utan att någonsin behöva uppdatera hela sidan.,
denna snabba utbytbarhet gör Spa otroligt användbar på sidor som är mycket navigerade och använder upprepade mallar.
inga extra frågor till servern
eftersom servern inte behöver spendera tid& energi gör hela ritningen, SPAs sänka effekten på dina servrar totalt sett – vilket innebär att du kan spara pengar genom att använda mindre servrar för samma mängd trafik.
snabb och lyhörd front-end byggd
tillsammans med den snabbare prestandatiden som förklaras ovan, låter SPAs också utvecklare bygga front-end mycket snabbare.,
Detta beror på Spa: S frikopplade arkitektur, eller en separation av back-end-tjänster och front-end-skärm.
många affärskritiska funktioner ändrar inte så mycket på baksidan.
hur dina kunder loggar in, registrerar, köper och spårar order kan ändra det är ”look” eller presentation från tid till annan, logiken och data orkestrering bakom det är ganska konstant – och du vill inte riskera att förstöra det.
på samma sätt kan ditt råinnehåll och dina data förbli desamma men hur du vill visa det skiljer sig åt.,
genom att frikoppla den back-end logiken & data från hur det presenteras gör du det till en ”tjänst”, och utvecklare kan bygga många olika front-end sätt att visa och använda den tjänsten.
med en frikopplad inställning kan utvecklare bygga, distribuera och experimentera med front-end helt oberoende av den underliggande back-end-tekniken.
de utformar hur de vill att användarupplevelsen ska se ut och känna, och sedan dra in innehåll, data och funktionalitet genom dessa tjänster.,
Detta görs med hjälp av API: er, som är en standarduppsättning av regler mellan applikationer om hur de kommer att strukturera, utbyta och montera data.
denna API-inställning låter utvecklare arbeta snabbt på användargränssnittet utan risk för affärskritiska back-end-tekniker.
förbättrade användarupplevelser
eftersom fler och fler funktioner är byggda som modulära tjänster (en mikroservice arkitektur) som kan uppdateras oberoende, blir det lättare att experimentera med hur de visas och används.,
Spas ramar är bra för att leka med dessa tjänster för att skapa engagerande, dynamiska och även animerade användarupplevelser.
många människor gillar bara att utvecklas på ett visst programmeringsspråk (många spa-ramar använder javascript) och tack vare API: er kan de Spa du bygger på ett språk fungera lyckligt med back-end-tjänster som utvecklats på olika språk.
enkelsidig applikation med vinkel vs React vs Ember vs Vue?,
Angular och React (och många andra som Ember och Vue) är ramar som utvecklare använder för att skapa Spa effektivt och vältaligt.
enkelt uttryckt, dessa ramar är en samling av återanvändbara komponenter, som många utvecklare har bidragit till, som följer en definierad uppsättning av byggregler.
om du tänker på det som att bygga ett hus, kan du blanda upp leran, torka tegelstenarna, gruvan och mögla stålet själv – eller du kan använda tegel och rör andra människor har redan utformat och fokusera din tid på vad som gör ditt hus unikt.,
När det gäller skillnaderna mellan dem alla, Jag är ingen expert (men den här killen verkar vara), men en stor sak om spa och de ramar som stöder dem är att tack vare API: er, med rätt integrationer kan du använda vilken ram du föredrar med din andra API-aktiverade teknik.
varför enkelsidiga applikationer och CMS var historiskt en svår Parning
När du använder Spa kan utvecklare tänka på upplevelsen som en” app ” men besökaren kommer fortfarande att tänka på det som en webbsida, och där det finns en webbsida finns det ett marknadsföringsteam som kliar för att optimera det.,
eftersom Spa är appar som kräver utvecklingsarbete för att tinker med displayen & leverans av upplevelsen, marknadsförare måste gå tillbaka till den digitala stenåldern (aka 90 – talet) och be om utvecklingshjälp för varje tweak-orsakar oundvikliga flaskhalsar.
bort redigeringsverktyg marknadsförare används för att
CMS redigeringsfunktioner marknadsföringsteam förlitar sig på (live förhandsvisning, dra-och-släpp, WYSIWYG redigering, etc) är vanligtvis knutna till leverans tier I CMS.,
med spa bestäms leveransen av SPA och innehållet lagras helt enkelt i CMS på vanligt sätt som API: erna kan läsa. Eftersom spaet återges på framsidan, har back-end CMS ingen aning om hur det ska se ut och kan därför inte snurra upp en förhandsgranskning.
så CMS-användare hamnar fast med en mycket daterad strategi-fyll i ett formulär, korsa fingrarna, tryck publicera och gå och se hur det ser ut live.
för att återgå till vårt exempel paint-by-numbers lagrar CMS det råa innehållet (färgen) och spaet har guiden paint-by-numbers om hur innehållet ska se ut., Förhandsgranskningen har inte den här guiden, så kan inte ta reda på hur innehållet ska se ut.
Detta är en ren ”huvudlös” leverans av innehåll (aka, det har inte CMS leverans tier som ett ”huvud”). Det är bra för att utveckla snabbt, men lite grov för marknadsförare som vill ändra webbplatsen på egen hand utan att behöva koda.
Vid sidan av det används marknadsförare för att tänka på saker i ”sidor”, men eftersom ett SPA är en enda sida som sidbyggnads-och redigeringsfunktionerna inte behöver vara tillgängliga.,
om de vill ha en ny ”sida” (en ”rutt” i ett SPA), eller vill att vyn ska se annorlunda ut, måste de Fråga en utvecklare.
gjorde det svårt att återanvända innehåll
det här problemet kommer från två kärnorsaker, en med föråldrade CMS och den andra från SPA design.
För det första finns det vissa CMS där det helt enkelt inte finns en de-koppling av hur ditt innehåll ser ut och hur det lagras.,
eftersom lagring av innehåll inte är i en standard, presentation neutralt format SPA kan inte använda den på API-baserade sätt vill.
det här är inte bara ett problem när du använder Spa naturligtvis gör den här typen av CMS-inställning det omöjligt att återanvända innehåll över kanaler i allmänhet.
eftersom innehållet är knutet till hur det visas( ett sidbaserat system), kan Vanliga frågor du lägger på din webbplats inte bara utnyttjas för att någon ska bläddra igenom på sin smarta klocka – du måste lagra samma innehåll på två olika sätt.,
SPA behöver ett innehållsbaserat CMS för att fungera korrekt, så att det kan dra råinnehåll och visa det hur det vill.
på SPA-sidan kommer svårigheten från det faktum att många webbplatser kommer att bli en hybridinställning.
medan du kanske vill ha vissa delar som ett SPA, kanske du vill att andra ställer in på traditionellt sätt (ofta bättre för SEO), och det måste finnas en sammanhängande känsla mellan dessa.
om din inställning är två hinkar med innehåll, bitar för den traditionella webbplatsen och SPA, att sammanhållningen kommer att bryta., Du behöver innehåll som fungerar över allt.
svårt med anpassning / relevans
SPAs ta tag i innehåll på ett ”service” sätt, så att det är lite nugget av innehåll utan mycket sammanhang – inte en stor hjälp i relevant leverans.
utöver det gör många CMS deras anpassning antingen sida baserad (inte till hjälp i ett SPA), eller på klientsidan-och de javascript – personaliseringsreglerna spelar inte mycket snyggt ovanpå spa javascript. Alltför många kockar i Personalisering kök om du vill.
är marknadsförare dömda för alltid i en SPA-Värld?
självklart inte!, Du behöver bara ett CMS som har en arkitektur redo för spa-användning.
en som är API-baserad, frikopplar innehåll från presentation, kan arbeta med SPA för att ge en Live förhandsvisning & redigeringsverktyg, stöder en hybrid setup, och gör Personalisering på serversidan.
I nedan delar jag ska gå igenom hur Bloomreach gör just det.
-
hur Bloomreach erbjuder enkelsidig applikation för utvecklare och marknadsförare
-
anpassning och Hybridstöd för enkelsidiga applikationer