Backend Agnostic Frontend — how does it work?
One of the key USPs (Unique Selling Proposition — unique feature) of Vue storefront is that it might work with any eCommerce backend platform.
We do support quite many backends just outside the box:
… but there is a way to integrate your own, 3rd party platform as well. Well, there are basically three different ways to do so! This blog post is just about it.
Generic integration
The easiest and most popular way of integrating Vue Storefront with custom backend has been called “Generic integration”. It’s because this method is all about aligning the backend API and data formats to Vue Storefront generic data format.
You might have seen that our data formats are pretty much similar to Magento formats. We’ve simplified them and aggregated them. Some parts are denormalized on purpose.
We’re trying to avoid the relations known from the standard databases and rather use the DTO concept. For example, Product is a DTO containing all information necessary to display the PDP (Product Details Page): including media_gallery, configurable_children and other features. It's then fairly easy to cache the data for the Offline mode and performance.
Read the full Product entity specification
The generic integration process is fairly easy, three steps procedure:
- Step One Vue Storefront uses Elastic Search as a backend for all catalog operations. We do have three default types of entities that must be supported:
product,category,attributeand two optional entitiestaxrule,cms_blockandcms_pagein the ES. - Step Two The second step is to support the dynamic calls that are used to synchronize shopping carts, promotion rules, user accounts, and so on. To have this step accomplished you’ll need to implement. Check the boilerplate API implementation in Express.js. Some folks have it implemented in the PHP (see the OpenCart integration) some in Ruby (see the Spree integration)
- Step Three Is to configure
vue-storefrontto use the right set of endpoints from Step Two.
Read full step-by-step tutorial (including example JS code)
PROS:
- Visibility + OSS marketing: Vue Storefront, Community, 50 partners (agencies), training, docs all included,
- All VS features (SSR, additional modules) — OOTB
- short time to market.
CONS:
- generic data formats (might introduce some limitations),
- architecture assumptions that might be limiting: eg. elastic search,
- generic solution — so users might want to change to any other backend platform.
Direct integration
In some cases, Generic integration is pretty limiting. For example — product catalog. ElasticSearch layer has been introduced to Vue Storefront in order to speed up catalog querying. It was pretty important as the Magento1 and Magento2 APIs were extremely slow at the time. For the modern, API first platforms like Shopware6 or Commerce Tools — using an additional ElasticSearch layer is nothing but limiting.
Some of the eCommerce platforms do have dynamic sorting/recommendation engines bound to the catalog browsing features where using an additional buffer database (which ElasticSearch is) can prevent you from using these features in the first place.
To be not limited by the Generic integration strategy, Direct integration assumes that some core Vue Storefront modules will be replaced. Modules from a core that are tied to Magento logic should be treated as Magento only modules (and potentially moved to another repo/dir). I mean: catalog, cart, user.
You can replace these modules in the src/modules/index.ts the file without even touching the core :)
Every new integration should have its own modules for its platform-specific eCommerce/CMS/etc features (for example catalog-magento, catalog-shopware, cms-wordpress, cms-prismic etc)
By replacing the whole catalog a module you can easily replace ElasticSearch with just a direct call to the platform API, replace the REST calls with the graphQL calls and so on.
Additionally — one might want to put the Storefront UI on top of it (we’re currently working on SFUI based theme for Vue Storefront by the way)in order to add the additional UI abstraction layer.
PROS:
- All the benefits of positioning as a “Vue Storefront Connector”
- Most of the docs + trainings + VS partners ready to work with new frontend,
- We recommend publishing it as OSS to grow the community,
- Optimized data flows in/out API,
- Optimized data formats,
- Dedicated, upgradeable theme — to leverage on UX best practices.
CONS:
- limited compatibility with Vue Storefront (Core, but not all of the modules)
- part of the dedicated code that is not maintained by the community
Native integration
The last integration strategy is to just … well use just some libs (like Storefront UI) and components from Vue Storefront — but actually create a dedicated frontend application.
In this case, you’re not using much of the Vue Storefront code at all. Probably just the server app, SSR renderer, caching mechanism plus Storefront UI.
It can be the most optimal way of binding to the backend platform. It’s extremely fast, extremely low footprint.
By the way — this is our integration strategy of choice for Shopware6 (expect Developer Preview Release in January). It will be fully implementing Storefront UI with all it’s features and based on NuxtJS. The key reason was to leverage the full potential of Shopware Customer Experiences CMS. It’s like building a kind of new product (and this is a reason why Shopware6 integration will be released under the
shopware-pwa by Vue Storefront). We’re super excited about it :)
PROS:
- Optimized/dedicated data flows in/out API,
- Optimized/dedicated data formats,
CONS:
- Different data formats (steeper learning curve),
- Themes, modules can be not exchangeable between backend platforms.
Contact us
If you’re working on your own Vue Storefront integration and need some help — don’t hesitate to contact me via peter@vuestorefront.io
