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.
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.
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.
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.
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):
- Backend: Enabling .Net MVC parity in a SPA
- Backend: Achieving SEO, Accessibility, and separate Frontend deployment
- Frontend: Anatomy of an implementation
- Frontend: Routing & Custom components
- Frontend: Adding application services