Skip to main content

Concepts

Before starting to develop a frontend application, it is essential to understand the underlying concepts and the approach proposed by Discovery CMS. Unlike traditional CMS, which deliver HTML pages directly to the browser, the Discovery CMS has a headless approach: the frontends, whether websites or applications, are developed using any frontend framework (e.g. React or Vue), or using server-side approaches (PHP, Python...). The role of the CMS, in this case, is to make the contents and pages available via API, leaving the person creating the frontend the choice of organizing the display of these contents/pages.

The frontend can therefore be created in any technology that is capable of consuming a REST API (and, in the next version of the CMS, GraphQL). However, if you use a Javascript-based framework, Discovery CMS provides a connector that:

  • facilitates communication between frontend and backend
  • allows you to build pages on the CMS backend using the React/Vue/etc components as bricks. which are made available to publishers

The advantages of the Discovery CMS are therefore:

  • dynamic access, by the application, to all or part of the contents, without having to release a new version when, for example, a hero image on a page changes;
  • possibility for site/app administrators to create new pages or modify existing ones using a library of components made available by the developers.

If, for some reason, you do not want to allow administrators to modify the structure of the pages, for example because some application logic could be violated, it is naturally possible to inhibit this possibility.

Preview vs Production View​

In order to allow for content updates when the site is already in production, the Discovery CMS always provides two data views:

  • preview view: it is the view that is updated when saving as draft (draft)
  • production view: this is the view that is updated when you publish

The normal workflow involves data being updated and saved as a draft, possibly activating workflows review by other users if necessary.

Only when the contents are to be published to end users are they brought from the "draft" state to the "published" state. Of course, in cases where no revision is necessary and you want to update the public site immediately, you can avoid saving as draft and publish the changes directly.

It is important to keep in mind that the preview view refers only to the page or content you are editing. If the current page/content refers, via a Reference type field, to other contents, the published view of the referred content is recovered in the preview. For example, let's say you opened a home page in the Page Editor that lists a "T-Shirt Red" product. It is possible that someone has changed the title of the reported product, but has not yet published it. In the page preview, "T-Shirt Red" will always be shown and not the title with the latest changes. This ensures that the preview of the page or content is faithful to what users will see as soon as the current page or content is published in production.

Custom APIs​

The Discovery CMS offers a standard REST API (and, in the future, GraphQL API) that can be used by frontend applications to retrieve content from the repository. In addition to the CMS APIs, however, the application may need additional APIs, for example to interact with other systems or offer features not included in the CMS.

In this case two approaches are possible:

  • use a set of APIs in addition to the CMS APIs: you can use your own layer of APIs in addition to those provided by the CMS;
  • extend the CMS APIs by creating specialized endpoints that can facilitate or optimize interactions between them of the application with the CMS itself.

The first solution can be adopted completely independently, while for the extension/customization of the CMS API it is necessary to make use of the Professional Services offered by Reply.