Learn about Edge Delivery Services in upcoming GEM session
Adobe Developers Live, November 2022, Session | Bring in-context and headless authoring to your NextJS app
Session Details
[Level: Intermediate] Next.js provides great developer experience to build web apps quickly. It is also a perfect delivery vehicle for content powered by AEM Headless. In this section, we will show you how to enable in-context and form-based editing for integrated AEM.
Session Presentation
Presentation link: https://bit.ly/3DZ4qAp
Session Recording
Session Schedule
9th November, 2022 | 10:45-11:30 PST OR 18:45-19:30 UTC OR 19:45-20:30 CET
Speaker(s)
Iryna Lagno, Engineering Manager, Adobe & Duy Nguyen, Software Engineer, Adobe
Moderator(s)
Adobe
Product(s)
AEM
Full Schedule
Session Q&As
| Questions | Answers |
| we want to understand if we need to write the UI for nextjs components, but then write separate UI for authoring in AEM | React components used in your Next.js app are different from the AEM components used for authoring in the Remote SPA Editor. You need both components for in-context editing with Next.js. If you already have existing AEM components used in AEM pages, you can of course used them here without re-writing the same components to author remote Next.js pages. |
| How would you go about hosting the AEM instance so that it pulls in the NextJS app for in-context editing? You can set up your SPA Remote Page for Next.js and do in-context editing in both AEM on premise and Cloud Service. |
Authoring experience is the same as in AEM pages, if you have all components available in AEM and React. |
| How is the authoring experience working? Are you using the nextJS components in author as well? Or are you replicating the components in ui.frontend | Authoring experience is the same as in AEM pages, if you have all components available in AEM and React. |
| Does AEM Cloud caches GraphQL persisted queries at the closest server location from the user request? | It depends on how you implement your Next.js app to leverage different types of rendering and caching. Client side rendered apps pull content directly to the user’s browser, so GraphQL persisted query results are served from AEM CDN. Server side rendered apps pull content to Next.js server which then serves it to the end user. In that case, GraphQL persisted queries are server-to-server calls. The end user would only get content from your Next.js CDN. |
| Website is loaded on nextJS server right ? AEM is only used for content delivery to NextJS | Yes |
| Is AEM Author using same js/css from NextJS App in Author Edit Mode? | Yes, it loads JS/CSS from the Next.js app. |
| Where all this (in line) edited content and its layouts is being stored (at runtime)? Are there happening POSTs requests (GraphQL mutations) under the hood? |
Your Next.js app consumes JSON data from AEM. The AEM Editable SDK takes care of adding data attributes to HTML elements so that the Remote SPA Editor understands which component is being edited to update it in the repository. There is no GraphQL mutation under the hood. |
| And what if there’s no Page at all and everything is driven as a pure content-as-service (providing a structed content only ) as JSON to the Next.js App | You are free to implement your Next.js app with JSON from content fragments only. |
| Its easy if we have one CF that co-relates to an equivalent Front End component but what’s the recommendation if my CF is a nested CF that references multiple CF’s ? | It’s hard to answer this question without a use case. Generally speaking, you can write any logic in your Next.js app to handle relationship between content fragments. |
| Do you support the new layout feature in Next 13? | That is part of the app directory feature which is in beta release. We are considering how to leverage that in Next.js apps for AEM. |
Q&A
Please use this thread to ask the question related to this Session.
Don't forget to register yourself for this session using the registration link shared above.
Kautuk Sahni
