Vue-storefront: [RFC] Vue Storefront architecture discussion

[filrak]

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.

[Adel-Magebinary]

Maybe remove ajax? And move to WebSocket too?

[pkarw]

I had some time during the weekend so I've refactored Category.js a little bit: https://github.com/DivanteLtd/vue-storefront/pull/2724

It's like point no.2 accomplished:
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.

@patzick, @Igloczek, @filrak could You point out in here what else should we refactor to have this Category.js ready for Theme 2.0

Next step will probably be to:

• (A) confirm this direction,
• (B) refactor Product.js,
• (C) move the core/pages to compatibility,
• (D) create Product and Category 2.0 in core/modules + start implementing theme 2.0

Any ideas on how (D) should look like?
We can do (B)+(C) in 1.10 safely.

[lukeromanowicz]

How about a complex module extending mechanisms with dependency check that would be resolved in building step by webpack? Currently, we only have extendModule supporting stores and routes but both code versions reach browsers, I believe. Also loading files with fallback to base module/theme would be useful, especially in themes. We want the app to be both extensible and thin after all.

Putting a little bit more pressure on Unit Test coverage would ensure better code quality and maintainability. Also not a single word about typescript and Vue 3.0. What's your point of VUE on that?

[filrak]

@lukeromanowicz improved module API is in a roadmap too ;) just not a main focus yet. In short words you can imagine it being more and more similar to Nuxt modules (which includes build time registration you mentioned) + ability to easily distribute modules into different routes and components via abstraction on top of Vuex (similar to RouterManager) - happy to discuss it via priv if you're curious about this topic.

Regarding unit tests - new code will be unit tested at the time of writing it. For the old code we need to figure out few things about how we're gonna approach it (what we refactor, what stays platform specific etc) before we're gonna approach it's testing.

Regarding TS and Vue 3 - not yet discussed. As i mentioned in a post plan is on early stages and first we want to discuss the big picture and go down into implementation details later. Also Vue 3 migration itself should be straigtforward as it mostly affects View layer

[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!)

[filrak]

@grimasod

There may be some special cases that can't be achieved this way, when the operation is too closely linked to the backend platform

Unfortunately it appeared to be much more than "some" cases after doing more integrations. Generally speaking you're right and this is also what we want to achieve. We also think that the more backend-agnostic modules we have - the better. The only difference is that we're moving VS-API layer to client side. We are experimenting with client-side mappers for backend-agnostic modules (replacement of VS-API indexers) but it's too early to say how it'll go.

To clarify. By saying

Once we are done with the core discuss which modules should be platform-specific and mark them as Magento-specific

I meant exactly the thing you're talking about (except GraphQL which I also agree about but I'm not sure if it will be that easy to migrate once we move completely to GQL since even though we're calling it 2.0 it should be easily upgradable from 1.x)

Perhaps @pkarw could say more on this topic ;)

[fancydev18]

since even though we're calling it 2.0 it should be easily upgradable from 1.x
Maybe this could be a nice to have. Since you're reconsidering the basis of a potential client eCommerce framework, why set limits required by 1.0 compatibility?

Projects on 1.x could remain on 1.x for as long as desired, or companies would pay developers for a new 2.x frontend, using only the same data (products, categories...)

[pkarw]

Refactoring status:

• Category Page - #2890 to be finished in next 1-2 weeks,
• Product Page - #3093 - discussing the scope - to be finished (stage 1.0 - MVP for vs 2.0) - end of July,
• Checkout Page - won't be refactored; will be created from scratch in Theme 2.0 (#3024)
• My Account Page - won't be refactored; will be created from scratch in Theme 2.0
• Login/Register - won't be refactored; will be created from scratch in Theme 2.0
• Home Page - won't be refactored; will be created from scratch in Theme 2.0

[pkarw]

We should move the cms, compare, newsletter, recently-viewed, social-share and wishlist modules to separate repos + include them in the theme as a package.json dependencies. -> #3094

[pkarw]

We should remove the compatibility from the core with the 2.0 release (I mean - lets move it to separate repo and let the users mount them under webpack aliast in case of backward compatibility)

[pkarw]

We should also have the #2760 implemented by the 2.0 release. Would be great if you @filrak can wrap up the ideas for the enhancements there next week - then uppon approval on that let's take 2-3 full days to implement the changes - probably even for 1.11 (it should be backward compatible in the end)

[pkarw]

Related #3050

[pkarw]

Related #2918

[pkarw]

I just realized that what @grimasod describe in his comment from 22 may is +/- Vue Storefront Next: https://medium.com/the-vue-storefront-journal/vue-storefront-whats-next-362362db44da?source=collection_home---7------0-----------------------