Announcing Vendure v3.1

At the recent Vendure Conf 2024 we announced our newest feature release: Vendure v3.1! In this post we'll introduce some of the major new features now available.

Vendure's new caching mechanism

Caching is a means of avoiding doing the same work more than once. When we look to increase performance, it is one of the most powerful tools available.

In this release, we are shipping a brand new caching mechanism in the core of Vendure.

First, let us consider a real-world example that motivated the development of this feature. A common way to set up promotions in Vendure is to base them on facet values: "if the order contains any products with the 'summer sale' facet value, discount that order line by 10%". Behind the scenes, whenever you add something to the order, each line needs to be checked against this promotion. When you consider that there might be 50 or 100 such promotions, and 100 order lines, you can probably imagine that the amount of time spent checking the facet values becomes significant. In fact, we found that this exact scenario was leading to unacceptable performance in some cases.

The obvious thing to do is to cache the ids of each facet value associated with a given product variant. The problem is, what happens when a product variant is updated? What if the facet values change? Now we get into the topic of cache invalidation - a famously hard problem.

Vendure is commonly deployed in a multi-instance configuration. This means there are multiple servers running at the same time. If we cache data on one instance, it won't be available to the others. If we update a product variant on one instance, we have to way to invalidate any cache on other instances.

This is precisely what our new CacheService solves. It is a cache layer that is shared across all instances.

Since every instance shares the cache, it means we can aggressively cache data for a long time, and invalidate it only when we know the value changed, and this gets then propagated to all instances.

Furthermore, the cache features pluggable backends - we ship with support for database and Redis storage, but you can implement your own adapter for memcached or any other solution.

In v3.1 we already implement this caching in our built-in promotion logic, so you should start seeing a performance improvement after upgrading if you make use of this type of promotion.

You can read more in our new Cache documentation, including how to configure the new cache plugins for your application, and how to make use of the CacheService to speed up your own custom code.

The OrderInterceptor API

The OrderInterceptor is a brand new API that allows you to run code before any changes are made to an order, i.e. adding, updating or deleting lines.

This is a low-level API that unlocks a number of new capabilities which were previously not possible to implement without overriding all of the order-related mutations. This work-around is not only a chore to implement - it also breaks down as soon as more than one plugin wants to modify order-related behaviour.

With the new order interceptor API you can hook into any order modifications and reject them based on your own custom logic. Moreover, multiple interceptors can be defined, allowing complex behaviour to be composed, whilst keeping logic encapsulated inside plugins in a truly re-usable way.

Some use-cases for order interceptors include:

• Preventing certain products from being added to the order based on some criteria, e.g. if the product is already in another active order.

• Enforcing a minimum or maximum quantity of a given product in the order

• Using a CAPTCHA to prevent automated order creation

• Ensuring product bundles are purchased as a unit

You can read more in the OrderInterceptor documentation.

Struct Custom Fields

A highly anticipated feature is support for a brand-new struct data type for custom fields. A struct is a key-value structure which allows you to define a set of sub-fields, each of which can have its own distinct data type, label, validation rules, and UI component.

Previously, such functionality had to be hacked together by storing a JSON-stringified object in a text field. This work-around was however error-prone and required a significant amount of custom development.

With native support for structured data, you now have this advanced capability at your fingertips with all the ease of custom fields.
With the above definition, we get all the features we expect from custom fields: a type-safe GraphQL schema, auto-generated UI form controls, input validation, and more.

You can read more in our struct custom fields documentation.

Complete custom field support

Staying on the topic of custom fields, we have now expanded custom field support to all entities. With this release you can now define custom fields on: Session, Payment, Refund, ShippingLine, StockLevel, StockMovement and HistoryEntry.

Custom fields are one of the super powers of Vendure. This extended support unlocks even more customization opportunities and allows complex custom logic to be implemented.

Other notable changes

• We are shipping a new AddressBasedTaxZoneStrategy which detects the appropriate tax zone based on the customer's address. In most cases this is preferable behaviour to the default

• The default StockLocationStrategy has been updated to work with multi-channel, multi-location setups out of the box.

• The default logic for rounding monetary values has been updated to behave in alignment with most peoples' expectations (see related issue)

• The AssetServerPlugin now allows better control over image transforms with the new ImageTransformStrategy, including an out-of-the-box strategy to limit transformations to presets only.

• The rich text editor in the Admin UI can now select & embed images from the Vendure assets library.

• Plugin compatibility errors can be ignored to make certain upgrade scenarios easier.

• New GraphQL API mutations have been introduced to unset the billing and shipping address on an order.

For the complete list of changes, see the Vendure v3.1.0 Changelog.

Thank you to all contributors

The following community members contributed to this release. Thank you all!

Ahmet Tok, Alexis Vigoureux, Andrii Baran, Eugene Nitsenko, Javier Elices, Jeremy Milledge, Julian Pufler, Leftovers.today, Marc Schipperheyn, Martijn van de Brug, Oliver Streißelberger, Shingo Aoyama, Tiis, dfernandesbsolus, oidt.