[PAGES-190] Assist SPA developers to make SPA's editable in the Page Editor Created: 01/Apr/19  Updated: 15/Dec/22  Resolved: 26/Sep/22

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Epic Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Done Votes: 4
Labels: None
Remaining Estimate: 0d
Time Spent: 2h 49m
Original Estimate: Not Specified

Issue Links:
Relates
dependency
is depended upon by PAGES-218 SPA Editor Backlog Selected
Template:
Epic Name: SPA Editor
Acceptance criteria:
Empty
Date of First Response:
Team: DeveloperX

 Description   

Development teams are employing a headless approach where they create the frontend as a Single Page Application (SPA), typically with React, Angular or Vue.

They want to allow their content authors to use the Page Editor to manage the content and layout of the SPA.

We need to adapt the Page Editor and our REST endpoints to improve support this use case.



 Comments   
Comment by Emilio Garza [ 12/Jul/19 ]

At VSP Global, we use Magnolia headless through delivery and have to maintain FTLs and our SPA separately, thus producing duplicated code. This would be a major improvement to the headless approach.

Comment by Jeffrey van der Heide [ 23/Dec/19 ]

Really like the effort going in to this! So far it's looking great! Really looking forward to moving to Magnolia + Angular hybrid headless as our main stack. The initial tests look very promising.

Any plans on potentially making SSR easily pluggable as/in the rendering engine? 
I could imagine creating something like a dockerfile with a Magnolia instance and n-amount of nodejs images,
where Magnolia would put requests that require SSR through to the Nodejs server (that would share a certain mount/path with magnolia to access the (e.g. Angular) files. From where Angular universal could render the page with its socket-engine (https://github.com/angular/universal/tree/master/modules/socket-engine) and give that back to Magnolia from where Magnolia could actually cache that page. Wouldn't mind giving this a spin myself if I can make sometime to do so soon.

SSR is a must given that sadly SEO and Social Sharing previews etc. still require them. 
Or do you have an other vision/idea regarding a SSR approach?

Comment by Christopher Zimmermann [ 06/Jan/20 ]

Thanks for the feedback Jeffrey. Our approach is to be fully headless - so an angular/nodejs server can be used to serve the production instance, including using its built-in SSR. However in this scenario the Magnolia page caching is not in effect as Magnolia is not serving "pages", the angular server is. However you can use any standard caching mechanism that you want for the Angular server.

(Of course you could choose to host your Angular app as resource files served from Magnolia as well - but in this case the angular SSR would not be available.)

This feature "just" makes the angular app editable via the Magnolia Pages App. The production instance can be something else entirely.

Generated at Mon Feb 12 06:16:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.