Use cases and usage guidelines

The Component Service is flexible and can be used in various ways. There are some circumstances when the Component Service should not be used or is not supported.

Suitable use cases

The Component Service is designed for the following key use cases:

  • 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.

Unsuitable use cases

Use cases where Component Service may not be suitable:

  • 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.

Use cases where the Component Service is not suitable or not supported:

  • 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.


You should be aware of the following limitations of the Component Service. Some of these are by design, while others will be addressed as new features are rolled out to the service.

  • 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.