London Dev Meetup Rescheduled! Due to unavoidable reasons, the event has been moved to 21st May. Speakers remain the same—any changes will be communicated. Seats are limited—register here to secure your spot!

Remko Jantzen
Jun 29, 2021
  4388
(4 votes)

Into Foundation Spa React series

It has been a while since I have written about the Headless CMS and React frontend implementation for Foundation. To say that nothing has changed with the project since is an understatement. Since that blog post, significant parts of the solution have been overhauled and more advanced features have been added, bringing the React frontend almost up-to-par with a .Net MVC-based frontend.

This is the first blog post in a series, that will go into the various aspects of the Headless setup and React SPA and how this enables a headless deployment into Optimizely DXP (Content Cloud). The series will first dive into the backend extensions to Foundation-MVC-CMS (or any Content Cloud implementation) and then focus on the frontend.

Solution aims and constraints

Before going into the details of the solution, I will first reiterate and expand on the design constraints and aims I set out with when designing and creating Foundation-Spa-React. I am fully aware that some of these constraints are not there for everyone and have inspired some design decisions that are not always well received. However - if you have the ability to do so - many of the constraints are coded "loosely coupled" into the application, so adjust them however you see fit.

Technology stack

The project has been constructed with the following technology stack in mind

  • Backend: Optimizely Content Cloud with Search & Navigation, running in a Headless mode to deliver models & business logic
  • Frontend: TypeScript (latest), React (with Router & Helmet), Redux, Axios

Deployment

The solution should be able to deploy into the Optimizely DXP, without the requirement to procure additional solutions and services. At the time of writing, the Optimizely DXP only allows deploying a .Net solution into an Azure WebApp, without a separate frontend application.

As - in some occasions - the frontend will be a completely separate application, hosted outside the Optimizely DXP, the solution should support such a deployment scenario as well. This scenario is not part of the example, but some tests have shown that the required changes are minimal.

Workflow

Typically when talking headless, one of the implications is that there are two teams working on delivering the solution: a (relatively small) backend team creating integrations and platform customizations and a frontend team working in a different project, consuming the backend services and writing JavaScript (TypeScript) / HTML / CSS to create the customer experience. In this setup, it is in many cases undesirable to require a frontend developer to do a complete solution deployment, including the .Net solution.

As such the final solution should overcome this constraint and enable frontend teams to work completely independently of the backend teams once the additions are deployed to the Optimizely DXP. As the .Net solution controls the data models, utilities should be provided to aid the frontend team in ensuring that these are represented correctly in the TypeScript code.

Frontend

Full ability to deliver an SEO-friendly and accessible website, which implies that the website must be fully server-side rendered to allow crawlers as well as non-JavaScript aware screen-readers to read the page and understand it. Though this might seem pretty straightforward, consider that no templating at all will be done in .Net MVC, everything will be delivered by the frontend team.

Use core product capabilities

With Optimizely Content Cloud being a PaaS solution, it is easy to extend it for every small and single improvement identified. Yet, the constraint applied here is to minimize the number of customizations added on the C# side and to remove these once a viable solution has been added to the core product. This approach has already resulted in the removal of a number of customizations/extensions from the initial version to the version currently on GitHub.

Continue reading

So, how are these aims achieved and constraints met? Find out in the subsequent blog posts (these will become links when a post has been published):

  1. Backend: Enabling .Net MVC parity in a SPA
  2. Backend: Achieving SEO, Accessibility, and separate Frontend deployment
  3. Frontend: Anatomy of an implementation
  4. Frontend: Routing & Custom components
  5. Frontend: Adding application services
Jun 29, 2021

Comments

Please login to comment.
Latest blogs
Optimizely Frontend Hosting Beta – Early Thoughts and Key Questions

Optimizely has opened the waitlist for its new Frontend Hosting capability. I’m part of the beta programme, but my invite isn’t due until May, whil...

Minesh Shah (Netcel) | Apr 23, 2025

Developer Meetup - London, 21st May 2025

The London Dev Meetup has been rescheduled for Wednesday, 21st May and will be Candyspace 's first Optimizely Developer Meetup, and the first one...

Gavin_M | Apr 22, 2025

Frontend hosting for PaaS & SaaS CMS

Just announced on the DXP, we FINALLY have a front end hosting solution coming as part of the DXP for modern decoupled solutions in both the PaaS a...

Scott Reed | Apr 22, 2025

Routing to a page in SaaS CMS

More early findings from using a SaaS CMS instance; setting up Graph queries that works for both visitor pageviews and editor previews.

Johan Kronberg | Apr 14, 2025 |