In questa parte del AEM Percorso di sviluppatori headless, scopri come utilizzare lo strumento di sviluppo AEM e l’SDK Headless per unire l’applicazione.
Nel documento precedente del percorso senza testa AEM, Come aggiornare i contenuti tramite le API di AEM Assets hai imparato ad aggiornare il contenuto headless esistente in AEM tramite API e ora dovresti:
Questo articolo ha lo scopo di aiutarti a capire come mettere insieme la tua AEM applicazione headless:
L'SDK AEM viene utilizzato per generare e distribuire il codice personalizzato. È lo strumento principale di cui hai bisogno per sviluppare e testare la tua applicazione senza testa prima di andare in diretta. Contiene i seguenti artefatti:
Diverso dall'SDK AEM, il AEM SDK headless è un set di librerie che possono essere utilizzate dai client per interagire in modo rapido e semplice con AEM API headless tramite HTTP.
Per ulteriori informazioni sull’SDK senza titolo AEM, consulta la sezione documentazione qui.
Oltre all’SDK di AEM, avrai bisogno di strumenti aggiuntivi che consentano di sviluppare e testare il codice e il contenuto localmente:
Poiché AEM è un'applicazione Java™, è necessario installare Java™ e l'SDK Java™ per supportare lo sviluppo di AEM as a Cloud Service.
Git è ciò che utilizzerai per gestire il controllo del codice sorgente e per archiviare le modifiche a Cloud Manager e quindi distribuirle in un’istanza di produzione.
AEM utilizza Apache Maven per generare progetti generati dall’archetipo del progetto Maven AEM. Tutti gli IDE principali forniscono supporto per l’integrazione per Maven.
Node.js è un ambiente di runtime JavaScript utilizzato per lavorare con le risorse front-end di un progetto AEM ui.frontend
sottoprogetto. Node.js è distribuito con npm, è il gestore di pacchetti Node.js de facto, utilizzato per gestire le dipendenze JavaScript.
Ora, diamo un'occhiata alle parti costituenti di un ambiente AEM.
Un ambiente AEM completo è costituito da Author, Publish e Dispatcher. Questi stessi componenti sono resi disponibili nel runtime di sviluppo locale per facilitare l’anteprima del codice e del contenuto prima di iniziare a usare il programma.
Il servizio di authoring è il luogo in cui gli utenti interni creano, gestiscono e visualizzano in anteprima i contenuti.
Il servizio di pubblicazione è considerato l’ambiente “live” ed è normalmente ciò con cui gli utenti finali interagiscono. I contenuti vengono modificati e approvati nel servizio di authoring e quindi distribuiti al servizio di pubblicazione. Il modello di implementazione più comune per le applicazioni headless AEM consiste nella connessione della versione di produzione dell’applicazione a un servizio di pubblicazione AEM.
Dispatcher è un server web statico integrato con il modulo Dispatcher AEM. Memorizza in cache le pagine web prodotte dall’istanza di pubblicazione per migliorare le prestazioni.
Il progetto di sviluppo locale è basato su Apache Maven e utilizza Git per il controllo del codice sorgente. Per aggiornare il progetto, gli sviluppatori possono utilizzare, tra gli altri, il proprio ambiente di sviluppo integrato preferito, ad esempio Eclipse, Visual Studio Code o IntelliJ.
Per testare gli aggiornamenti di codice o contenuto che verranno acquisiti dall'applicazione headless, devi distribuire gli aggiornamenti al runtime AEM locale, che include le istanze locali dei servizi di authoring e pubblicazione AEM.
Assicurati di prendere nota delle distinzioni tra ogni componente nel runtime AEM locale, in quanto è importante testare gli aggiornamenti dove contano di più. Ad esempio, prova gli aggiornamenti del contenuto sull’autore o testa il nuovo codice sull’istanza di pubblicazione.
In un sistema di produzione, un’istanza di Dispatcher e un server http Apache si troveranno sempre davanti a un’istanza di pubblicazione AEM. Forniscono servizi di caching e sicurezza per il sistema AEM, pertanto è fondamentale testare il codice e gli aggiornamenti di contenuto anche in Dispatcher.
Per preparare il progetto senza testa AEM per il lancio, è necessario assicurarsi che tutte le parti costitutive del progetto funzionino bene.
Per farlo, devi mettere tutto insieme: codice, contenuto e configurazione e testalo in un ambiente di sviluppo locale per renderlo disponibile dal vivo.
L'ambiente di sviluppo locale si articola in tre aree principali:
Una volta configurato l’ambiente di sviluppo locale, puoi simulare il servizio dei contenuti all’app React distribuendo localmente un server Node statico.
Per un'analisi più approfondita della configurazione di un ambiente di sviluppo locale e di tutte le dipendenze necessarie per l'anteprima dei contenuti, vedi Documentazione sulla distribuzione di produzione.
Dopo aver completato questa parte del Percorso di sviluppatori AEM Headless, devi:
Continua il tuo percorso AEM headless rivedendo il documento successivo Come andare in diretta con la tua applicazione headless dove si prende il vostro progetto AEM Headless in diretta!