openfront-custom-storefront

Start by exporting or introspecting the target product's GraphQL schema, then validate anonymous catalog reads and run negative access tests before building pages. Use named operations with code generation, a same-origin BFF with httpOnly cookies, and implement routes in phases starting with a read-only catalog.

Adapting the built-in storefront reuses existing routes, modules, and server data layers within the product's repository. A separate client must use only the configured GraphQL endpoint and verified external contracts, never importing Keystone models, Prisma, or backend environment variables.

Not safely at canonical commit 6662469. The activeCart, updateActiveCart, payment session, and completeActiveCart roots use sudo without caller binding, idempotency, or atomic transactions, so the host must add bounded, ownership-checked commands first.

No. Each Openfront vertical has its own schema, resolvers, and access rules, so every operation must be derived from the target product's current schema and built-in call sites. Never reuse Ecommerce roots by analogy for another vertical.

Roots like activeCart, getCustomerOrders, and completeActiveCart return the GraphQL JSON scalar, which generated TypeScript types cannot validate. Parse them with Zod or Valibot schemas and fail closed when required IDs, amounts, or ownership evidence are missing.

Keep session tokens, cart IDs, and guest order secrets server-side or in host-only httpOnly cookies behind task-specific BFF routes. Never store them in localStorage, expose them to browser JavaScript, or put them in analytics, cache tags, or durable URLs.