Starting a DXM implementation targeting content delivery through a .NET API to a ReactJS site
The following question came through our Support team that is better addressed in the Community context:
"We are starting a new project using Crownpeak. The initial idea is sending Crownpeak content to a .NET API and then to a ReactJS ... I would appreciate if you could give me some guidance on how to approach this."
Re: Starting a DXM implementation targeting content delivery through a .NET API to a ReactJS site
Due to DXM's decoupled architecture, you need to consider two different contexts: the content management context and the content delivery context.
You have already outlined an approach to your content delivery context: a .NET backend that presents an API that your ReactJS site will communicate with for all its content needs including content discovery (query) and content retrieval. I would always encourage teams to build what they need in the content delivery context first, and then look at how to use DXM to introduce content management features. DXM is not an application platform that you extend but a content management, cloud-based service.
Content Delivery context
Critical to getting this to work is establishing what your "content" is going to be. It sounds like delivering JSON responses through the API that the React app can parse and pass to React components would be a good fit.
Let's take a closer look at how the .NET backend is going to discover and process this content. A very simple approach would be to publish JSON files from the CMS (content management context) to the server hosting the .NET backend following some kind of naming and organization strategy, perhaps folders for each "type" of JSON and each file based on the asset's branch ID in the CMS: /articles/12345.json, /articles/67890.json, /press-releases/251259.json, /alerts/23932.json for example.
A slightly more involved approach would be to publish the content from the CMS to Crownpeak Search G2. Search G2 provides its own API (it is a Solr query endpoint), that provides everything you would need for querying, sorting and retrieving content. The "fields" being published to Search G2 could be in individual fields or you could choose to serialise a JSON structure to a string and place this in a single text field. If you consider this approach, please also consider whether you need a public or a private Search G2 collection.
Content management context
Turning our attention to the DXM environment. You will clearly need to have templates in the CMS that will be responsible for three important aspects:
Data entry and management capabilities content managers will need to create, update and manage content;
Producing JSON output (file-based approach above) or pushing JSON to Search G2; and
Providing content managers with a good preview experience so they have some idea how the content they are creating in the CMS will appear on the site. This is going to be the trickiest part of you're only publishing JSON.
As far as implementation approaches go, you could use either straight templating or Component Library.
DXM React SDK?
One possibility to consider is the new DXM React SDK, which allows you to do much of the work in React and have the SDK generate all of the CMS elements including components, templates and models. The React SDK sets up content to publish both JSON files or to push to Search G2.
Another compelling benefit of the SDK approach is that the in-CMS preview is automatically created from the React components. The SDK is very new (launched in the past month) and still under active development to introduce new features as well a fix any issues.