yireo / magento2-sync-graph-ql-session-with-frontend
yireo/magento2-sync-graph-ql-session-with-frontend
Magento 2 module to sync a GraphQL session with the regular session
Yireo SyncGraphQlSessionWithFrontend
Magento 2 module to sync from the GraphQL session to the Knockout session and from the Knockout session to the GraphQL session.
Summary
- The GraphQL cart token (aka
masked_id) is added to the CustomerDatas sectioncartof the Knockout frontend (customerData.get('cart')) which is automatically synced by Knockout to local storage; - Within local storage, you can fetch the GraphQL token again from
mage-cache-storage.cart.masked_id, for instance if you are switching from a regular Knockout frontend to a React-based checkout;
Kudos
Thanks to Willem Wigman for coming up with the idea for putting the cart token in the section data.
Proof-of-Concept for cart
Use a GraphQL client within React to generate a cart token:
mutation {
createEmptyCart
}
The result might be something like the following:
vGS4ZLj6LkFVrH5CkAPEapLhgfbsoQKF
You should now be able to navigate to the Knockout frontend. After making a modification to the cart (adding a new item, changing the quantity or just wiping out local storage), you can then inspect the local storage entry mage-cache-storage.cart.masked_id: It should hold the same token as mentioned above.
If you add a product to the cart in the Knockout frontend, the same product should be there in the GraphQL session as well:
query cart($cartId: String!) {
cart(cart_id: $cartId){
id
items {
product {
sku
}
}
}
}
Now, add a product to the cart (in this case with a product SKU 24-MB04:
mutation addToCart($cartId: String!) {
addSimpleProductsToCart(input: {
cart_id: $cartId,
cart_items: [{data: {quantity: 1, sku: "24-MB04"}}]
}) {
cart {
id
total_quantity
items {
id
prices {
row_total {
currency
value
}
}
product {
url_key
}
}
}
}
}
Next, head over to the Knockout frontend, wipe out local storage mage-cache-storage.cart (or do this in Knockout via customerData.clear()) and inspect the cart again.
Proof-of-Concept for customer
Use a GraphQL client within React to generate a customer token:
mutation login($email:String!, $password:String!) {
generateCustomerToken(email:$email, password:$password) {
token
}
}
Next, login as the same customer in the Knockout frontend. The local storage item mage-cache-storage.customer.customer_token now refers to the same GraphQL token.
This probably needs some enhancement, so that you are logged in right away in either frontend, without loosing security.
Changelog
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog,
and this project adheres to Semantic Versioning.
[Unreleased]
[0.0.2] - 2020-07-10
- Complete refactoring to use CustomerData sections
[0.0.1] - 2020-05
- Initial draft with a GET token
Requires 3
| Package | Constraint |
|---|---|
| magento/framework | ^100.1|^101.0|^102.0 |
| magento/module-checkout | ^100.1 |
| magento/module-quote | ^100.1|^101.0 |
Compatibility
Each Magento release line is installed on its supported PHP versions, then the module is built (DI compilation + static-content deploy) and its unit and integration suites are run. The matrix shows the lines and PHP versions the module is confirmed to install and run on. Code-quality results further down (phpstan, phpcs, …) are reported separately and never affect compatibility.
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | not tested | not tested | ||
| 2.4.8 | not tested | not tested | ||
| 2.4.9 | not tested | not tested |
Code Quality
Advisory checks against the module's source. Static analysis runs once across the whole module; PHPStan re-runs per Magento + PHP version because resolvable symbols differ between releases. These NEVER affect the Compatibility badge — a phpcs finding can't make a module incompatible.
Static analysis
Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, composer.json validity. Each runs once for the whole module.
PHPStan
Type-checks the module's PHP against a real Magento install at the configured gate level. Re-runs per Magento and PHP version because resolvable symbols differ between releases. Cell → details modal.
Tests
Unit and integration suites, run for each applicable Magento and PHP version. A test failure speaks to the module's behaviour, not its compatibility with a Magento line, so it is reported here separately and never reddens the compatibility matrix.
Unit tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Integration tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Security
Security checks run directly against the module: an audit of its declared dependencies for known vulnerabilities (composer audit) and a scan of its source for malware and web-shell signatures. Each runs once. A malware detection fails the version outright.
More from yireo
View vendorTurn an existing module into recurring revenue.
If you already maintain a Magento 2 module on GitHub or GitLab, listing it on Packagento takes about five minutes. We mirror your tags, handle distribution signing, and route paid licenses through Stripe Connect, so you can keep shipping the way you already do.