Mixed Domain and Sub-path Routing

Mixed routing combines domain-based and path-based strategies for complex scenarios requiring both brand independence and configuration variations within specific brands. This approach enables independent brand deployments while maintaining shared user state and dynamic configuration switching within specific stores.

Overview

This hybrid approach enables you to:

• Deploy independent domain-based stores that share components through file-based inheritance
• Implement path-based routing within specific stores for granular integration control
• Maintain independent scaling and deployment for different brands

Real-World Scenario

Consider a large apparel retailer with the following requirements:

• Fashion Main (fashion-main.com) - Primary storefront with shared components
• Luxury Brand (luxury-brand.com) - Independent brand requiring separate deployment and scaling
• Content Differentiation within the main brand:
  • /sportswear - Managed by Marketing Team A using dedicated CMS space for sports content
  • /elegant-wear - Managed by Marketing Team B using different CMS space for elegant fashion

This setup combines domain separation for distinct brands with path-based content management within the main store.

When to Use Mixed Routing

The mixed approach is specifically for scenarios where you need both domain-based and path-based routing. Use this approach when you have:

Domain-based requirements (justifying separate brands):

• Independent brands requiring separate SEO strategies and scaling
• Team independence where different teams need to work on separate stores without coordination
• Independent deployment schedules for different brands

AND path-based requirements within specific brands:

• Multiple configurations on a single domain (SEO requirements, legal constraints) within one of your brands
• Shared user sessions across different sections within a brand

Setting Up Domain-Based Stores

Create two deployable stores using the Alokai CLI:

• fashion-main - Primary storefront that will implement path-based routing
• luxury-brand - Independent luxury brand with separate deployment

Implementing Path-Based Routing

Once you have your domain-based stores set up, adding path-based routing within the fashion-main store follows the same process described in the implementation guide, with one key difference: all implementation happens within the store directory structure (apps/stores/fashion-main/) rather than in the base applications.

Key Implementation Points

1. Config Switcher Setup: Create the extension within your store's middleware directory (apps/stores/fashion-main/storefront-middleware/integrations/)
2. Frontend Configuration: Add the routing logic to your store's SDK utilities (apps/stores/fashion-main/sdk/modules/utils.ts)
3. Store-Specific Styling: Apply configuration classes and CSS variables within your store's style files
4. Conditional Components: Implement component variations using the same patterns described in the Conditional Components section

Mixed Approach Benefits

• Domain Independence: Each brand (luxury-brand, fashion-main) operates independently with its own deployment lifecycle
• Path-Based Flexibility: Within fashion-main, you can dynamically switch between sportswear and elegant-wear configurations based on the URL pathname

Implementation Strategy

Start Simple: Begin with domain-based separation for brands, then selectively add path-based routing only where clear content differentiation needs emerge.

Architecture Guidelines:

• File Overrides: Use for substantial differences (entire layouts, major functionality, brand-specific features)
• Conditional Logic: Use for content variations, styling differences, and configuration switching
• URL Structure: Plan your URL architecture in advance to support configuration switching:
  • Path-based config IDs within stores: /sportswear, /elegant-wear
  • Consider locale placement: /en/sportswear vs /sportswear/en
  • Ensure config IDs align with your Config Switcher configuration keys
• Team Ownership: Consider establishing clear responsibility boundaries to maintain code quality:
  • Shared code responsibility: Designate ownership for base components and common functionality
  • Store-specific ownership: Assign responsibility for store overrides and brand-level configurations
• Minimize frontend customization: Push configuration differences to middleware layer via Config Switcher rather than adding conditional logic to components

Common Pitfalls to Avoid:

• Overusing path-based routing where separate stores would be cleaner
• Creating inconsistent URL patterns which complicates config switching
• Mixing conditional logic with file overrides unnecessarily
• Adding path-based routing complexity without clear business justification

Summary

Mixed routing combines domain-based and path-based strategies for complex scenarios requiring both brand independence and configuration variations within specific brands.