Meta modules

If several teams are working on a project, small modules are a way to federate the graph implementation. It also makes it easier to change implementations and service providers later in the project.

For instance, you could replace a Magento2/Cms module with a Wordpress/Cms one without impacting the web application (as long as both schemas share a common API).

Having a lot of different modules could make distribution more tedious. That is why Front-Commerce allows you to author and consume "meta modules".

Using a meta module

TL;DR: there is no difference between using a meta module and a normal module!

Let’s illustrate meta module by analyzing how Front-Commerce’s Magento2 integration can be registered in your project.

If your Front-Commerce application is aimed at being a PWA frontend for a monolithic Magento2 instance, then it is only a one line change to get all the features:

.front-commerce.js

module.exports = {
  name: "Front-Commerce",
  url: "https://www.front-commerce.test",
  modules: [],
  serverModules: [
    { name: "FrontCommerce", path: "server/modules/front-commerce" },
    { name: "Magento2", path: "server/modules/magento2" },
  ],
};

Under the hood, it imports several GraphQL modules at once (Magento2/Cms, Magento2/Catalog, Magento2/Checkout, Magento2/Search, etc..).

How to define a meta module

For a module to be considered as a meta module, you need to expose a list of submodules in the modules key of the module definition (along with the namespace).

Here is an example from Magento2 meta module definition:

node_modules/front-commerce/src/server/modules/magento2/index.js

import Cart from "./cart";
// […]

export default {
  namespace: "Magento2",
  modules: [
    Cart,
    // […]
  ],
};