Try our conversational search powered by Generative AI!

Remko Jantzen
Jun 29, 2021
(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


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.


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.


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


Please login to comment.
Latest blogs
Optimizely Web... 6 Game Changing Features in 2024

If you are interested in learning about what's new within Optimizely Web, you are in the right place. Carry on reading to learn about the 6 greates...

Jon Jones | Mar 3, 2024 | Syndicated blog

Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog

Identify Azure web app instance id's for an Optimizely CMS site

When running Optimizely CMS in Azure, you will be using an instance bound cloud license. What instances are counted, and how can you check them? Le...

Tomas Hensrud Gulla | Feb 27, 2024 | Syndicated blog