Nonostante tutti i suoi vantaggi, applicare Jamstack ai siti Web di e-commerce con cataloghi di grandi dimensioni e aggiornamenti frequenti comporta molte sfide. Se stai gestendo un sito di eCommerce su una piattaforma di back-end come Salesforce Commerce Commerce Cloud, Magento o SAP-Hybris, probabilmente ne stai già affrontando alcuni.
In questo articolo vengono illustrate le sfide principali nella creazione di siti Jamstack di e-commerce su larga scala e in che modo Layer (ora Edgio) può aiutarvi ad affrontare questi problemi.
Per la versione completa della presentazione del CTO di Layer0 Ishan Anand alla Jamstack Conference 2020, visitate il canale ufficiale di Layer0 YouTube.
Cos’è Layer0 (ora Edgio)?
Layer0 porta i vantaggi di Jamstack nell’eCommerce, accelerando la velocità del sito e semplificando i flussi di lavoro di sviluppo. Trasferendo i dati memorizzati nella cache dall’edge al browser, prima che siano richiesti, Edgio può mantenere i siti Web 5 secondi prima dei tocchi degli acquirenti. Sharper Image, REVOLVE e Shoe Carnival sono solo esempi di siti che sfruttano la piattaforma Layer0 Jamstack per aumentare la produttività degli sviluppatori e distribuire i loro siti Web di secondo.
Quali sono le sfide dell’utilizzo di Jamstack per l’eCommerce su larga scala?
L’utilizzo di Jamstack e Headless per l’e-commerce, in particolare su siti con cataloghi di grandi dimensioni, aggiornamenti frequenti o su piattaforme di e-commerce monolitiche, è in genere associato alla gestione delle seguenti sfide:
- Tempi di costruzione lunghi
- Aggiornamenti frequenti
- Migrazioni complesse dei siti
- Dati dinamici
- Personalizzazione
- Verifica a/B.
- API incomplete
- Architettura Data Pipeline
- Personalizzazioni perse dalle API
- Limiti di connessione al database
- Capacità di squadra
- Integrazione CMS
- Stili incorporati nei contenuti CMS
- Integrazione del flusso di lavoro di backoffice
Creare problemi di tempo e altre sfide su larga scala
Jamstack è dotato di una scalabilità integrata ad alto traffico. Tuttavia, la fase di creazione introduce una nuova dimensione di scala, poiché il rendering statico tipico avviene durante la creazione. Man mano che espandete il vostro sito Web o eseguite modifiche più frequenti, uscite dal punto di riferimento in cui Jamstack è veloce e agile. Il risultato è un attrito in tempo di costruzione. È facile spazzare il problema sotto il tappeto se stai lavorando su un piccolo sito, ma non è il caso del tipico sito di eCommerce.
Un’altra cosa importante da ricordare è che i siti sono creati tanto da non sviluppatori quanto da sviluppatori. Poiché i contenuti, il marketing e il merchandising cambiano costantemente le cose, l’attrito nel tempo di costruzione può diventare rapidamente un problema per l’intera organizzazione.
Tutto questo vuol dire che “su larga scala” accade più di quanto penseresti, e non è limitato all’eCommerce. Date un’occhiata a questo confronto tra rivenditori e siti Web di notizie. Per i siti di e-commerce, il numero di SKU è un proxy per il numero di pagine.
Siti di e-commerce con molti prodotti (SKU), editori con molti articoli
Editori con molti articoli
Mentre potresti pensare che solo siti come Amazon trattano milioni di SKU, questo non è vero. I siti Web relativi ai ricambi per auto sono un ottimo esempio: Ospitano milioni di prodotti in base ai criteri di ricerca anno/modello/marca/veicolo (YMMV). Ad esempio, TruPar.com vende esclusivamente componenti per carrelli elevatori, con SKU 8M.
Fortunatamente, alcune tecniche di rendering statiche e dinamiche aiutano a risolvere i problemi di Jamstack su larga scala.
Tecniche “statiche”
- Ottimizzazione dei tempi di costruzione
- Rendering lato client
- Generazione (ri)statica incrementale
Tecniche “dinamiche”
- Rendering lato server senza server + CDN
- Rendering statico parallelo
Tecniche di rendering “miste”
- Scelta della migliore tecnica di rendering per ogni classe di pagine
- Scelta di un framework e di una piattaforma che vi consenta di combinare le tecniche in base alle vostre esigenze
Nei paragrafi seguenti verrà illustrato il significato di queste tecniche.
Tecniche statiche
Ottimizzazione dei tempi di costruzione
Esistono diversi metodi per ottimizzare i tempi di creazione per le pagine Javascript dinamiche.
Build incrementali
Con le build incrementali, è possibile salvare gli artefatti delle build e rigenerare solo ciò che è cambiato. Se viene modificata una sola pagina, verrà rigenerata la pagina singola.
Costruzioni parallele
Il framework suddivide la build in più processi o thread. Ciò è utile per l’elaborazione delle immagini.
Generatori di siti statici alternativi
Gli SSG alimentati a nativa sono un metodo emergente e sono stati trovati per segnalare tempi di creazione migliori. Esempi includono Hugo (GO) e NIFT (C++). Tuttavia, molti generatori di siti statici scritti in modo nativo non funzionano bene con i siti Web pesanti di Javascript. Un brindisi relativamente nuovo sta cercando di affrontarlo.
Il problema è che il supporto del framework e del provider cloud per le build parallele e incrementali varia. Non tutti lo sostengono, e quelli che offrono solo un sostegno limitato.
Potenziale costo in eccesso per le pagine con visite non frequenti
Vi è anche la questione del potenziale eccesso di costi. Se avete un sito di grandi dimensioni con decine di migliaia di SKU o più, la maggior parte del vostro traffico segue una distribuzione di energia e dedicate più tempo di elaborazione alla ricostruzione di pagine che non verranno mai visitate. Più si aggiorna il sito, maggiore sarà il costo. Tenetelo a mente quando pensate ad alcune di queste tecniche.
Secondo willit.build (una pagina di benchmark della build di Gatsby, che fornisce tempi di build storici dei siti costruiti su Gatsby Cloud) i tempi di build per i siti Contentful e WordPress sono di circa 200 ms per pagina, il che significa che per un sito con 10k pagine, una build completa del sito potrebbe richiedere 25 minuti. Le build incrementali possono farti scendere a pochi minuti, mostrando il potere delle build incrementali. Questa tecnica può essere utile se non fai build complete.
Rendering lato client
Noto anche come shell dell’app o modello di fallback SPA, il rendering lato client è il routing CDN. Se il vostro sito ospita un milione di prodotti, tutti questi vengono instradati da questo livello CDN nel index.html e diventano un unico file statico contenente una shell dell’app e viene eseguito il rendering sul lato client. Quando il browser carica la pagina, il router del sito client recupera ed esegue il rendering del contenuto della pagina nel browser.
Con il rendering lato client, è possibile ospitare un numero infinito di pagine, ma vi sono alcune considerazioni importanti:
CSR può influire negativamente sul SEO
Il problema del rendering lato client è che potrebbe danneggiare le prestazioni, perché la pagina non può eseguire il rendering fino al caricamento di Javascript. A partire da maggio 2021, Google classificherà i siti Web in base a metriche a tre velocità, CLS, LCP e FID, collettivamente denominati Core Web Vitals. Il rendering lato client può avere un impatto negativo su tutti questi elementi, in particolare sugli spostamenti di layout cumulativi. Non è impossibile, ed è solo difficile ottenere buoni CLS con il modello di shell dell’app. A tale scopo, è necessario creare versioni personalizzate della shell dell’app per ogni tipo di pagina.
Le pagine di rendering lato client non possono essere lette da (alcuni) bot
Alcuni bot non sono in grado di leggere il contenuto renderizzato lato client. Google sostiene che i loro bot possono eseguire il rendering di Javascript e interpretarlo, ma sappiamo che la maggior parte degli altri bot non può farlo, compresi quelli della maggior parte delle piattaforme social, che è una fonte di traffico significativa per molti siti.
CSR richiede il supporto per le regole di riscrittura e reindirizzamento
Il terzo problema nell’implementazione della CSR è che richiede il supporto del provider di CDN per riscrivere e reindirizzare le regole, e alcuni lo fanno più elegantemente di altri. Ad esempio, è necessario utilizzare i gestori Lambda@Edge su AWS CloudFront tramite il supporto di 404 pagine.
Per fortuna, le principali piattaforme Jamstack Netlify, Vercel e Layer0 offrono un modo abbastanza semplice per abilitare la CSR.
In Netlify, si dispone di un file di reindirizzamento. Con i modificatori 200, è una riscrittura, ma è un reindirizzamento nascosto che l’utente non vede mai.
Netlify
Vercel offre il supporto per la riscrittura in vercel.json e si integra perfettamente con Next.js.
Vercel
La shell dei comandi CDN-as-JavaScript in Layer0 offre Next.js riscrive e supporta altri framework.
Layer0 (Edgio)
Generazione statica incrementale
Questa tecnica è stata introdotta da Next.js e ha comportato la generazione di nuove pagine statiche su richiesta in risposta al traffico in entrata. Il browser richiede una nuova pagina che non è stata ancora visitata e per ogni pagina, indipendentemente da quale sia la pagina, la CDN restituirà rapidamente una pagina di fallback universale che contiene solo dati segnaposto e nessun contenuto.
Mentre viene visualizzata la pagina di fallback, il processo di creazione statica della pagina viene eseguito in background. Al termine della compilazione, la pagina di fallback carica i dati JSON statici e visualizza la pagina finale. Da quel momento in poi, le visite future avranno l’HTML creato staticamente.
Rigenerazione statica incrementale
Esiste una versione della generazione statica incrementale chiamata rigenerazione statica incrementale, che è essenzialmente lo stesso processo. Tuttavia, comporta l’aggiornamento di una pagina statica esistente in risposta al traffico. Quindi, se i dati sottostanti cambiano, sta rieseguendo il processo di build, ispirato da un protocollo di cache obsoleto ma non molto apprezzato. Questo servirà una versione obsoleta della pagina invece del fallback mentre ricostruisce la pagina e poi la sostituisce con la nuova versione una volta terminato il processo di creazione.
Rigenerazione statica incrementale:
- Aggiorna le pagine statiche esistenti in risposta al traffico,
- Funge da versione obsoleta della pagina anziché da fallback.
La rigenerazione statica incrementale ha un impatto minore sul SEO e sulla compatibilità, soprattutto nella prima pagina. La pagina di fallback è interamente CSR e non ha dati, quindi non è chiaro come i bot risponderanno ad essa.
Tecniche dinamiche
Oltre alle tecniche statiche, i siti Web di eCommerce possono anche trarre vantaggio da tecniche dinamiche come:
- Rendering lato server senza server + CDN
- Rendering statico parallelo
Rendering lato server senza server + CDN
L’utilizzo di SSR in combinazione con la CDN consente di generare pagine su richiesta in risposta al traffico, offrendo alcuni vantaggi. Questa tecnica è anche più compatibile con il modo in cui vengono realizzate le piattaforme di e-commerce tradizionali. Consente di supportare molte pagine, generandole dinamicamente quando necessario, e garantisce un’elevata compatibilità con le piattaforme legacy.
Tuttavia, anche questa tecnica è un po’ controversa. La comunità Jamstack tende ad essere molto dogmatica su ciò che Jamstack è e afferma che Jamstack richiede la generazione statica.
Il rendering lato server senza server è effettivamente Jamstack-ish quando vengono soddisfatte 2 condizioni:
- Zero DevOps e server da gestire. È senza server e gli sviluppatori non devono gestire scale-way. È lo stesso senza server che molte piattaforme Jamstack usano per alimentare le loro API, il che dice che puoi usarlo per alimentare i dati HTML e attraverso SSR.
- HTML è gestito dalla CDN. Si tratta di una condizione critica. Dopo la prima perdita della cache, il sito gestito da CDN è veloce quanto un sito Jamstack generato da statica. Tenere presente che questa operazione richiede una corretta gestione della cache ed è più difficile per i siti a più pagine.
Rendering statico parallelo/precaricamento SSR
Layer0 consente di specificare l’insieme di URL che devono essere pre-rendering e memorizzati nella cache all’edge durante la distribuzione, per garantire che gli utenti abbiano un’esperienza inferiore al secondo quando accedono al sito.
Il pre-rendering statico comporta l’invio di richieste al codice dell’applicazione e la memorizzazione nella cache dei risultati subito dopo la distribuzione del sito. In questo modo, è sufficiente creare l’app per implementare il rendering lato server e ottenere i vantaggi di velocità di un sito statico per alcune o tutte le pagine. Questa funzione è particolarmente utile per siti grandi e complessi con troppi URL per il prerender senza incorrere in tempi di creazione eccezionalmente lunghi.
Il precaricamento SSR è un’altra tecnica utilizzata da Layer0 per accelerare la velocità delle pagine. È molto simile alla normale pipeline SSR, ma si basa sull’analisi dei registri del traffico dopo la distribuzione. Le pagine ad alto traffico sono precaricate in parallelo alla distribuzione. Lasciamo che la distribuzione avvenga istantaneamente e in modo asincrono, creando le pagine ad alto traffico. In questo modo, è possibile disaccoppiare la distribuzione dalla build. In questo modo è possibile ottenere distribuzioni immediate, massimizzando al contempo i riscontri nella cache.
Essenzialmente, se c’è una richiesta per una pagina con livelli di traffico elevati, molto probabilmente ci sarà un colpo di cache. È il modo migliore per ottenere i migliori risultati cache possibili in questo ambiente.
Il rendering statico parallelo consente di:
- Analizzare i registri per le pagine ad alto traffico
- Recupera e archivia HTML per pagine ad alto traffico in modo asincrono dopo la distribuzione
- Implementazione immediata massimizzando i riscontri della cache
Prerendering statico
Tecniche di rendering miste
Non è necessario scegliere tra tecniche di rendering statiche e dinamiche. Puoi scegliere ciò che è giusto per ogni classe di pagine sul tuo sito. “Potresti voler dichiarare “chi siamo”, “politica di restituzione” o blog statico e altre pagine come carrello, prodotto e categorie come dinamico.” Ti consigliamo di scegliere un provider di piattaforme che ti consenta di combinare in modo flessibile le tecniche come necessario, soprattutto se stai facendo questo su larga scala.
Scegliere la migliore tecnica di rendering per ogni classe di pagine, ad esempio, dichiarare alcune pagine statiche (ad esempio blog, chi siamo, ecc.) e altre pagine dinamiche (ad esempio carrello, prodotti, categorie, ecc.)
Scegliete un framework e un provider di piattaforme che vi consenta di combinare in modo flessibile le tecniche in base alle vostre esigenze
Jamstack in scala con Layer0
Le immagini della cache CDN di oggi, JavaScript e CSS, ma non i file JSON o HTML, e questo è ciò che frena i tempi di caricamento della pagina. Layer0 CDN-as-JavaScript rende gestibile la memorizzazione nella cache dei dati all’edge anche in un ambiente SSR dinamico e senza server.
Jamstack elimina il server dall’equazione e consente efficacemente alla CDN di gestire il traffico, cosa che può fare con facilità indipendentemente dalle fluttuazioni del traffico. Layer0 fa lo stesso ma in modo diverso: Invece di eseguire il rendering alla build, eseguiamo il rendering su richiesta ma memorizziamo ogni build nella cache sull’edge, quindi una build non è più necessaria dopo 1 build.
Il rendering di ogni pagina durante la creazione va bene per i siti più piccoli, ma il tempo di creazione diventa quasi insopportabile una volta che si è più grandi. La mancanza di personalizzazione/personalizzazione o le soluzioni alternative per fornire questi elementi rendono l’attenzione di Jamstack sul tempo di costruzione meno rilevante per i siti web basati su database su larga scala come eCommerce e Travel.
CDN-as-JavaScript
Layer0 CDN-as-JavaScript offre un potente controllo edge su chiavi cache, intestazioni, cookie e altro ancora, e funziona anche con il codice. Comprende il codice e il routing del framework e può essere emulato localmente o in ambienti di pre-produzione.
Le regole Edge sono presenti nel codice, proprio come nel classico Jamstack, che ti offre il controllo completo sull’edge con log live, controllo delle versioni e rollback con un solo clic.
Vedere Layer0/Edgio Cookbook per alcuni esempi dettagliati di modelli di instradamento su CDN-as-JavaScript.
Monitor delle prestazioni
Per massimizzare i tassi di hit della cache, è importante sapere quali sono questi tassi in primo luogo, ma queste informazioni di solito sono sepolte in profondità nei registri di accesso della CDN.
Layer0 dispone di un monitoraggio delle prestazioni integrato, che rende più facile comprendere quando si verificano errori e riscontri nella cache delle pagine e che espone queste informazioni allo sviluppatore in modo molto semplice. Il Performance monitor nel livello 0 consente di:
- Comprendere il traffico in base ai percorsi, non agli URL, perché è così che gli sviluppatori pensano della loro app. Inoltre, tiene traccia di ogni distribuzione, in modo che gli sviluppatori possano individuare qualsiasi regressione.
- Misurare i problemi di prestazioni nello stack e negli scenari di caricamento (API, SSR, Edge, ecc.)
Layer0 ha anche creato uno strumento per diagnosticare se la risposta proviene dal bordo dell’origine: DevTools. DevTools consente di determinare se la risposta proviene dal bordo dell’origine. Nell’esempio seguente viene illustrato come funziona sulla shell di un’app creata con React Storefront, mostrando quando arriva una richiesta. La risposta in questo esempio viene fornita attraverso la rete edge Layer0 (ora Edgio).
Layer0 DevTools consente di diagnosticare se le risposte provengono dall’edge o dall’origine
Capire se una risposta proviene dal bordo o dall’origine è fondamentale per il precaricamento in scala, che è un’altra cosa che Layer0 fa per voi.
Precaricamento su scala
Il precaricamento è importante per le prestazioni perché sblocca le velocità delle pagine istantanee. I tradizionali test di velocità delle pagine, come quello che si verifica con Lighthouse, sono focalizzati su ciò che accade dopo che il cliente fa clic. Tuttavia, è possibile iniziare a fare molto prima che il cliente tocchi e ottenga latenza zero e larghezza di banda quasi infinita.
Layer0 DevTools consente di diagnosticare se le risposte provengono dall’edge o dall’origine
I siti Web su Layer0 sono incredibilmente veloci perché utilizzano il prefetching predittivo avanzato insieme a Layer0 CDN-as-JavaScript, che consente loro di rimanere 5 secondi prima dei tocchi degli acquirenti. Ciò avviene tramite lo streaming dei dati dinamici memorizzati nella cache dall’edge ai browser degli utenti prima di fare clic su qualsiasi cosa, in base a ciò che si prevede di fare clic su Avanti. In altre parole, il tuo negozio può fornire i dati JSON per i diversi prodotti che stai offrendo, i loro prezzi e le informazioni in una frazione del tempo.
Migrazione incrementale
Layer0 offre la migrazione iterativa (graduale, progressiva), che consente di migrare iterativamente una sezione dell’app alla volta, seguendo il modello strangolatore di Martin Fowler. In questo modo, si “strangolano” in modo incrementale le funzionalità specifiche e le si sostituiscono con nuove applicazioni e servizi. È come spostare una montagna pietra per pietra.
La migrazione incrementale richiede un controllo instradato all’edge o all’origine della CDN. Ecco un esempio di come si fa su Layer0 usando CDN-as-JavaScript.
Personalizzazione e segmentazione
La migrazione incrementale, graduale e progressiva è importante per i siti di grandi dimensioni. Ma non si limita alla personalizzazione! Include anche lingua, area geografica, ecc. E ha senso perché i siti di grandi dimensioni di solito operano in diverse aree geografiche e devono essere in grado di personalizzare il contenuto in base alle esigenze degli utenti durante la visita del sito.
Le linee guida generali sono: Se questo contenuto è al di sotto della piega, consigliamo il caricamento ritardato e il rendering lato client. Se si tratta di contenuti personalizzati al di sopra della piega, è necessario utilizzarli in un output reso dal server.
Sopra la piega personalizzata = aggiungere personalizzazione alla chiave cache
Su Layer0, è possibile dichiarare una chiave cache personalizzata e personalizzarla, ad esempio, in base alla valuta o al comportamento. Potete personalizzare le promozioni e ordinare l’ordine nelle pagine delle categorie, in base al fatto che qualcuno sia un visitatore frequente o un nuovo visitatore, con poche righe in CDN-as-JavaScript.
Test a/B e Layer0
I test a/B e la personalizzazione aggiungono un nuovo livello di complessità alla creazione di siti Jamstack. I test sono molto importanti per i grandi siti e le grandi organizzazioni, in cui le decisioni sono basate sul ROI e deve essere dimostrato di migliorare i tassi di conversione.
Nel Jamstack tradizionale, tuttavia, l’unica opzione disponibile è il test A/B lato client eseguito nel browser. Il problema è che ciò può influire sulle prestazioni e annullare i test in due modi. Può danneggiare le prestazioni delle tue varianti, cancellando qualsiasi tipo di miglioramento. E a volte, i test A/B hanno effetto dopo che l’occhio ha superato gli elementi testati. È possibile che nell’intestazione sia presente il test A/B e che l’utente abbia già eseguito la scansione oltre tale intestazione una volta che JavaScript viene eseguito e modificato tale elemento.
I problemi con i test A/B lato client
- In genere, l’unica opzione per i siti statici
- Non funziona fino a quando non viene eseguito JavaScript
- Prestazioni scadenti che potrebbero annullare il test
Gli esperimenti Layer0 Edge rimediano a questi problemi abilitando i test A/B sull’edge. Su XDN, le nuove esperienze sono sempre native, memorizzate nella cache e sotto-secondi. Ciò va oltre i test A/B a qualsiasi variante del tuo sito Web.
Esperimenti Edge
Layer0 è anche dotato di un potente motore Edge Experiments integrato. Il modulo fa parte di CDN-as-JavaScript ed è a conoscenza di tutte le varianti, garantendo che ciascuna sia memorizzata nella cache separatamente all’edge. In questo modo è possibile controllare esattamente quali visitatori vedono quale variante.
Gli esperimenti sui bordi consentono di:
- Instradare il traffico in tempo reale a qualsiasi filiale implementata all’edge della rete
- Eseguire test A/B, implementazioni canary o flag delle funzioni
- Scrivere le regole di routing in base alle probabilità o ai valori di intestazione e pari
- Indirizzi IP
Con Edge Experiments, puoi facilmente dividere i test senza influire sulle prestazioni del tuo sito. Le divisioni vengono eseguite all’edge attraverso un’interfaccia potente e facile da usare. Gli esperimenti Edge possono essere utilizzati per test A/B e multivariati, distribuzioni canary, test Blue-green, migrazione iterativa da un sito Web legacy, personalizzazione e altro ancora.
In che modo i nostri clienti traggono vantaggio da Layer0
Layer0 offre una transizione senza problemi a Jamstack e headless e offre un enorme vantaggio per i siti con cataloghi di grandi dimensioni, aggiornamenti frequenti o per quelli che eseguono piattaforme di eCommerce legacy. Shoe Carnival e Turnkey Vacation Rentals sono due esempi di team di sviluppatori presso grandi siti che utilizzano Jamstack e Headless per l’eCommerce su Layer0.
Chiavi in mano
Turnkey Vacation Rentals è una società di gestione immobiliare per affitti vacanze a servizio completo per case in affitto di livello premium e di lusso nelle principali destinazioni di viaggio in tutto il paese. A differenza di siti come Airbnb, chiavi in mano offre solo elenchi pre-controllati. Gestisce inoltre i dettagli di gestione a livello centrale, utilizzando un set standardizzato di strumenti tecnologici.
Configurazione originale
Turnkey stava eseguendo un’app all’interno di Docker su AWS Elastic Beanstalk e stava cercando una soluzione per fornire loro un maggiore controllo e una visione più approfondita delle prestazioni.
Hanno preso in considerazione alcune soluzioni Jamstack, ma volevano una piattaforma che potesse supportare Next.js nativamente, come Layer0. Uno dei fattori decisivi è stato che con Layer0, potevano evitare di refactoring come funzionavano il loro codebase e la pipeline di dati.
Layer0 ha aiutato Turnkey ad aumentare l’agilità con alcune funzionalità elencate di seguito.
Ambienti
In passato, Turnkey utilizzava una pipeline personalizzata costruita all’interno di Jenkins, e il team stava implementando da una filiale di trunk, senza mai avere completa fiducia in ciò che si stava preparando per entrare in produzione.
Con Layer0, le filiali hanno ambienti individuali e il team di Turnkey può configurare ambienti incontaminati, che non si fondono nell’ambiente di staging finché non sanno che qualcosa ha superato il controllo qualità. In questo modo si elimina il carico mentale associato al controllo della qualità.
Registri
Scavare attraverso i registri del server su Beanstalk può essere un incubo: Devi capire esattamente quali registri stai cercando, quale server sono su cui sono, se sono bilanciati dal carico, ecc. Con Layer0, è possibile eseguire lo streaming live dei registri direttamente dalla build, che consente di trovare la build che si desidera risolvere, premere Play e guardare il log.
Migrazione incrementale
Le pagine “chiavi in mano”, non “React/Next.js”, venivano eseguite sulla vecchia architettura. Con Layer0, potrebbero prendere ciò che avevano già migrato, metterlo sull’XDN e continuare la migrazione incrementale.
Layer0 ha dato al team di strumenti chiavi in mano di concentrarsi sulle prestazioni.
Carnevale delle scarpe
Shoe Carnival Inc. È un rivenditore americano di calzature. L’azienda attualmente gestisce un negozio online insieme a 419 negozi di mattoni e Malta in tutte le regioni del Midwest, del sud e del sud-est degli Stati Uniti.
Di seguito sono riportate alcune delle caratteristiche di Layer0 che il team Shoe Carnival ha trovato particolarmente utile.
Flessibilità
Shoe Carnival utilizza Salesforce Commerce Cloud, che non è stato progettato per gestire frontend senza testa come quello di Shoe Carnival. Quindi, c’era molta esperienza ingegneristica e di comprensione sul lato back-end per eseguire i dati sul frontend. Queste sfide potrebbero essere risolte grazie alla flessibilità offerta dal backend Layer0 tra Salesforce e il frontend React. Il team di Shoe Carnival poteva creare liberamente con React e ignorare i limiti di Salesforce.
È il momento di aumentare la produzione
Il tempo di produzione di Shoe Carnival è aumentato drasticamente. Il team può essere separato dai cicli di sviluppo di Salesforce e apportare modifiche molto rapide nella distribuzione.
Velocità del sito
La velocità di produzione è un enorme vantaggio, ma le prestazioni del sito in genere sono difficili da ignorare poiché il carnevale delle scarpe è passato da 5-6 secondi di caricamento medio delle pagine a meno di secondi. Possono memorizzare nella cache gli oggetti a un livello molto granulare e disporre degli strumenti per garantire che i clienti siano sempre disponibili e aggiornati.
Implementazione incrementale
L’implementazione incrementale consente al team di distribuire in produzione molto più velocemente rispetto alla creazione di un’applicazione completa per la distribuzione.
Per quanto riguarda l’impatto della migrazione a Layer0, quando Shoe Carnival ha testato il sito di origine rispetto al sito headless per le conversioni 50/50 a livello CDN, il headless ha sempre vinto, superando il sito di origine e migliorando velocità e visibilità.
Riepilogo
Noi di Layer0 crediamo che Jamstack sia il futuro dello sviluppo web. Layer0 apporta essenzialmente i vantaggi di prestazioni e semplicità di Jamstack ai team di sviluppo front-end di grandi siti di eCommerce dinamici in cui le tecniche statiche tradizionali generalmente non si applicano. Ci piace chiamarlo Jamstack dinamico. Rende i siti Web SPA con caricamento istantaneo e più facile da sviluppare.
Layer0 viene fornito con una CDN-as-JavaScript che può aumentare o addirittura sostituire la CDN corrente e portare tutte le funzionalità di sicurezza Web necessarie alla periferia della rete. Layer0 include anche una serie di tecnologie incentrate sullo sviluppo che rendono l’intero processo di sviluppo, distribuzione, anteprima, sperimentazione, monitoraggio, inoltre, è possibile eseguire il frontend senza testa in modo semplice, con URL di anteprima full-stack automatizzati, un backend JavaScript senza server per frontend, monitoraggio avanzato della cache e altro ancora.
Layer0 è una piattaforma di sviluppo all-in-one che consente di:
- Utilizza Jamstack per l’eCommerce tramite rendering pre e just-in-time
- Abilitare il networking a latenza zero tramite il precaricamento dei dati dalle API del catalogo dei prodotti
- Configurare Edge in modo nativo nell’app (CDN-as-JavaScript)
- Eseguire le regole del bordo localmente e in fase di pre-produzione
- Crea URL di anteprima da GitHub, GitLab o Bitbucket con ogni nuova diramazione e push
- Eseguire le divisioni all’edge per test A/B performanti, implementazioni canary e personalizzazione
- JavaScript senza server molto più semplice e affidabile di AWS Lambda
