USF-3668: Storefront Architecture and Backend options docs#765
USF-3668: Storefront Architecture and Backend options docs#765
Conversation
Restore the architecture doc from the original PR branch so this branch matches the intended split. Removes images/Architecture.svg (not in source). Adds anchor headings (#commerce-blocks, #runtime-flow) for existing links. Fixes data-export-validation link to backends/#storefront-services. Made-with: Cursor
fnhipster
left a comment
fnhipster
left a comment
There was a problem hiding this comment.
What is the difference between a "Block" and a "Commerce Block"? Is it that they use drop-ins, or their connectivity with our Commerce Back-ends? If so, then why do "Blocks" also have a connection to Backends?
| - **blocks** — Content blocks (Cards, Columns, Headers) and Commerce blocks (cart, checkout, account) | ||
|
|
||
| ## Edge Delivery Services | ||
| Commerce blocks use Commerce APIs; the boilerplate uses <Link href="https://preactjs.com/" text="Preact" />/HTM for complex state. See [Getting started](/boilerplate/getting-started/) for file structure. |
There was a problem hiding this comment.
I think this whole sentence is misleading.
Commerce Blocks integrate with Commerce via GraphQL and are powered by drop-ins. The boilerplate doesn't utilize preact.
| ## Commerce Boilerplate Architecture | ||
| [Blocks reference](/boilerplate/blocks-reference/) · [Blocks configuration](/boilerplate/configuration/) · [Storefront configuration](/setup/configuration/commerce-configuration/) | ||
|
|
||
| The Commerce Boilerplate follows a modular architecture that separates core AEM functionality from commerce-specific features. This separation ensures maintainability and alignment with the upstream AEM Boilerplate while providing robust commerce capabilities. |
There was a problem hiding this comment.
Why are we removing this? No relevant?
| [Drop-ins](/dropins/all/introduction/) are domain-driven commerce components. Install from NPM (for example, `npm install @dropins/storefront-cart`). Use the [extension](/dropins/all/extending/) patterns when customizing. | ||
|
|
||
| The [Commerce Boilerplate](https://github.com/hlxsites/aem-boilerplate-commerce) is organized into four main layers that build on each other to deliver a modular, maintainable storefront architecture: | ||
| <Aside type="note" title="Existing storefront?"> |
There was a problem hiding this comment.
Should we briefly mention when Luma Bridge is recommended and when it isn't? For example, “In some cases like x and y, you may need to bridge your existing Luma storefront with Edge Delivery, go here for that.”
There was a problem hiding this comment.
The Luma Bridge appears connected to Drop-ins, but it isn't. It's actually the other way around.
bdenham
added
major-update
2 participants
Purpose of this pull request
This pull request adds a dedicated Storefront Backend Options topic and updates Storefront Architecture so Get started clearly separates architecture from backend types and prerequisites. It introduces a new Backend options page (Commerce PaaS, Adobe Commerce as a Cloud Service, Adobe Commerce Optimizer) with a comparison table, prerequisites by backend, and a diagram; refreshes the Architecture topic from the get-started-architecture-and-setup work and links it to Backend options; updates the sidebar label to "Storefront Architecture" and adds a "Backend options" entry; and fixes the data-export-validation link to point to the new backends page.
Associated JIRA ticket
USF-3668
Staging preview
Affected pages
What's New highlights
whatsnew
Added Storefront Backend Options to help you identify your backend (Commerce PaaS, Adobe Commerce as a Cloud Service, or Adobe Commerce Optimizer) and confirm prerequisites before storefront setup. Updated Storefront Architecture to align with this structure and point to Backend options.