[RFC] Vue Storefront architecture discussion

RFC for improved Vue Storefront architecture

This document describes our future plans and ideas (still as a working draft on early stages) for Vue Storefront architecture.

---

(1) Business logic

Motivation and backstory

Our goal is to make Vue Storefront extremely flexible and easy to customize framework for eCommerce. Users should be able to combine different services in any way they want to deliver best shopping experience for their use cases.

Currently even though Vue Storefront is backend-agnostic in theory it’s tied to Magento formats and therefore to the Magento way of approaching eCommerce functionalities.

It’s possible to connect any other backend to Vue Storefront via connector which is basically mapping other eCommerce API to the Magento one. This approach obviously has many limitations and the more connected solution differs from Magento the harder it is to make such connector. The quality of connectors that need to make a lot of workarounds to adjust the way their eCommerce is solving thing to the Magento one is also suffering very much.

We want Vue Storefront to be some kind of Nuxt for eCommerce which means you should be able to choose the technologies you want, install proper modules and build a theme based on this modules. We should fulfil use cases such as

• Product catalog on PIM, headless checkout/cart, CMS content from PIM or Wordpress/Prismic etc
• eCommerce features from Magento, content from other CMS
• eCommerce features from headless solution X, cart from Y, checkout from Z, content from V

…etc. In short words Vue Storefront should be an engine that allows combining different technologies into one eCommerce store rather than a template for Magento.

High-level overview of solution

To fultil this needs we came up with a list of steps that needs to be done to provide truly backend-agnostic solution and ensure the quality of every integration.

Backend-agnostic and platform specific parts

• Vue Storefront core and some parts of theme are the only real backend-agnostic elements.
• Modules from core that are tied to Magento logic should be treated as Magento modules (and potentially moved to another repo/dir).
• Every new integration should have it’s own modules for it’s platform-specific eCommerce/CMS/etc features (for example catalog-magento, catalog-shopware, catalog-woocomemrce, cms-wordpress, cms-prismic etc)
• Modues around one integration are not depending on each other so we can combine different technologies easily.

The implication of having platform-specific modules is a huge reduction in project complexity. In most of teh situations migrator and vs-api can be totally omitted and the communication can be direct via API.

How logic is consumed

• In themes we use modules logic only via Vuex actions/getters (and potentially some helper functions).

• … according to the above statement core components will be depreciated and Vuex api will be improved to expose easy to work with API. It will remove a lot of complexity.

• Core pages will be in proper modules

How Themes will look like

• Themes will be platform-specific but a lot of things can be reused.

Once we have whole communication done through Vuex actions/getter a lot of theming opportunities will open.

• People can easily create new shop designs from scratch and just use core getters/actions
• Themes across different eCommerces will obviously differ hence UI libraries to make the customization extremely easy.

Action plan (early phase)

1. Move old core pages to compatibility folder and remain untouched for backward comaptibility. Make an alias to not break existing shops.
2. Move logic from core pages to Vuex so it can be easily consumed by new theme (Theme 2.0). Old actions and getter must remain for backward compatibility but shouldn’t be included in docs and warnings should be prompted every time they are used.
3. Once we have a good Vuex API for Magento investigate which parts of Vue Storefront outside modules aren’t backend-agnostic and adjust them (special attention for libs and helpers).
4. Once we are done with the core discuss which modules should be platform-specific and mark them as Magento-specific

The plan is still in early stages and we are currently focusing on new theme so everything is open for discussion. We are happy to hear your feedback and will be even more happy if some of you would like to help us with new architecture planning and it’s implementation.

---

(2) Main repo structure for VS 2.0

Project structure of VS 2.0 will be based on encapsulated monorepo packages. VS git repo will be just a container for all packages and project creation process will be moved to cli tool.

This is how VS repo will look like (more or less)

/docs
/packages
   /core
   /theme-default
   /cli
   /...some other packages maintained by core team

Every package inside packages folder is a separate NPM package with separate versioning. It’s pretty standard setup for every monorepo project and is proven to work well. You can read more here

---

(3) Setting up new Vue Storefront projects

New VS shops will be created with help of a cli tool called create-storefront-app - it’s already in progress. The cli will set up a new VS project for you along with proper theme, modules etc.

[grimasod]

I’d like to share some ideas… I believe a good platform-agnostic solution could be to use GraphQL with the “API First” approach.

That is, first define the API for an ideal e-commerce backend, not based on any existing platform. This API could be implemented using a GraphQL server (such as Apollo). The GraphQL data sources can be mapped to anything, like Magento, WooCommerce, Prismic, Firebase, AWS, etc. In cases that data can’t be mapped directly, or requires pre-processing, or caching, they could be integrated though secondary APIs, when necessary. These would be platform-specific installable extensions, like mage2vs.

The Vue Storefront Framework would then be something like:

• Vue Storefront
• Vue Storefront GraphQL Server
• Vue Storefront API Platform (optional server-side platform for secondary API extensions)

Some advantages of this approach:

• Platform-specific logic moved to server
• Single API (easier to secure, easier to log / debug)
• Vue Storefront focused on user interface only
• Vue Storefront modules based on function and are platform-agnostic
• No need to repeat functionality in each module for each platform
• Frontend development shielded from platform-specific complexities

There may be some special cases that can’t be achieved this way, when the operation is too closely linked to the backend platform. This could still be achieved with the platform-specific modules outlined above. In other words, the core would include modules like catalog-graphql, cms-graphql, checkout-graphql, etc., that would cover the majority of cases, but other modules could still be used if necessary.

What do you think?

[grimasod]

A further advantage, that I forgot to mention, would be ease of switching backend platforms. For example, when switching from Magento to an alternative system, it would only be necessary to change the GraphQL datasources, while the whole frontend could remain the same (theoretically!)