Documentation

Best practices

To best utilize Connect, we recommend some best practices for when and how to use Connectors.

When to use Connect

Connect can simplify hosting and integrating your applications, however, some types of applications are more suitable than others for use with Connect. To ensure Connect meets your needs, we recommend evaluating the type of application you plan to build. When deciding to deploy an application in Connect, consider the following:

  • Operation type: is the application one of the supported types, which are service, event, job, asset, or Merchant Center Custom Application?
  • Statelessness: can the application operate without persistent session storage?
  • Resource requirements: does your application meet the following CPU and memory specifications for Connect:
    • For service, event, asset, and Merchant Center Custom Applications types: 1 CPU, 512 MB memory
    • For job application types: 2 CPU, 4 GB memory
  • Scalability: does the application handle a variable request or event load effectively depending on serverless infrastructure and the Connect resource requirements?
  • Processing time: can the application complete its tasks within the timeouts imposed by serverless infrastructure?

For each type of application, we recommend different usage guidelines.

Service application

A service application provides specific functions to other applications, often running in the background.

Characteristics

  • Infrastructure: serverless, for example, Cloud Run in Google Cloud Platform (GCP).
  • Scalability: scales based on incoming requests.
  • Resource limitations: uses a maximum of 1 CPU and 512 MB memory, and processing timeouts are in place.
  • Supported applications: stateless HTTP-based applications.
  • Usage examples: API proxies, API extensions, or third-party system webhooks.

Event application

An event application handles events or triggers, often in real time, and subsequently executes further actions or workflows.

Characteristics

  • Infrastructure: serverless with event broker push, for example Cloud Pub/Sub in GCP.
  • Scalability: scales based on incoming events.
  • Resource limitations: uses a maximum of 1 CPU and 512 MB memory, and processing timeouts are in place.
  • Supported applications: processes events from commercetools.
  • Usage examples: Subscriptions.

Job application

A job application manages and executes background tasks for a particular system or workflow.

Characteristics

  • Infrastructure: serverless with scheduler triggers, for example, Cloud Scheduler in GCP.
  • Scalability: runs based on scheduled intervals.
  • Resource limitations: uses a maximum of 2 CPU and 4 GB memory, and processing timeouts are in place.
  • Supported applications: lightweight, recurring tasks.
  • Usage examples: scheduled operations, such as periodic order updates.

Assets application

An assets application is designed to manage and track assets within a system, to help ensure proper usage.

Characteristics

  • Infrastructure: serverless with a content delivery network (CDN), for example, Cloud CDN in GCP.
  • Scalability: scales based on incoming requests and has fixed caching time-to-live (TTL).
  • Supported applications: hosting front-end assets.
  • Resource limitations: uses a maximum of 1 CPU and 512 MB memory, and processing timeouts are in place.
  • Usage examples: serving static assets required by Checkout Payment Connectors.

Merchant Center Custom Application

A Custom Application is an application you've built for use in the Merchant Center.

Characteristics

  • Infrastructure: serverless, for example, Cloud Run in GCP.
  • Scalability: scales with incoming requests.
  • Resource limitations: uses a maximum of 1 CPU and 512 MB memory, and processing timeouts are in place.
  • Supported applications: Custom Applications configured in the Merchant Center.
  • Usage examples: Merchant Center Custom Applications.

When to use a single Connector vs multiple Connectors for multiple applications

When developing multiple applications for Connect, it's important to consider when to use a separate Connector for each individual application and when to use a single Connector for multiple applications. This decision has significant implications for how the integrations are structured, managed, and deployed.

A single Connector for multiple applications

We recommend using a single Connector for multiple applications in the following circumstances:

  • Unified management of related functionalities: when related functionalities can be managed together. For example, a Connector that manages both automated event-based orders and operational tasks around orders in a Merchant Center Custom Application.
  • Coordinated deployment and scaling: when functionalities are related and likely to be deployed or scaled together. Centralizing related applications allows for coordinated scaling and deployment across functionalities, which reduces overhead and maintains consistency.
  • Shared integration points: when different functionalities share common integration points or often need to interact with each other. This simplifies integration by centralizing interactions with commercetools Composable Commerce and other systems, using shared modules and common packages to streamline operations.
  • Cohesive development with a single team: when a single team is responsible for the Connector, ensuring cohesive development across all functionalities. However, deployment failures or issues with the Connector can impact all functionalities, which can reduce resilience and fault isolation across systems.

Multiple Connectors with a single application for each

We recommend using multiple Connectors for multiple applications in the following circumstances:

  • Distinct and independent integrations: when each integration or functionality is distinct and independent from each other. For example, a separate Connector for handling payment processing, inventory management, and customer data synchronization.
  • Separation of concerns: when there is a clear separation of concerns, making it easier to independently maintain and update each Connector. Each Connector operates autonomously, allowing teams to upgrade or fix individual integrations without affecting others.
  • Faster development workflows: when merging multiple integrations into a single Connector can slow down development workflows due to increased code smells, security scans, and deployment processes. Keeping Connectors separate allows for faster development, testing, and deployment without delays caused by unrelated modules.
  • Independent deployment and scaling: when integrations might need to be deployed or scaled independently. Each Connector can be scaled based on its specific load and usage patterns, with isolated impact, ensuring that any Connector deployment downtime won’t affect others.
  • Team autonomy and focus: when different teams are responsible for different integrations, allowing them to work independently. Teams can manage their own specific Connector via separate Git repositories, reducing the risk of conflicts with other teams.
  • Compliance and security isolation: when different integrations require distinct compliance and security measures. Each Connector can be secured independently, reducing the risk of a breach affecting multiple functionalities.

When to use an alternative to Connect

Connect applications are not suitable for use cases that involve:

  • Stateful operations: as Connect is serverless and stateless, applications requiring session persistence or long-term data storage, such as shopping cart sessions or authentication states, are not supported.
  • High resource requirements: applications that are CPU or memory intensive, such as complex analytics or data processing jobs, as these may exceed Connect’s resource limits.
  • Long running processes: Connect imposes strict timeouts, so applications needing extended processing time, such as file processing or report generation, should not be hosted on Connect.
  • Batch processing: applications involving bulk data processing or storage, such as large database transactions or extensive file processing, are not suitable.