Make Integration Architecture Decisions
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the tradeoffs between implementing integrations client-side versus server-side.
- Describe how the loose coupling principle provides for fault tolerance.
Introduction
The next architectural decision is where integration logic runs—in the shopper’s browser or on the server—and how to structure an integration so a single component failure doesn’t take down the whole feature. Facebook and Apple Pay each offer both a client-side and a server-side path, making them ideal for examining these tradeoffs.
Client-Side Versus Server-Side Integration
Most integrations run in one of two ways: code in the shopper’s browser (client-side) or code on the B2C Commerce application server (server-side). Both approaches have the same goal but different risk profiles.
The choice between client-side and server-side is critical and specific integration requirements dictate the implementation. For example security-critical integrations, such as payments and fraud checks require server-side security. Whereas, client-side integrations can be reserved for noncritical activities like user tracking, where the impact of a service failure has fewer severe consequences.
Server-Side
Server-side integrations run on the B2C Commerce application server. The data exchange bypasses the shopper’s browser entirely.
Server-side integrations provide more reliable, browser-independent data collection through direct server-to-server communication. They address evolving browser privacy standards like third-party cookie deprecation and are not affected by ad blockers or client-side JavaScript failures. However, they require more complex API configuration and credential management, and can lack flexibility for custom events outside the platform's standard implementation. A server-side approach is particularly valuable when:
- Consistent, reliable data transmission is critical.
- Future-proofing against browser restrictions is needed.
- Minimal storefront customization is preferred.
- Secure server-to-server authentication is required.
Salesforce recommends prioritizing server-side options when available to ensure integration reliability as browser privacy standards continue to evolve.
Client-Side
Client-side integrations offer simpler initial setup and greater flexibility for capturing browser behaviors and custom events. They provide direct access to user interactions and can be easily customized or disabled based on existing instrumentation. However, they are increasingly vulnerable to browser privacy features, ad blockers, and third-party cookie deprecation, making them less reliable for consistent data collection. Client-side approaches work well when:
- Direct browser interaction and user behavior capture is needed.
- Custom events or tracking beyond standard implementations are required.
- Simple configuration with automatic code injection is preferred.
- Preexisting client-side instrumentation needs to be maintained.
Loose Coupling and Fault Tolerance
Loose coupling is an architecture principle where components interact through well-defined interfaces rather than direct dependencies. When one component changes, fails, or gets replaced, the others remain untouched.
LINK Cartridges Are Independently Swappable
A merchant activates Apple Pay through the Standard Payment API or a LINK cartridge—the storefront checkout flow is identical either way. The PSP absorbs the implementation detail. If a merchant changes PSPs, they install the new LINK cartridge and update the cartridge path. Link cartridges are not plug and play. They require some code updates when swapped. Similarly, removing int_google and int_socialfeeds from the path removes the Google Channels integration without touching app_storefront_base.
Service Configuration Is Decoupled from Code
Google Merchant credentials live in service records under Administration Operations Services, not in cartridge code. Switching between sandbox and production means updating two service records (google-surfaces-api-preprod, google-surfaces-api-prod) with no cartridge changes. The cartridge calls the service by name; the service framework resolves the endpoint and credentials at runtime.
Hooks Fire Without Knowing the Handler
When B2C Commerce generates the Facebook catalog feed, it fires a feed transformation hook. A custom cartridge registers the handler; the platform code has no knowledge of what it does. If no handler is registered, the default behavior runs. Neither side depends directly on the other.
Parallel Paths Provide Fault Tolerance
The Facebook integration illustrates fault tolerance through parallel paths. The pixel collects events in the browser; the Conversions API collects the same events on the server. If the browser blocks the pixel, the Conversions API path continues independently.
The two paths are complementary, not redundant. The Conversions API applies only when B2C Commerce injects the pixel and doesn't cover custom events from third-party tracking tools.
Apple Pay has the same structure: the Standard Payment API and the LINK cartridge path both produce the same checkout experience. For a merchant whose PSP hasn’t implemented the Standard API using the LINK cartridge, the storefront flow doesn't change.
Parallel paths are not available for all integrations.
Next Up
In this unit you learned that while client-side integrations offer lower setup complexity, they face risks like cookie deprecation and browser-based blocking that server-side integrations avoid through more robust server-to-server configurations. You also learned that by applying the principle of loose coupling—through swappable cartridges, replaceable job steps, and externalized credentials—you can ensure that these components remain independent and fault-tolerant. In the next unit, you learn how to manage these integrations using the B2C Commerce web services framework for central registration, rate limiting, and circuit breaker protection.