Home

Overview

Thank you for your interest in contributing to the Storefront API Project! As part of our journey towards microservices and distributed deployments, we are beginning to decouple all Catalog storefront capabilities from the Magento monolith into an independent storefront application that can be scaled independently.

The benefits of this storefront application will be:

• Highly optimized read APIs for significantly better storefront performance.
• Independent and more frequent updates that deliver business value.
• Highly optimized GraphQL service that can be scaled independently.

Catalog Storefront Service

Catalog service provides shoppers access to products and categories and their attributes. Catalog service is not a source of truth for the data it stores and basically is a projection of the connected management systems like PIM, ERP, etc.

Consequences for data and storage:

• Due to its origin, the data in catalog service is eventually consistent.
• The structure of the stored data is optimized to service storefront reads scenarios. Data denormalized.
• The data is partitioned per store view. The store view is selected as an optimal data distinguisher.

Catalog storefront service will provide read and import APIs.

• Read API's will be exposed to the shopper through the BFF layer such as GraphQL.
• Import API will not be exposed to the public. The purpose of the import API is to populate the catalog database with the data received from the various sources.

Integration

Integration schema has to fulfill the following acceptance criteria:

• The storefront catalog could be deployed separately and does not rely on a source of information it consumes.
• Source for the information could be disabled, replaced, or partially replaced. (Real-life example, AEM allows to override just a few attributes for each product, all other attributes should be pulled from Magento).
• Integration logic should not be a part of the back-office system because of a lack of extensibility - we cannot put enough logic into the external back-office system.
• Another reason, we may need to evolve this layer more rapidly to adjust per discovered cases.

Message Broker

As a result, we come out to a new application - the message broker which will listen to events emitted by the back-office. Each time the message broker receives a new message it performs back lookup for the updated entity data through the API. The data received from a back-office will be correspondingly transformed into the format supported by the catalog storefront import API. The message broker synchronously calls the storefront import APIs. (If import will require queue for the processing of the messages this queue will be added as a private implementation of storefront catalog service).

/Users/niskapoo/Desktop/StorefrontAPIs.jpg)