Use cases and usage guidelines

Creating structured design elements that editors can add to a content page.

Implementing design systems that will be used across one or many sites.

Components that require more complex server-side code to render a section of a web page.

Components that load data from other sources, such as an API, and render it server side.

Interactive components that render both HTML and JSON end points and may interact with other services client-side, for example, writing data.

Components that package up some useful functionality and are deployed to other third-party websites. For example, a course finder added to a portal that is not built on the Squiz DXP.

When the output is so simple that the WYSIWYG editor, your CMS will handle it, for example, basic text formatting. The Component Service is not intended to implement the more atomic style elements of your design system.

Using server-side code to write data to a persistent data store. The Component Service is designed to be cacheable and read-only. Any write actions, for example, submitting a form or sending data to an API to be stored, must only be performed client-side if implemented using the Component Service.

When you want to load data from many different sources in the same process, perform significant computation, or create large amounts of output. The Component Service is limited to a five-second process time. If you are doing more intensive computation, you may need to use another system to generate your output and store it somewhere, such as Datastore, so that the Component Service can retrieve it quickly.

Chaining multiple components together. Loading components from within other components is not supported.

Components that need to return an uncached response. The Component Service currently has a five-minute minimum cache timeout.

When you want to use existing Squiz Content Management Service implementation patterns through the UI. The Component Service uses APIs and JavaScript to render your components in a more industry-standard way. Squiz Content Management Service keywords, asset listings, and other low-code features are no longer used in this approach. Data is loaded through APIs and processed through code. This approach also requires developers to be able to work on code locally and deploy it.

When you need complete control over the editing experience and need to create a fully customized editing interface.

The service is read-only.

Output is always cached.

There is a five-second limit on execution time. The Component Service produces an error if execution runs over five seconds.

It is not advisable to create a dependency chain. The Component Service is not designed to manage inter-component dependencies.

Squiz Content Management Service keywords and other service-specific syntax are not supported inside the Component Service.

It is not currently possible to customize the editing interface generated from your manifest.json. For example, there is no equivalent to custom edit layouts.