evitaDB is a specialized database with an easy-to-use API for e-commerce systems. It is a low-latency NoSQL in-memory engine that handles all the complex tasks that e-commerce systems have to deal with on a daily basis. evitaDB is expected to act as a fast secondary lookup/search index used by front stores.
Often the product listing page contains listings in differently sorted forms. The typical example is the "Top Sellers" block, which lists the exact same products as the main listing on the page, but sorts them differently. If we could merge these two listings into a single query that returns two results, we could benefit in two ways:
we wouldn't be forced to declare the same complex set of filtering constraints and requirements in two different queries.
the database engine could reuse the computed result of filtered products to satisfy both queries at once - just applying different sorting and paging requirements.
So we end up with a faster and simpler system for this use case, which is ultimately what we want.
Spacing rules
Another common scenario is to skip certain positions in the listing to display non-product data such as advertising or content blocks. While this feature can be implemented using the existing [strip] (https://evitadb.io/documentation/query/requirements/paging?lang=graphql#strip-recordstrip) feature, it requires careful calculations on the application side. If we could integrate spacing rules into the viewport composition, it could be reliably calculated on the database side, and the client application could simply use the existing page requirements, which are much easier to use.
Sticking sorting randomness
Another scenario that the client solves is the reliability of the output to the end user. Consider this situation - we have 10 products we want to promote on the first 3 positions of the listing. In order to cycle them all, we choose to sort them randomly (so every time there are different 3 promoted products out of 10 available). But this could be confusing for the user who refreshes the page or lists through additional pages. This situation can be easily solved by passing the seed from the client side to the random function, which could generate the seed per user and store it in their session cache.
Viewport rules
Often the product listing page contains listings in differently sorted forms. The typical example is the "Top Sellers" block, which lists the exact same products as the main listing on the page, but sorts them differently. If we could merge these two listings into a single query that returns two results, we could benefit in two ways:
So we end up with a faster and simpler system for this use case, which is ultimately what we want.
Spacing rules
Another common scenario is to skip certain positions in the listing to display non-product data such as advertising or content blocks. While this feature can be implemented using the existing [strip] (https://evitadb.io/documentation/query/requirements/paging?lang=graphql#strip-recordstrip) feature, it requires careful calculations on the application side. If we could integrate spacing rules into the viewport composition, it could be reliably calculated on the database side, and the client application could simply use the existing page requirements, which are much easier to use.
Sticking sorting randomness
Another scenario that the client solves is the reliability of the output to the end user. Consider this situation - we have 10 products we want to promote on the first 3 positions of the listing. In order to cycle them all, we choose to sort them randomly (so every time there are different 3 promoted products out of 10 available). But this could be confusing for the user who refreshes the page or lists through additional pages. This situation can be easily solved by passing the seed from the client side to the random function, which could generate the seed per user and store it in their session cache.