Skip to main content

Choosing Your Approach

Beta

The Storefront SDK is in beta. Content in this section may be updated as the SDK evolves.

Partners building on Propeller come from different starting points. Some are building a new storefront from scratch. Others have an existing website on a CMS platform with its own frontend framework. Some manage multiple brands and sites from one CMS.

The Storefront SDK's three-layer architecture supports three common patterns. Choose the one that fits your project.

Pattern A: Commerce-led (Accelerator)​

The Accelerator owns routing. Commerce pages (product, category, cart, checkout, account) are file-system routes. The CMS handles content pages via a catch-all route.

Propeller Accelerator (owns routing)
├── /product/42/shoes        → ProductService
├── /category/17/electronics → CategoryService
├── /cart, /checkout         → CartService
├── /account/*               → UserService
└── /about-us, /blog/*       → CMS catch-all

Uses: Layer 3 (Accelerator), which includes Layer 2 (UI Components) and Layer 1 (SDK Services).

Best for: greenfield projects where speed to market is the priority and content needs are straightforward. The Accelerator provides a working storefront out of the box.

Pattern B: CMS-led​

The CMS owns all pages, all URLs and all routing. Commerce components are functional blocks injected into CMS-managed page templates. Page structure is fully configurable in the CMS.

CMS (owns routing and page structure)
├── /                        → CMS page with commerce blocks
├── /products/shoes          → CMS page with ProductGrid block
├── /products/shoes/nike-42  → CMS page with ProductDetail block
├── /about-us                → CMS page (editorial only)
└── /cart                    → CMS page with Cart block

Uses: Layer 1 (SDK Services) + Layer 2 (UI Components). The partner imports SDK services and UI components into their CMS's frontend framework and handles routing through the CMS.

Best for: multi-brand and multi-site environments where content editors need to manage everything from one place.

Pattern C: SDK-only with custom UI​

The partner uses SDK services directly and builds all UI themselves. No Propeller-provided components. The stack-agnostic component documentation serves as a reference for what to build and which SDK methods to call.

Uses: Layer 1 (SDK Services) only.

Best for: partners with strict architectural requirements, a framework without Propeller component support, or a need for full control over every aspect of the frontend.

Decision table​

Your situationRecommended approach
You have an existing frontend and just need Propeller dataLayer 1 (SDK only) — import propeller-sdk-v2, use the typed services
You want pre-built commerce components in your existing React or Vue projectLayer 1 + 2 — install @propeller/ui-react or @propeller/ui-vue via npm
You want a working storefront out of the boxLayer 3 (Accelerator) — clone the Next.js or Vue app and customize
Your CMS owns routing and page structureLayer 1 + 2 — use SDK and components, let your CMS handle pages and URLs (Pattern B)
You manage multiple brands or sites from one CMSLayer 1 + 2 — CMS-led architecture where all pages and URLs are managed centrally
You use a framework we don't have components for (Angular, Svelte, Web Components, etc.)Layer 1 + component docs — use the SDK directly and build UI from the stack-agnostic component documentation
You want to prototype or demo quickly for pre-salesLayer 3 (Accelerator) — fastest path to a working storefront
You need a B2B portal with customer-specific pricingAny layer — use semi-closed portal mode to hide prices for unauthenticated users

Next steps​