Crystallize logo

GraphQL is ideal to query structured product catalogues fast

Psst: we are hiring remote frontend developers and backend developers.

Illustration of backend developer holding a laptop against a designer holding a picture of cat

The product catalogue (PIM) is the heart of any e-commerce solution. In Crystallize we have based our API for the product catalogue on GraphQL to have a great developer experience and to provide a low latency API. We wanted the developers to have the freedom when building the user interface, typically in React, without having a back-end that slows them down.

REST API latency kills performance

With a traditional REST API you typically would do several calls to the back-end to render a page in an e-commerce solution. The reason is that REST APIs very often are atomic by design and are typically delivering too much or too little data. Multiple calls to the back end quickly stacks on and your performance suffers. For these reasons we decided to go for GraphQL for our catalogue queries.

GraphQL for surgical accuracy in data transfer

Consider a list of products; here you want to fetch the list of all products in the selection and with the associated content like name, main image, price etc. The beauty of GraphQL is that we can specify in the query specifically what data we want returned. This saves data transfer size and time.

We can request more complex content structures like products and relevant meta information we also limit the number of queries to the back-end API down to a single one. This is great for performance and latency where the goal is a single query to the back end for each page render.

Redis for real time API performance

GraphQL is not a silver bullet in terms of performance, you can also do it wrong. I have seen several examples of GraphQL API implementations where it just hooks to the REST API in the back-end. The result of a GraphQL call could then result in tens or hundreds of REST API calls which will kill your performance. For that reason it is important to have a native implementation for GraphQL and ideally all in memory.

We decided to go for Redis as the layer where we have product catalogue structures in pre sorted sets. This allows us to linearly scale with constant performance of about 5ms response time for our GraphQL calls. The developers loves this and so does the end users.

Editorial, developer and customer experience in one

Below you see the connected loop of editorially created products that are instantly available in the GraphQL API. For us this serves the following goals:

Oh, and not to mention that this is great for Google SEO as they promote content that is served fast. You know how many slooow e-commerce sites there are out there and you do not want to be part of those.