📄️ Meta modules
We recommend keeping your GraphQL modules small and focused on a single feature, but having many different modules could make distribution more tedious. That is why Front-Commerce supports the concept of "meta modules", which are a way to group smaller modules.
📄️ Slim down resolvers with loaders
GraphQL modules may grow over time: resolvers will have more and more code to provide the required features. In Front-Commerce’s core and platforms integrations, we have introduced the concept of "loaders" to handle this complexity, keep code maintainable and increase testability.
📄️ DataLoaders and cache invalidation
One of the main responsibility of GraphQL modules in Front-Commerce is fetching data from remote sources in resolvers. However, a naive approach may reach a few limits in a real application. That is why Front-Commerce provides helpers allowing developers to build high-performance applications.
📄️ Change a resolver behavior
In a project, it is quite usual to have the need to change the implementation of the resolver associated with a GraphQL field. This page explains how to do it properly so that the project remains as maintainable as possible.
📄️ Remote schemas
If you already have existing headless services exposing a GraphQL API, you might want to reuse them with the lowest possible overhead. This page will explain how you could expose remote GraphQL schemas as part of your Front-Commerce GraphQL schema.
📄️ Rate Limiting
You may want to prevent abuses of your application, for instance, to prevent malicious users from sending many contact form requests or scanning some information with bots. Therefore, Front-Commerce’s core contains tooling that allows you to add basic rate-limiting in a very granular way to any field (Query or Mutation).