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