[RFC] Refactor Vuex API calls to separate layer

What is the motivation for adding / enhancing this feature?

It would be great to move out all the network/API communication to separate layer. The goal: make it easier to integrate VS with 3rd party backend. Now it’s possible only by exposing the API in our format (https://github.com/DivanteLtd/vue-storefront-integration-boilerplate). We do have a pretty nice mechanism to add abstraction layer over ElasticSearch (https://github.com/DivanteLtd/vue-storefront/tree/master/core/lib/search) using SearchAdapters. Would be awesome if instead of set of functions “serverCartCreate” we do have something like (thinking aloud, don’t bind to the naming): PlatformStrategy.CartAdapter { create, update, delete, sync, totals }, PlatformStrategy.UserAdapter { login, register ...} - typed with TS. So in these adapters user can do the mapping from Vue Storefront internal data format (we can’t change the data formats that we’re currently using to not break the backward compatibility!) to the specific API calls.

What are the acceptance criteria

• we should design this feature with Magento 2.3 graphQL support (to be able to add graphQL support instead of vue-storefront-api) in this separated layer

[patzick]

Yes, definitely we shouldn’t invoke any API calls from components and Vuex actions directly.

I designed that way before and it worked nice: Component needs data -> awaiting dispatched vuex action (action can resolve something from state, prepare request data etc) -> action invoke API layer -> here is our factory which choose GraphQL/REST/Anything -> goes back to action, which can store something (but doesn’t have to!) -> resolves back for component which needed that data at the begining

API layer should be unified - means that vuex action doesn’t have to know context of used API layer - it shouldn’t make a difference if it is a REST or GrapgQL -> invokes call with object as params and waits for (also unified) response.

This approach keeps vuex actions a lot cleaner and separate concerns.

The architecture of vuex modules i’ve used:

store
  - api.ts
  - actions.ts
  - getters.ts
  - index.ts
  - mutations.ts

[pkarw]

I don’t see much value in separated mappers. I mean BigcommerceApiStrategy (keeping to the example I’ve proposed) should do the mapping returning Product, Cart and other VS interface compatible entities. This adapter itself would call BigCommerce rest or graphql api.

Well, it’s basically just a different taste - the same nutrients 😃