RFC: Better starter project for AEMaaCS

[Tylopilus]

After toying around with this project I can see a few downsides for basing a real project off of this project:

1. No typescript
2. Project is going against author in production build. This requires at least an auth-token / ims handshake for CS. unclear how to combine this. Authoring in AEM would require author content. Accessing NextJS should have content from Publisher
3. Project does not have a catch all route so if a new page in aem has been created it's not valid in nextjs
4. Navigation within AEM is not setup correctly for the rewriter-rules
5. Adding the SPA-Route for each page should ideally not needed. SPA-Host should come from env and page should follow navigation-title
6. Documentation is lacking, e.g. it's not clear what pages/api/getNextProps.js is used for
7. There is no way to easily get 'all routes' from AEM for SSG

So all these issues are currently not addressed within this repo. For faster adoption rate imho there should be a good starter provided that has all these points checked and then can be build on top of.

[duynguyen]

Hi @Tylopilus - glad to see your interest in this project and playing around with it! Your feedback is really helpful for us to shape our plan for upcoming releases.

No typescript

While typescript is increasingly used a lot in large-scale projects, many devs don't need it in the beginning. We wanted to keep it simple in this first release, hence js only for now. We might add ts later based on the feedback like yours, and our capacity (to create as well as maintain it). Of course if you're interested in contributing, PR's are always welcomed. 😄

Project is going against author in production build. This requires at least an auth-token / ims handshake for CS. unclear how to combine this. Authoring in AEM would require author content. Accessing NextJS should have content from Publisher

This has not been very clear in this project, and we will need to improve it. In a real project, you would have 2 deployments of the app: authoring and publish (same code, different deployment configs). The author-able app gets content from AEM author instance, can be loaded in AEM remote SPA editor that allows content authors to update it. This app requires the IMS auth to connect to author. The publish app gets content from AEM publish instance. This does not need any auth.

Project does not have a catch all route so if a new page in aem has been created it's not valid in nextjs

That'd be a good enhancement. Created #5 to track this.

Navigation within AEM is not setup correctly for the rewriter-rules

You're right, we'll need to revisit the rewriter-rules.

Adding the SPA-Route for each page should ideally not needed. SPA-Host should come from env and page should follow navigation-title

We are working on an enhancement of the SPA Remote Page (Next) component in AEM so that you only need to set the SPA URL once in the root (home) page, and all child pages should inherit from it (following the path in AEM).

Documentation is lacking, e.g. it's not clear what pages/api/getNextProps.js is used for

This will be addressed in a WIP tutorial to be published in Experience League. In short, pages/api/getNextProps.js is required by AEM remote SPA editor to load the app there for WYSIWYG editing.

There is no way to easily get 'all routes' from AEM for SSG

We will add examples for it to the tutorial as well.

[Tylopilus]

This has not been very clear in this project, and we will need to improve it. In a real project, you would have 2 deployments of the app: authoring and publish (same code, different deployment configs). The author-able app gets content from AEM author instance, can be loaded in AEM remote SPA editor that allows content authors to update it. This app requires the IMS auth to connect to author. The publish app gets content from AEM publish instance. This does not need any auth.

I have to think about this. At first I had some concerns but the more I think about it the overhead would be manageable. AEM CA-Configs for runtime and each Next-Deployment has it's host-url. This would then still work with preview-build-urls and easily changeable.

Is there any plan to provide a simple way of deploying this to adobe runtime? For now I will stick with vercel and see what to adjust.

But my main point was also that there should be at least one additional starter template. This one as a showcase including wknd-app and a bare bones starter. This one is nice but it's a lot to strip out if you want to build anything else than wknd.

Another thing: For SSG there also needs to be a function to get all available routes for which I created a Feature-Request here: https://github.com/adobe/aem-react-editable-components/issues/132

[duynguyen]

Is there any plan to provide a simple way of deploying this to adobe runtime?

That's in the radar. However, we don't have a detailed plan as of today.

But my main point was also that there should be at least one additional starter template. This one as a showcase including wknd-app and a bare bones starter. This one is nice but it's a lot to strip out if you want to build anything else than wknd.

Good point. It was based on wknd because of the sample AEM content you can get from it. Without wknd content we might end up with a vanilla Next.js app just like the one you get from create-next-app. Do you have an idea what a starter template should contain if we remove wknd?

[Tylopilus]

The starter should already be opinionated about the connection to AEM. So same envs as here + adobe react packages. Additionally i think it would be wise to introduce a new package which is a config-client. This client then can either handle the authentication based on a developer token or local auth token and could also be a wrapper for the adobe-headless-client and co A good example is actually what the guys from builder.io are providing: https://stackblitz.com/edit/nextjs-builder?file=pages%2F[[...page]].tsx