Storefront Architecture

These short topics give you a working map of documents, delivery, blocks, drop-ins, events, and Commerce services. You will also see which layer to check first when a block will not render, a drop-in shows no data, or Commerce calls fail.

How the pieces fit together

Merchants create pages as documents. Edge Delivery ServicesAdobe's hosting and delivery infrastructure that turns authored documents into fast HTML pages served from servers close to the shopper. You push code to GitHub; Edge Delivery Services builds and publishes automatically. turns those documents into HTML. Your Git repository runs JavaScript in the shopper’s browser to load the right Commerce UI for each block on the page. Drop-in componentsNPM packages that provide core Commerce storefront features such as cart, checkout, product details, and account flows. inside those blocks call Adobe Commerce APIs to load real product, cart, and account data.

If you are new to this stack, think of it in three layers: an authoring layer (how merchants create pages), a delivery and logic layer (how pages load and run code), and a data layer (where live Commerce information comes from). The diagram below shows all three at once.

Loading diagram...

Merchants create documents that Edge Delivery Services converts into HTML blocks. Content blocks display text and media. Commerce blocks load drop-in components, which call Adobe Commerce APIs for live cart, product, and account data. The Commerce boilerplate (your Git repository) is the code that connects blocks to drop-ins.

How this differs from a classic Commerce storefront

In a classic storefront, Adobe Commerce often builds shopper-facing pages with PHP. On this storefront, Edge Delivery Services delivers the HTML and JavaScript. Drop-in components call Commerce APIs from the shopper’s browser when they need live cart, product, or account data. The Commerce Admin, catalog, and order tools stay on the server. You change how the storefront page is assembled, not how Commerce stores data.

Key concepts

Edge Delivery Services

Edge Delivery Services (EDS) is Adobe’s cloud delivery network for storefront pages. It turns authored documents into HTML and serves those pages from servers close to the shopper, so pages load fast. You do not manage servers or deployments. When you push code to GitHub, EDS builds and publishes automatically.

Document Authoring and DA.live

Document Authoring is the way merchants create and update storefront pages without writing code. Pages are written as documents in Google Docs, SharePoint, or directly in DA.live (Document Author). Tables in those documents define the blocks on the page. Site CreatorApp in Document Author (DA.live) that creates and initializes a storefront by setting up content, optional code, theme choice, and storefront configuration values., the tool you use to set up a new storefront, also runs inside DA.live.

Content blocks

A content block is a named section of a page that displays layout and marketing content, such as heroes, card rows, columns, headers, or footers. Merchants create them as document tables. EDS converts each table into a div with a matching class name. Your repository holds the JavaScript and CSS that renders that div on the page. Content blocks do not call Adobe Commerce APIs.

Commerce blocks

A Commerce block is a named page region for interactive Commerce experiences such as cart, checkout, product detail, sign-in, and account. Merchants create Commerce blocks the same way as content blocks, using a table in a document. The difference is what runs in the browser. The block’s JavaScript loads a drop-in component and initializes it with your Commerce endpoint and configuration.

Commerce boilerplate

The Commerce boilerplate is a starter template for your storefront repository. It starts from Adobe’s Commerce boilerplate template and holds everything your storefront needs to run: block decorators (one JavaScript file per block under blocks/), initializer scripts that configure each drop-in (scripts/initializers/), styles, and your storefront configuration file. This is the code you own, customize, and push to GitHub.

Drop-in components

A drop-in component is an npm package (@dropins/storefront-*) that ships a ready-made interactive slice of the Commerce UI, such as cart, checkout, sign-in, or product details. In the diagram above, drop-ins sit between Commerce blocks and Adobe Commerce APIs. A Commerce block loads its drop-in first, then that drop-in calls the APIs for live data. You install drop-ins with npm, configure them in scripts/initializers/, and extend or style them when the defaults are not enough.

Adobe Commerce APIs

Adobe Commerce APIs are the endpoints that drop-in components use to read and write live Commerce data like product details, cart contents, orders, account information, and so on. They include GraphQL and REST. Adobe also provides hosted Commerce Services, including Catalog Service, Live Search, and Product Recommendations. These services return catalog data to the storefront faster than the core GraphQL APIs alone.

Quick reference

Piece	One-line job	Where to find it
Document	Where merchants create and edit pages	Google Docs, SharePoint, DA.live, or Universal Editor (a visual editor for rendered pages)
Edge Delivery Services	Turns documents into fast HTML pages	Adobe-hosted; see AEM documentation for how it builds and deploys pages
Content blockEdge Delivery Services blocks used for non-commerce page content and layout, such as cards, columns, headers, and footers.	Displays text and media layout on a page	blocks/<name>/<name>.js in your repo
Commerce blockJavaScript blocks that integrate drop-in components into Edge Delivery Services pages to power storefront commerce experiences.	Loads a drop-in for interactive Commerce UI	blocks/<name>/<name>.js in your repo
Commerce boilerplatePre-configured storefront with the components and services you need to get started.	Starter code for your storefront GitHub repository that connects blocks to drop-ins	Commerce boilerplate template
Drop-in componentNPM packages that provide core Commerce storefront features such as cart, checkout, product details, and account flows.	Ready-made Commerce UI package	@dropins/storefront-* on npm
Adobe Commerce APIs	Endpoints drop-ins call for live Commerce data	Your Commerce backend — Commerce PaaS, Adobe Commerce as a Cloud Service, or Adobe Commerce Optimizer

Go deeper

Read in order the first time through. Each topic builds on the previous one. After you have run the boilerplate once, you can jump ahead for lookup. If you open Events on day one with no context, it can feel out of order; the architecture pages above prepare you for that topic.

1. How a page loads The step-by-step timeline from an authored document to a Commerce API call in the browser.

2. Blocks and the repository How documents, blocks, your Git repo, and drop-ins connect, plus which boilerplate folders to open first.

3. Drop-ins at a glance What a drop-in package contains, how you install one with npm, and where to go when you need to extend or customize.

4. Drop-in coordination How multiple drop-ins on the same page communicate through a shared event bus so cart, checkout, and auth stay in sync.

5. Commerce services and backends The full system stack: hosted Commerce Services, core GraphQL, and how your backend type affects what you install.