Introduction

Nacelle's data model

Nacelle leverages a canonical commerce data model. When product and commerce data is transformed in Nacelle, it does so to align with this standardized data structure. The consistency of this structure leads to the following advantages:

  1. An increase in interoperability and abstraction since this model is a standard
  2. An increase in performance for indexing because defined fields are predictable
  3. An increase in velocity because all engineers will speak the same data object language in your composable stack
  4. An increase in productivity since many different spaces can share code and components
  5. A decrease in maintenance costs and headaches because queries do not have to be re-written if something changes upstream from transformations (i.e., in the data source)

Custom and unstructured data

Commerce at scale demands flexibility. Therefore, every object in Nacelle has a key-value store. Any data that does not fit into Nacelle's canonical commerce data model can be dropped into this key-value store, and nacelle promises delivery of this unstructured data.

See the details of the Metafield object

Further customization

Since Nacelle's primary APIs are GraphQL, federation or schema stitching can be used to merge your custom GraphQL with Nacelle's. For more information on these approaches, please see apollographql.com/docs/federation and the-guild.dev/graphql/tools/docs/schema-stitching/stitch-combining-schemas.

Custom schemas can also be used to improve the GraphQL experience for Content by introducing Typed Fields.

Specific object definitions

📘

We use GraphQL notation to describe our Canonical Commerce Data Model

The following documentation pages will provide more details on each object found within Nacelle's canonical commerce data model. They include:

Filter definitions