Guidenace on Implement Server side rendering in AEM LTS + VUE js setup

​@PrakashBa2 

With AEM 6.5, I would keep SSR on the Vue js side rather than trying to make AEM handle the rendering.

A typical setup is for AEM to expose content through APIs, such as GraphQL, Content Fragments, or JSON. The Vue js SSR layer then fetches that content and renders the initial HTML. AEM remains the content platform, while Vue.js handles the application rendering.

It would be good to pay attention to caching, authentication if needed, and how routing and content preview or authoring should work between AEM and the SSR layer.

If you share more details about your current AEM and Vue architecture, the options will be easier to narrow down.

​@PrakashBa2 ,

I looked into this recently. AEM can’t run Vue on the server itself (6.5 LTS or Cloud Service). Rhino doesn’t support modern JS and Nashorn was removed in Java 15, so Vue 3 SSR needs a separate Node renderer outside AEM.

I would prefer using and customizing the Remote Content Renderer (RCR). AEM POSTs the page model to your Node service, which renders it with createSSRApp + renderToString and returns HTML. The client then hydrates. You need two webpack builds: the client one goes into the clientlib, and the server one is deployed to the Node service. Adobe documents RCR for React and Angular only, so for Vue you’d write the renderer yourself. A rough design would look like below:

 

Things to watch:

• The SPA Editor is deprecated, and the Vue community packages (Vue 2 @mavice, Perficient’s Vue 3 port) don’t include an SSR pipeline.
• If you host on Adobe I/O Runtime, there are limits: 60 s timeout, 1 MB payload, 600 activations/min.
• Keep author mode client-side, and watch for hydration mismatches.

Alternatives: If Vue only handles interactive parts, render the SEO-critical markup in HTL and let Vue enhance it, with no Node service needed. For a Vue-heavy build, a decoupled Nuxt 3 app with persisted GraphQL queries and the Universal Editor is a cleaner option.