Building a generational company requires exceptional, hard-working people.
We are tackling the complexities of commerce infrastructure that no one else has dared to.


## Change how commerce is built



small

Header

Grid

Change how commerce is built

Careers

<p class="text-regular font-medium text-theme-text-primary">
  Try Medusa
</p>
<p class="text-regular text-theme-text-secondary">
  Spin up your environment in a few minutes.
</p>



Transition to Next.js 14 with Server Components

## **The challenge**

Medusa is an [open-source backend commerce framework](https://medusajs.com/) with APIs and tools to manage Products, Orders, Customers, and more. For everything beyond standard commerce functionality, we make it easy to introduce your own custom data models, business logic, API endpoints, etc. Medusa’s APIs can be used in storefronts that your customers interact with - an example of such a storefront is our [Next.js starter](https://medusajs.com/nextjs-commerce/).

On many websites, content changes relatively infrequently. And when it changes it’s often acceptable that there is some delay between content updates to visitors seeing it. For a blog post, for example, it’s acceptable that a few minutes pass between hitting publish and the post showing up on the site. When this is the case, statically generating and serving the webpages via a CDN greatly benefits visitors as the page loads quickly.

In ecommerce, however, dynamism is crucial. When a customer adds something to their cart, it should happen instantly. If a product sells out, it should be immediately clear to all customers. And with multi-currency and personalized prices, the customer should see the price they will be charged in real time. Ecommerce websites, therefore, have to interact with a server that can deliver this information. Front-end frameworks like React all have mechanisms for this and in the past years, the common approach has been directing browsers to fetch data from servers that the framework would then render to HTML on the client.

This is also what Medusa’s Next.js starter did. When the customer visits the Cart page the starter would trigger an API call from the browser to fetch the customer’s cart data from Medusa and render it. To keep track of the user’s Cart and optimize the storefront experience, the previous version used client-side state and React Context to store Cart IDs, cache requests, and much more.

With [Next.js 14](https://nextjs.org/), you can still make requests from the client; however, new tools like [React Server Components](https://vercel.com/blog/understanding-react-server-components) and Server Actions are now available to simplify the developer experience for caching and state management when building highly dynamic websites. This new paradigm requires you to think differently about how you build your React applications, so there was a bit of a learning curve to migrating the starter to using the new tools. Below are the key differences I encountered and how I have understood React’s new tools.

## **Data fetching and state**

Let’s tackle data fetching and state management first, taking the shopping cart as an example.

The Medusa server already keeps track of the contents of the current shopping cart. By retrieving this data, storing it in the Next cache, and then accessing that cached data from any component that might need it, we eliminate the need to manage the cart state in the client.

By revalidating the cart data whenever we modify it, we make sure the cache always holds an updated version of the cart, accessible throughout the app.

Let’s dig a bit deeper into how this works in Next.js:

### Fetching and caching

Next.js has a caching mechanism built-in that automatically works with the native `fetch` API. This means that every fetch request is automatically cached until revalidated. As a result, you can safely fetch the same data from every component that needs it without worrying about doing 20 duplicate requests. This eliminates the need for keeping a global data state using Context or prop drilling.

At first, re-fetching the same data multiple times in a component tree seemed counterintuitive as you’d normally fetch data in one place, and pass it down via either Context or props. You must also remember to revalidate the relevant parts of the cache *every time* you mutate data on the server. These patterns take some getting used to.

My way of thinking about it is that in the previous model, a `fetch` meant going to the server and getting data back. With Next.js’s caching mechanism, a `fetch` is an abstraction for an *intent* to get some data and Next.js is then in charge of delivering it either from its cache or by going to the server for you. This creates super fast interactions, but it also forces you to be meticulous about revalidation which was not a concern previously.

Once figured out, the caching mechanics are very effective in practice. Fetching new data from the server is swift, and all subsequent requests load almost instantly from the cache. This leads to a responsive front-end performance when navigating through your app.

### Data mutations with Server Actions

Now we know how to fetch and cache data. But how do we handle data mutations, like adding an item to the shopping cart? User interactions often trigger these mutations and require us to use a Client Component to render variant selectors and an "add to cart" button. But we aim to manage API interactions server-side. To accomplish this from a Client Component, we can use *Server Actions*.

Server Actions are **asynchronous functions** executed on the server. They can manage form submissions and data mutations in Client Components. Under the hood they trigger a POST request to the Next.js server. The actions can be used like any other function in your project, making them convenient to work with.

In the new Starter, we use the Medusa JS client through Server Actions to interact with the Medusa server. This replaces many client-side data mutation hooks from the `medusa-react` package used in previous versions.

### Implementing “add to cart” - before and after

Let’s take the “add to cart” action and compare how to implement it in both the old and the new version.

![](/images/snippets-1-large.jpg)

First of all, we no longer have to wrap our root layout in Context Providers to give its children access to data and actions. In the new setup, we can keep the root layout simple and server-rendered.

![](/images/snippets-2-large.jpg)

Instead of defining the `addToCart` function in the `ProductProvider`, we’d now export it from an `actions.ts` file. There’s two significant differences here you should note:

1.  The `“use server”` keyword at top of the file. This tells Next.js to execute this function on the server, even if its called from a client component.

2.  The `revalidateTag` function call on line 15. This ensures that cart cache is revalidated and all components using cart data will fetch the latest data: the cart with the newly added item in it.

![](/images/snippets-3-large.jpg)

Now we can import and use the `addToCart` function like any other function in a client component. Notice the `"use client"` keyword on top of the file. This tells Next.js this should be a client component. The product variant is fetched in its parent Server Component, and passed down as a prop. All data fetching and mutating is handled by the server.

## Server vs Client components

React Server Components allow you to build UIs that can be rendered on the server. Server components have a couple of benefits. Most notably, they have access to server-side data fetching. This can enhance performance by decreasing data fetching time and reducing the number of client requests. It also means you don’t have to expose API keys in the browser or worry about CORS. They can also be pre-rendered or cached on the server. This means the client gets served the rendered HTML and doesn’t need to download, parse and execute the JavaScript needed to render the page.

![](/images/Next.js%20server.jpg)

So when should you use a Server Component? As a rule of thumb, any component can be a Server Component, *unless* it needs client-side interactivity. If you need access to React hooks like `useState` or `useEffect`, or want to attach an `onClick` event handler to a button, you need to use a Client Component.

Client Components can be children of Server Components, meaning you can use a Server Component to fetch data server-side, and pass it down as a prop to the Client Component.

Let’s have a look at the product page to see the component structure:

![](/images/product-page.jpg)

All components marked in red, including the page itself, are Server Components. There are two exceptions: the product actions and the cart button/modal on the top right. These require client-side interactivity and event handlers. Since they are both rendered within Server Components, we can fetch cart and product data on the server and pass it down as a prop.

## Static pre-rendering

Looking at the product page above, we can identify some parts of the page that use static data. The product title, description and images are all available when we build the app, and don’t change. They won’t change based on user behaviour and the general change frequency isn’t high. This means we can pre-render these parts of the page at build time as static HTML. This will improve page loading times.

The cool thing is that we can leave ‘holes’ in the static HTML for the server to stream dynamic data into. The server can quickly deliver the statically generated HTML with fallbacks. This is done by wrapping the components that require dynamic data within `<Suspense>` boundaries and providing a fallback. As the user views the page, the server streams in the dynamic data, replacing the static fallbacks.

## Moving state to the URL

In the process of migrating to Next.js 14, one key shift in approach is the idea of moving state to the URL. This concept involves manipulating the URL to reflect and manage the application's state, providing a global state when using Server Side Rendering. Let's delve into how and why we implemented this strategy.

Medusa offers support for multi-region stores, allowing variation in pricing, inventory, and fulfillment options based on the user's region. The current region should be accessible by multiple components in the tree, on both the server and client sides. To facilitate this, we added a country code to the path, moving the region state to the URL. E.g. <https://next.medusajs.com/gb> or <https://next.medusajs.com/nl>.

There’s a couple of reasons we decided move the country code to the path:

*   It enables static pre-rendering.

*   It makes the country code globally available.

*   It allows search engines to index localized pages. This has a massive SEO benefit if you run a multi-region / multi-language store and want to rank well in all regions.

There’s a reason we didn’t go with URL search parameters to keep track of the region. I’ll explain why later.

### Using search params

Another example of where we moved state to the URL is in the checkout flow. Since it's a one-page checkout, we must monitor the completed checkout steps and determine which parts of the checkout UI should be rendered.

In the previous version, we’d keep track of this checkout state using React Context. Since the high-level checkout components have been upgraded to Server Components and the checkout state needs to be accessible to all child components, we've relocated the state to a `step=` search parameter in the URL.

![](/images/checkout.jpg)

There’s a couple of caveats to moving state to the URL. First of all, accessing search params from Server Components is a hassle. On the server side, they’re only available from within `page.tsx`, where they will be passed as props. If you need the params in any other Server Component, you’ll need to pass it down as a prop from the main page.

From Client Components it’s easy to access the dynamic URL params with the `useParams` and `useSearchParams` React Hooks respectively.

Be aware that using the `searchParams` prop or the `useSearchParams` disables static rendering. As a result, the entire route will be dynamically rendered. If you only need to access the params from a Client Component, consider wrapping that component in `<Suspense>` boundaries. This allows dynamic rendering up to that Suspense boundary, while the rest of the page can still be statically rendered.

To the best of my understanding, this doesn't apply to `params` and `useParams`. That's why I decided to use them for the country code. As a dynamic path parameter it’s still globally accessible, but doesn’t disable static rendering.

## Conclusion

In conclusion, the new patterns for fetching/caching that Next.js 14 introduces require some getting used to. Once you get the hang of it, It’s quite convenient to just be able to fetch the data where you need it, instead of having to set up client-side Context or endless prop drilling. The caching makes your UI feel very snappy and fun to use.

Same goes for working with Server Components and Server Actions. It requires you to plan out the structure of your app and forces you to think about what can be rendered on the server, and what has to be rendered in the client.

In my opinion, this method of work contributes to a cleaner, well-structured codebase. It clearly separates server and client code, logically groups Server Actions together, and the App Router enforces a clear project structure.

However, the approach is opinionated and involves a lot of 'magic' happening behind the scenes, such as with caching and Server Actions. Whether or not you're comfortable with this ultimately depends on personal preference.

**Want to try out the Medusa Next.js Starter?**

Like Medusa, the Next.js Starter is fully open source. Check out the [live demo](https://next.medusajs.com) or get the code on [GitHub](https://github.com/medusajs/nextjs-starter-medusa).


What we've learned from the transition to Next.js 14 with Server Components

Since selling its first mattress in 2016, [Matt Sleeps](https://www.mattsleeps.com/) has become popular among European consumers with its high-quality, adjustable mattresses. In 2023, the Financial Times listed Matt Sleeps as one of [Europe's five fastest-growing ecommerce companies](https://www.ft.com/ft1000-2023), with its 24x revenue growth over three years.

Matt Sleeps' success is a result of the company’s digital-first approach and ability to rethink the full customer experience when buying a new mattress. With initiatives like letting customers lend their mattresses for 120 days and untraditional publicity events like the [Hangover bar](https://www.youtube.com/watch?v=rkSPUV3lRBs) or their [“Bed Cinema”](https://www.youtube.com/watch?v=22gMSPNQ6T8), Matt Sleeps has always taken an innovative approach to their products. With Medusa, the time had come to push the bar for the digital parts of the customer experience.

<quote name="Joep Verbunt" title="Founder and CEO of Matt Sleeps">
I didn't know anyone who enjoyed buying a mattress. The big brands were sleeping in regard to ecommerce. Matt Sleeps was born with the mission to make the process of buying a mattress a fun experience even online.
</quote>

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/matt-sleeps-video-1-cover.png">
<source src="/videos/matt-sleeps-video-1.mp4" type="video/mp4" />
</video>

## A commerce framework that can push the bar

When Matt Sleeps first launched, the company used a custom-built Laravel ecommerce platform to power its online store. However, the system's performance had decayed as more products were added, and hacky workarounds within the setup made it increasingly difficult to customize. This was not sustainable for a brand that constantly wanted to push the bar for its digital commerce experiences. Together with their implementation and performance marketing partner, [Webbers](https://webbers.com/), they sought to find a new commerce framework that would enable them to:

1.  **Build a unique and localized storefront experience:** As a primary showroom for their products, the storefront needed to be tailored to provide a unique experience while seamlessly supporting a multi-market setup.

2.  **Handle pricing complexity and ship new features fast:** To maintain their growth, the team required a framework that made it easy for them to rapidly build and test new features while also being able to handle complex requirements in the product and pricing areas.

3.  **Create a seamless admin experience:** With thousands of orders per month, Matt Sleeps needed an admin dashboard that made it easy for store operators to manage returns, track orders, review sales, handle customer reviews, and more.

While the team evaluated various composable and headless platforms, they ultimately selected Medusa. The modular and customizable architecture made it excellent for rapid feature experimentation and allowed it to support some of Matt Sleeps' more complex needs. Medusa also provides out-of-the-box multi-regional support, making it easy to use across multiple markets.

<quote name="Pepijn van Vlaanderen" title="CTO at Webbers">
Medusa made all the core ecommerce logic readily available and offered a great developer experience when we needed it to add custom logic to handle the more complex parts of the build.
</quote>

## Unique and localized storefront experience

Webbers built a responsive storefront that reflected Matt Sleeps' playful, experience-focused brand identity. They conveyed the brand and product story through videos, interactive content, and playful tools such as their [product configurator](https://www.mattsleeps.com/en/configurator). With the help of the Next.js framework, the team was able to achieve improvements of 30-50% across most of its core web vitals despite the heavy use of dynamic content.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/matt-sleeps-video-2-cover.png">
<source src="/videos/matt-sleeps-video-2.mp4" type="video/mp4" />
</video>

Matt Sleeps sells products in the Netherlands, France, Germany, and Belgium, with plans to enter more markets soon. As a result, the team required a CMS to localize site content and manage media assets without developer assistance. They chose [Builder.io](http://builder.io/) due to its user-friendly visual editing experience. [Builder.io](http://builder.io/) easily connects to Medusa using product IDs to pull pricing and inventory data for product pages.

Using Medusa’s [multi-region support features](https://docs.medusajs.com/recipes/multi-region), Matt Sleeps has been able to set up localized payment options while translating the site content directly within [Builder.io](http://Builder.io). Webbers also created a custom [Admin Widget](https://docs.medusajs.com/admin/widgets) that enabled the Matt Sleeps' team to configure localized storefront URL handles and product names directly in Medusa. These handles and names were used in the storefront, order confirmation emails, invoices, and similar contexts.

![](/images/matt-sleeps-tech-stack.png)

## Pricing complexity and new features

Medusa’s architecture allowed Webbers to build custom solutions for some areas with more complex requirements. One example of this was in the product and pricing area. Matt Sleeps offers various customization options for its mattresses and beds. For example, customers can modify a Boxspring bed's color, size, headboard, footboard, legs, and more. This allows for over 20,000 different possible product combinations. To avoid dealing with that many variants, Webbers customized the pricing configuration. Instead of creating separate variants for each combination, they added product add-ons as [metadata attributes](https://docs.medusajs.com/development/entities/overview#metadata-attribute) in [Medusa’s Product entity](https://docs.medusajs.com/modules/products). When the customer then selected different add-ons for a given bed size, the price adjustments were executed as [Price Overrides](https://docs.medusajs.com/modules/price-lists/backend/override-price-selection-strategy) based on a separate product master sheet that contains the price per add-on for each bed size.

Matt Sleeps also benefitted from Medusa's customizable architecture when implementing new custom features. For instance, the Matt Sleeps team wanted to experiment with bundled discount offerings; e.g., purchasing a mattress and a bed of the same size would result in a discount. For this, Webbers was able to define the bundle logic directly within Medusa by extending the [ProductVariant entity](https://docs.medusajs.com/modules/products#product-variant-overview) to include bundle information. They then extended the `discountService` to take the bundle discounts into account. Having all pricing logic controlled directly within Medusa made it both faster to implement and simpler for Webbers to maintain and evolve.

![](/images/diagram.png)

## Tailored admin dashboard

For daily store operations, Matt Sleeps used Medusa's Admin dashboard. The team again leveraged Medusa's extensibility to create custom admin extensions using [Medusa Widgets](https://docs.medusajs.com/admin/widgets), [UI Routes](https://docs.medusajs.com/admin/routes), and [Medusa's UI components](https://docs.medusajs.com/ui). Some examples include:

*   **Sales analytics** provide the team with a quick overview of essential sales metrics, such as total sales, orders, top-selling products, returning customers, and more. See more in the video below with anonymized data.

*   **The customer review page** is used to manage customers’ product reviews. Store operators can handle reviews and add them to the product pages for each locale shop when appropriate.

*   **Custom return Overview** provides a view of all customer returns related to the company’s 120-days full satisfaction or return guarantee. The dashboard makes it easy to review return statuses, respond to return inquiries, coordinate pick-ups, and more.

*   **Extended order detail pages** provide the team with custom functionality, such as generating order invoices and viewing the status of some order items that are handled by third-party suppliers. For example, Matt Sleeps uses a third-party provider for the fulfillment of some of their bed frames. Through an API connection with the supplier, the store operator can verify whether the product has been delivered to the customer.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/matt-sleeps-video-3-cover.png">
<source src="/videos/matt-sleeps-video-3.mp4" type="video/mp4" />
</video>

For Matt Sleeps, Medusa’s extensibility allowed them to elevate the user experience of their store while building an admin solution tailored to the needs of their store operators. For Webbers, an experienced [Medusa Expert partner](https://medusajs.com/experts/), the case served as another proof point of how powerful a toolbox Medusa provides when building tailored client solutions.

<quote name="Pepijn van Vlaanderen" title="CTO at Webbers">
For Matt Sleeps, chosing a stable tech foundation for future scalability was important. Medusa once again proved to be a solution that provided the flexibility our client needed and the right architecture to make customizations straightforward for us to implement.
</quote>



Matt Sleeps: Elevating customer xp at one one of Europe's fastest growing D2C shops

Matt Sleeps: Elevating customer experiences at one of Europe’s fastest-growing D2C shops

We love to see the continuous community contributions with new additions to our [Medusa Plugin Library](https://medusajs.com/plugins/), new Admin translations, and new Starters and plugins being shared on our [Discord](https://discord.gg/medusajs). Recently, two of our [Medusa Experts](https://medusajs.com/experts/), [Rigby](https://rigby.pl/) and [Agilo](https://agilo.co/), also open-sourced some of the larger plugins they have developed. Check it all out below.

## Medusa Admin translated into +20 languages

The amount of community language contributions has been exceptional since we [announced multi-language support in September](https://medusajs.com/blog/announcing-multi-language-support/). Medusa now supports over 20 languages, including English, French, Portuguese, German, Spanish, Italian, Polish, Japanese, Chinese, and many more. [Check out all the translations](https://docs.medusajs.com/user-guide/tips/languages) or learn how you can [contribute to the translation efforts](https://docs.medusajs.com/contribution/admin-translations).

## Medusa Custom Attributes Plugin

[Viktor Holik](https://github.com/vholik) from the Medusa Expert partner, [Rigby](https://rigby.pl/), recently contributed a new [Custom Attributes Plugin](https://github.com/vholik/medusa-custom-attributes) that allows you to expand the current product attributes to include new ones specific to your use case, such as “furniture type” or “Year of production”. These custom attributes can be in the form of strings, numbers, booleans, or arrays.

The plugin has a UI allowing you to access all your custom attributes from a separate Custom Attributes page in your Medusa Admin. After creating a custom attribute, you can edit it for each product on the Product page using a [widget](https://docs.medusajs.com/admin/widgets). The plugin is actively used in the vintage marketplace, [Patyna](https://medusajs.com/blog/patyna/).

Read more about the plugin in Viktor's blog posts around it, [part 1](https://medium.com/rigby-software-house/adding-custom-attributes-in-medusa-js-ba1af9f312bb) and [part 2](https://medium.com/rigby-software-house/introducing-custom-attributes-in-medusa-js-part-2-ui-8c1f111f8845).

![](/images/cropped.png)

## Medusa WordPress Plugin

[Ante Primorac](https://github.com/anteprimorac) and [Anamarija Papić](https://github.com/anamarijapapic) from another Medusa Expert partner, [Agilo](https://agilo.co/), have built a new plugin named [MedusaWP](https://github.com/Agilo/medusawp). This plugin allows you to use [WordPress](https://wordpress.com/) as a CMS with Medusa. It enables you to import various data from Medusa into WordPress, including products, collections, thumbnails, and more.

The plugin also offers an overview of your data health, identifying any sync errors, partially synced items, and successful synchs. It also includes a country switcher feature for stores with multiple regions, which updates cart regions based on the country code.

At last, the plugin provides a feature-rich set of functions for your WordPress theme. These include [medusa-react](https://docs.medusajs.com/medusa-react/overview) utility functions for calculating and formatting prices and amounts.

You can view the full plugin and its feature set within the [MedusaWP repo](https://github.com/Agilo/medusawp).

![](/images/292096021-a4a7b8f5-5a2a-44ff-a5bf-bdbaa64a2111%20\(1\)%201.png)

## Multi-platform starter templates for Medusa

[Rodrigo Figueroa](https://github.com/bidah) developed a starter kit, [Universal Medusa](https://github.com/bidah/universal-medusa), that lets you create multi-platform storefronts using [Next.js](http://nextjs.org/) and [Expo](https://expo.dev/) with a Medusa backend.

Universal Medusa offers a comprehensive development setup that includes shared Tailwind CSS styles and components adapted for native mobile development using [Nativewind](https://nativewind.dev/). The starter mostly matches Medusa's previous feature set and design from the [Next.js Starter Template](https://medusajs.com/nextjs-commerce/).

Check out the [project’s website](https://universal-medusa-docs.vercel.app) to get started. Or check out Rodrigo’s latest [Mobile Medusa](https://github.com/bidah/mobile-medusa) starter for a React Native mobile starter.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; height: 700px; width: auto; margin-left: auto; margin-right: auto;" poster="/images/community-multi-platform-cover.png">
<source src="/videos/community-multi-platform.mp4" type="video/mp4" />
</video>

## Medusa Admin mobile (beta)

[Ragheb](https://github.com/mllrr96) is developing [Medusa Admin Mobile](https://github.com/mllrr96/Medusa-Admin-Flutter), a mobile-friendly Medusa Admin app for iOS and Android. This app is built using [Flutter](https://flutter.dev/) and comes in a [pre-compiled APK file](https://github.com/mllrr96/Medusa-Admin-Flutter/releases) for Android users. Although the app is in beta, it allows you to view and modify various aspects of your store, including settings, orders, products, customer information, discounts, gift cards, price lists, and more.

The latest version features a new look with material design and several themes. To try the application, visit the [Git repository](https://github.com/mllrr96/Medusa-Admin-Flutter), which provides all the steps to get started. Ragheb also encourages feedback either in the [project thread on Discord](https://discord.com/channels/876835651130097704/1149712066119217453) or in the [GitHub repo](https://github.com/mllrr96/Medusa-Admin-Flutter).

![](/images/Untitled%20\(12\).png)

## Ultimate Medusa Plugin (beta)

[Kichou Nadir](https://github.com/raideno) is developing the [Ultimate Plugin](https://github.com/raideno/medusa-plugin-ultimate). This plugin provides a user interface for interacting with new entities added to your Medusa store. It allows you to create, edit, view, and delete documents associated with those entities directly within the Medusa Admin. For example, if you add a blog entity (database table, service, route, loader, etc.), the plugin will allow you to manage related documents for each blog post directly from the admin dashboard.

Read more about the plugin in Kichou's [documentation](https://medusa-plugin-ultimate.raideno.xyz/). Please note that the plugin is still in beta mode.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/community-ultimate-medusa-plugin-cover.png">
<source src="/videos/community-ultimate-medusa-plugin.mp4" type="video/mp4" />
</video>

## Let us know what you are building

We would love to hear about the cool projects you have created with Medusa. Whether it’s plugins, widgets, storefront starters, your own store built with Medusa, or similar.

You can share all your cool projects in the *#Showcase* channel on our [Discord](https://discord.com/invite/medusajs) where we usually collect the latest community highlights. You can also learn how to publish your plugins on our Plugin Library using this guide in our [documentation](https://docs.medusajs.com/development/plugins/publish).


Community Highlights Jan’24

[Patyna](https://patyna.pl/) is Poland's largest vintage marketplace, selling more than 30,000 unique furniture, lighting, decorations, accessories, and more on their platform. The company started in 2013 and has since grown to serve a diverse market of private and B2B customers, such as architects, retailers, and designers. Today, more than 2,000 vendors use the platform to market their vintage furniture, from established wholesalers to local sellers.

Supported by their implementation partner, [Rigby](https://rigby.pl/), Patyna migrated from WooCommerce to Medusa. With Medusa, Patyna has been able to experiment and build new features faster while spending less time on maintenance and debugging. Along with the migration, Patyna built an admin setup with multiple user types and accesses, custom category control, a mechanism for order splitting, and much more.

<callout icon="lightBulbSolid" button-label="Get started" 
button-url="https://docs.medusajs.com/recipes/marketplace">
**Marketplace Recipe**
Set up your own marketplace with Medusa. </callout>

## 34% traffic uplift and 30% shorter time to market

Patyna's team originally built their marketplace using WooCommerce. However, they constantly faced two major challenges: site performance and the release speed of new features. The performance issues stemmed from the platform being bloated with plugins and hacky workarounds, adversely impacting page load time and causing crashes during traffic peaks. Furthermore, vendors experienced considerable load time when making updates to their stores.

The slow development velocity resulted from the team spending too much time on platform maintenance and debugging. The tightly intertwined logic in WooCommerce meant that overriding parts of the system and its plugins could cause problems elsewhere, making root causes hard to identify and debugging a laborious task.

Medusa addressed both of these challenges. Its composable nature allowed Rigby to easily use [Next.js](https://nextjs.org/) to build a custom and performant frontend, resulting in a 34% traffic increase two months after going live. By optimizing CI/CD pipelines, minimizing debugging and maintenance time, and enabling smoother implementation of custom functionality, Medusa reduced the time to market for new features by 30%. Especially the ability to rapidly build custom logic was something Rigby found unique about the Medusa framework.

<quote name="Jakub Zbąski" title="Co-founder and CEO at Rigby">
We looked into other solutions, but I do not think it would have been possible, even at the slightest part, with any of the existing open-source or SaaS solutions to get the same result.
</quote>

## Custom functionalities and multi-access

When setting up the marketplace, Rigby aimed for simplicity in their stack using only a few external services. They used [Strapi](https://strapi.io/) to manage content data such as homepage images, text, and About pages. [Sendgrid](https://sendgrid.com) and [Mailchimp](https://mailchimp.com/) were used for marketing, [Sentry](https://sentry.io/welcome/) for application monitoring, and [OpenReplay](https://openreplay.com/) for user session recordings.![patyna-tech-stack](/images/tech%20stack.png)

The marketplace encompasses three user types: customers, vendors, and Patyna Admin. For vendors and Patyna Admin, Rigby created separate admin dashboards with unique access levels and control features.

### Patyna Admin: Controlling the marketplace

Patyna’s admin has a custom dashboard from where they can control the entire marketplace. They can view all products, orders, vendors, and customers across the platform. Additionally, it allowed the team to:

*   **Create sales reports:** This allows Patyna to generate PDF reports with sales and margin overviews across all products and vendors.

*   **Manage product attributes:** This enables Patyna to define both standard product attributes (e.g., date of production) and custom attributes per product category (e.g., "Types of legs" for sofas). These attributes are then filterable for customers on the marketplace and must be filled out by vendors when creating new products within a category.

*   **Control discounts and gift cards:** This allows them to create special customer discount codes or gift cards that can be used across all vendors.

### Vendors: Controlling their store operations

Vendors are limited to controlling and accessing orders, customers, and products related to their own stores. Additionally, Rigby built custom functionality for:

*   **Self-pickup delivery:** This feature allows vendors to offer pickup options for their products, and they can then manually mark orders as collected in their admin dashboard upon customer pick-up.

*   **Custom order splitting:** When customers purchase products from multiple vendors, the order is split under the hood, ensuring each vendor manages only their part while the customer sees it all as a single order.

*   **'Classics' products:** Patyna has a unique section in their marketplace called 'Classics' for select iconic products. Vendors can propose products for this section directly in their admin dashboard, and the Patyna Admin then gets a chance to review the submissions afterward and approve them within their dashboard.

Being able to ship custom features faster has paid off. Patyna quickly saw a resurgence in vendor activity on the platform, and some vendors even expressed their satisfaction with the platform's improved usability, noting that they were now inclined to add more products to the new platform because of its improved usability and performance.

![patyna-admin-overview](/images/admin-overview.png)

## Cutting maintenance and debugging time in half

For Rigby, the case demonstrated the profound impact the Medusa framework could have on their development velocity. Patyna's team estimated that Medusa roughly halved the time spent on ongoing maintenance and debugging. The framework made it easier for the team to keep logs for debugging purposes while offering an overall better developer experience when implementing custom logic and functionality.

Despite using various composable ecommerce frameworks in the past, Rigby's learnings from Patyna convinced them to commit to Medusa for the future. Today, Rigby is included in [Medusa's Expert list](https://medusajs.com/experts/) and has chosen Medusa as their framework for multiple other ecommerce cases. For them, the decisive factors for doubling down on Medusa were the developer experience and scalability.

<quote name="Jakub Zbąski" title="Co-founder and CEO at Rigby">
The whole developer experience was really awesome. From managing vast product listings to handling intricate vendor details, Medusa provided a robust and scalable solution.
</quote>



Patyna: Boosting performance for Poland's biggest vintage marketplace

In 2023, we introduced many new features, architectural changes, and developer experience enhancements in Medusa. The latest of which is highlighted in our [Recap 3](https://medusajs.com/recap/) page.

We recognized the importance of making sure the documentation aligns with the core product at the same speed. We knew we had to enforce a docs-as-code approach further to do so. A docs-as-code approach encourages adopting processes, testing practices, and implementations with documentation typically used with code.

As a result, we've created a custom documentation toolkit that we use internally, ranging from low-level documentation generation tools to custom-built documentation websites.

In this article, I'll share with you some of the custom documentation tools we built in 2023 at Medusa and some of the plans we have to continue improving our documentation.

## Why Build Custom Tools

Previously, our documentation was built using tools like Docusaurus and Redocly. Our team manually wrote the content within the documentation as Markdown files within the Docusaurus codebase.

While this setup worked initially, it was only a short time until Medusa outgrew it. The quick pace of releases made information in the documentation stale; the large number of API routes slowed down the API Reference; introducing new features like [Modules](https://docs.medusajs.com/modules/overview) and [Workflows](https://medusajs.com/blog/announcing-medusa-workflows-sdk/) raised the need for understandable and easy-to-use references.

Our documentation tools weren't enough anymore. So, we started building a documentation toolkit to resolve our problems and improve the developer experience in our documentation.

## Custom REST API Reference

Previously, our REST API Reference website was built using Redocly as part of our main documentation website, built with Docusaurus. While Redocly is a great tool for building an API reference website, we had performance issues due to our wide-reaching commerce API Routes and information within each of those routes.

We explored different existing options, but none satisfied our use case. As a result, we decided to build a [custom API Reference website](https://docs.medusajs.com/api/store) from scratch.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/api-reference-cover.png">
<source src="/videos/api-reference.mp4" type="video/mp4" />
</video>

The website is built with Next.js 14, and documentation for Medusa’s API Routes is loaded on demand, improving the website's overall performance. Our designer also created a fresh and clean design for the new API reference.

You can check out the source code [here](https://github.com/medusajs/medusa/tree/develop/www/apps/api-reference).

## References Generator

After introducing the [Product](https://docs.medusajs.com/experimental/product/overview) and [Pricing](https://docs.medusajs.com/experimental/pricing/overview) Modules, we wanted to provide a clear API reference in our documentation for the main interface of each module. We also wanted to improve our existing references, such as the JS Client reference.

To do that, we used [Typedoc](https://typedoc.org/), a tool that generates documentation from comments in TypeScript source code, with existing and custom plugins relevant to our use case. Some of the plugins we built were:

*   A plugin that converts OpenApi Specification (OAS) schemas to their equivalent TSDoc comments. This is especially useful for our JS Client reference as we can reuse the same request and response type details used for the REST API Reference.

*   A plugin that uses ESLint to lint code examples in the TSDoc comments.

*   A plugin that allows injecting custom frontmatter into Markdown files.

![](/images/references-generation.jpg)

This also allowed us to bring the documentation close to the code, which:

*   Mitigates information staleness: as members of our engineering team make changes to the code, they can directly reflect the changes on the documentation in the code's doc-block.

*   Improves code readability and maintainability.

*   Provides better auto-complete descriptions during development.

This encouraged us to move more of our documentation pages to live closer to the code, which is still ongoing.

## Coming Soon: Workflows Diagram Generator

In [Recap 3](https://medusajs.com/recap/), we introduced Workflows. A workflow is a series of steps that complete a task and can be executed from anywhere. Aside from providing the necessary documentation for Workflows, we also wanted to visualize workflows in the documentation for a better developer experience.

So, we built a tool that creates [Mermaid](https://mermaid.js.org/) diagrams of workflows used in the Medusa backend, which can be visualized in the documentation.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/workflows-diagram-generator-cover.png">
<source src="/videos/workflows-diagram-generator.mp4" type="video/mp4" />
</video>

While we still need to incorporate it in our documentation, we've built the necessary foundation of this tool to make it possible and look forward to adding it to our documentation soon.

You can check out the source code [here](https://github.com/medusajs/medusa/tree/develop/docs-util/packages/workflows-diagrams-generator).

## UI Props Generator

In 2023, we introduce [Medusa UI](https://docs.medusajs.com/ui), a package of UI components that implement the Medusa design system and allow developers to build customizations in the admin with a consistent design.

In the [Medusa UI documentation](https://docs.medusajs.com/ui), we show the props that each component accepts. To ensure that these props remain up-to-date, we created a tool that generates JSON spec files for each component from the source code.

These spec files are then loaded in the Medusa UI documentation website, built on Next.js 14, to display the component's details and props.

![](/images/Screenshot%202023-12-13%20at%207.50.18%E2%80%AFPM.png)

This tool is built on top of [react-docgen](https://react-docgen.dev/), which extracts details of React components and generates JSON documentation, and Typedoc. As we faced some limitations with `react-docgen`, we customized its handlers and resolvers to ensure that all props and components were recognized and used Typedoc to fill in any missing details.

You can find the source code of the tool [here](https://github.com/medusajs/medusa/tree/develop/docs-util/packages/react-docs-generator).

## Generate Documentation on Release

Building the tools is one thing, but another important aspect is ensuring the documentation is updated whenever there's a new Medusa release.

So, we've added GitHub actions that run whenever a new release is published, making documentation updates part of the release pipeline.

![](/images/release-process.jpg)

This GitHub action checks for any updates in the REST APIs, UI props, and general references and opens a pull request with the updates, eliminating the need to make the updates manually.

## Notable Documentation Improvements

Aside from the custom documentation toolkit, we've continued improving our documentation to provide a better developer experience. The improvements include:

Added a Recipes section in our documentation, with guided learning paths that you can start and finish at your own pace.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/learning-path-cover.png">
<source src="/videos/learning-path.mp4" type="video/mp4" />
</video>

An enhanced search experience with intuitive navigation.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/search-cover.png">
<source src="/videos/search.mp4" type="video/mp4" />
</video>

An AI Assistant to provide help during your learning journey.

<video controls preload="none" style="object-fit: cover; max-height: unset; max-width: 100%; margin-left: auto; margin-right: auto;" poster="/images/ai-assistant-cover.png">
<source src="/videos/ai-assistant.mp4" type="video/mp4" />
</video>

## Future of Docs at Medusa

There are still many more improvements to be made both for our documentation and its underlying tooling and processes. Also, since Medusa’s features now make it suitable for orchestration tooling, developers need to understand Medusa as a framework, which requires building a learning path that teaches Medusa’s concepts from end to end.

While it's difficult to list all of the documentation plans, some of the ideas we have for the near future include:

*   Improved documentation structure with better learning paths and guidance.

*   Interactive API reference and UI documentation.

*   Better feedback collection from users to keep improving our documentation and core product.

If you have any ideas for improvements and new features or find bugs in our documentation, please share them with us on [GitHub](https://github.com/medusajs/medusa), [Discord](https://discord.gg/F87eGuwkTp), or our social channels.



Our Custom Tools for Great Documentation

We care deeply about developer experience across all our products. Our primitives and tooling allow developers to effortlessly build digital commerce applications at record speed.

Today, we are excited to announce a massive update to our Subscriber API that significantly improves the developer experience of a core concept in Medusa’s customization toolbox.

## Subscribers

Services in Medusa emit events whenever actions like creating and updating records occur. Subscribers in Medusa provide a way for developers to run asynchronous logic in response to these events. This could include syncing a product to an external service when it is updated in Medusa or applying a special discount when a set of specific products is added to a cart.

With our updated API, you can create subscribers using a pattern similar to how you build API Routes.

<codeblock language="ts">
```
// src/subscribers/order-placed.ts
export default async function ({ data, container }) {
    const { id } = data

    const slackService = container.resolve("slackService")
    const orderService = container.resolve("orderService")

    const order = await orderService.retrieve(id)

    await slackService.sendNotis({ data: order })
}

export const config: SubscriberConfig = {
    event: OrderService.Events.PLACED,
}
```
</codeblock>

Example of a Subscriber

The example above illustrates a few key points of the updated Subscriber API:

*   Exports from files in `/subscribers` control the behavior of your event handlers. The default export is a function with the logic to run, and the `config` export specifies the event that logic should be run in response to

*   The handler accepts an argument of type `SubscriberArgs`. This can be de-structured to access the event data and the Medusa container.

In the example above, we register a handler that is run every time the product updated event is triggered.

The new approach to registering subscribers also comes with the benefit of making it easier than ever to set up a handler for multiple events. The `event` field in the config accepts either a single event or a list of events. Continuing with the above example, it would be possible to update the handler to update the external system when a product is created, updated, and deleted.

```ts
// src/subscribers/product-sync.ts
import { syncProductsWorkflow } from "../workflows"

export default async function ({ data, eventName, container }) {
  await syncProductsWorkflow.run({ input: data })
}

export const config: SubscriberConfig = {
  event: [
		ProductService.Events.CREATED,
		ProductService.Events.UPDATED,
		ProductService.Events.DELETED
	]
}
```

By updating the `event` field and adding a few additional lines of code, the handler can now process all relevant events. This keeps the external system synchronized with Medusa.

## What is next?

We are excited to hear your thoughts about our new Subscriber API. If you have any feedback or experience issues, don’t hesitate to post on our [GitHub Issues board ](https://github.com/medusajs/medusa/issues)or [GitHub Discussions](https://github.com/medusajs/medusa/discussions). To check other of our recent releases, check out our [Medusa Recap page](/recap/).

You can also track our progress on [X](https://twitter.com/medusajs) and in our [changelog](https://medusajs.com/changelog/).


Announcing Improved Subscriber API

Digital commerce happens across multiple systems, whether ERPs, CMSs, marketing tools, custom services, or other tools. A key challenge is to ensure these systems work together to complete the tasks that drive your business forward. We are, therefore, incredibly excited to announce the beta release of Medusa Workflows, a new, powerful primitive in the Medusa toolbox to help build custom business flows involving multiple systems.

Medusa’s Workflows SDK enables developers to write critical business flows with a simple DX and a strong foundation. Workflows have built-in retry and rollback mechanisms, which make them resilient to intermittent failures and a great place to define your commerce stack’s integrations and customizations.

Medusa Workflows are not dependent on Medusa’s commerce modules. You can start using them to integrate your commerce stack regardless of what ecommerce platform you are on, giving you access to Medusa’s powerful customization tools without needing to migrate your commerce platform.

## Build a Workflow

Building Workflows is like writing JavaScript functions, but unlike regular functions, the Workflows SDK creates an internal representation of your Workflow to keep track of its progress, retry failing steps, and roll back operations if necessary.

### Define a Workflow Step

To create a Workflow, you first define a Workflow Step using the Workflows SDK’s `createStep` function.

```ts
import { createStep, StepResponse } from "@medusajs/workflows-sdk"

const reserveInventory = createStep("reserve-inventory", async (cart, context) => {
    const inventoryService = context.container.resolve("inventoryService");
    await inventoryService.reserveInventory(cart.items);
    return new StepResponse({ success: true });
  }
);
```

The above step resolves an Inventory Service from the dependency injection container and reserves inventory for items in a Cart. Note that the step takes a Cart as input and responds with a StepResponse. The StepResponse can be used in subsequent steps.

### Create a Workflow

Once your step is created, you can use it within a Workflow. To construct a Workflow you use the `createWorkflow` helper from the Workflows SDK.

```ts
import { createStep, StepResponse, createWorkflow } from "@medusajs/workflows-sdk"

const reserveInventory = createStep("reserve-inventory", async (cart, context) => {
  const inventoryService = context.container.resolve("inventoryService");
  await inventoryService.reserveInventory(cart.items);
  return new StepResponse({ success: true });
});

const acceptQuoteWorkflow = createWorkflow("accept-quote", function (input) {
  const cart = retrieveCart(input.cartQuoteId);
  reserveInventory(cart);
  authorizePayment(cart);
  createOrder(cart);
});
```

The above Workflow accepts a quote shared with a customer, and the step we created to reserve inventory is used as part of the Workflow. In the Workflow, we have used our `reserveInventory` Workflow Step.

The function passed to `createWorkflow` is used to generate a representation of the Workflow logic and map the data dependencies between steps. For example, the Workflow SDK knows that `reserveInventory` step needs the output of `retrieveCart` as its input. This enables Medusa to automatically retry a step if it fails and only progress when possible and allowed. If a step fails more than a configurable number of times, Medusa will automatically roll back previous steps.

### Defining compensating actions

Let’s define the compensation for our `reserveInventory` step. We do this by specifying what data our step will need to roll back in the StepResponse and a compensation function to execute when rolling back.

```ts
import { createStep, StepResponse } from "@medusajs/workflows-sdk"

const reserveInventory = createStep("reserve-inventory", async (cart, context) => {
    const inventoryService = context.container.resolve("inventoryService");
    await inventoryService.reserveInventory(cart.items);
    return new StepResponse({ success: true }, cart.items);
  },
  async (items, context) => {
    const inventoryService = context.container.resolve("inventoryService");
    await inventoryService.releaseInventory(items);
  }
);
```

Note that the StepResponse now specifies the `cart.items` as rollback data. This is then used in the compensation function to release the inventory.

### Triggering a Workflow

You can execute a Workflow from different places within Medusa. For example, you may use API Routes if you want the workflow to execute in response to an API request or a webhook. Subscribers if you want to execute a workflow when an event is triggered. Or Scheduled Jobs if you want your workflow to execute regularly.

Here’s an example of executing a Workflow in an API Route. You can learn about more ways of triggering Workflows in our docs.

```ts
// src/api/quotes/accept/route.ts

import { acceptQuoteWorkflow } from "@/workflows"

export async function POST(req, res) {
  const workflow = acceptQuoteWorkflow(req.scope)

  await workflow.run({
    cartQuoteId: req.cart_id
  })

  res.json({ accepted: true })
}
```

## What can you use Workflows for?

Medusa Workflows are especially good for orchestrating multiple tools to achieve a task. Integrating systems in your stack using Workflows, for example, ensures that data is kept consistent and that unexpected errors are handled gracefully. To build an integration with Workflows, you would create a custom Medusa service connecting to your 3rd party system. The custom service can then be resolved in your steps to execute actions.

The more systems you integrate with Medusa, the more Workflows you can create to automate your operations and push your customer experience forward. Consider the example of integrating purchase orders from your ERP system with inbounds in your WMS system. With a Medusa connection to your ERP and WMS, you can easily map the purchase order flow and other ERP to WMS flows. Additionally, because you have other connections - like your product information - available, you can leverage those in your Workflows. For example, you can quickly configure your purchase order Workflow to record the expected restock date of your products to display to customers.

![](/images/Untitled%20\(8\)-65817d5b.png)

### Long-running workflows (coming soon)

With the initial beta release, Workflows can run exclusively in-band. We will soon add support for long-running Workflows that include asynchronous operations or human-in-the-loop steps. This opens further use cases for Workflows. For example, you can build a Workflow to manage the preparation of new products for sale. The Workflow starts when a product is inbounded at your warehouse. Then, tasks can kick off for taking pack shots, writing titles and descriptions, translating copy, and merchandizing the product. As each task is completed, the Workflow can proceed. All tasks would be mapped as Workflow Steps and could be completed in systems across your stack. If a task fails to complete or a configurable timeout is reached, rollback logic can help keep your data consistent, or notify responsible parties.

![](/images/long-running%20\(1\).png)

## Core Workflows

Workflows are a key part of our efforts toward shipping Medusa 2.0. With Medusa 2.0, we are decoupling most of Medusa’s internal services and bringing them to standalone packages available on npm. This means you can use Medusa’s services, like Products, Pricing, Carts, etc., independently from the rest of Medusa. We will continue to offer Medusa’s powerful and customizable commerce API in a way that’s easy to install with `npx create-medusa-app`. For each default API endpoint, there will be an available core Workflow to do things like creating products, adding to cart, applying discounts, and much, much more. The core Workflows will orchestrate Medusa (or custom) modules and be extensible. This does two things:

1.  It makes Medusa pluggable - you can use any provider to handle Products, Carts, Discounts, etc. The Workflow will call the provider when it needs to.

2.  You will get a new and easy way to extend business logic by injecting custom code into Workflows. There is no need to modify core services or override default endpoints; the Workflow will ensure your custom logic is called when required.

Core Workflows are introduced incrementally behind the `medusa_v2` feature flag, and more and more Workflows become available as we ship new Commerce Modules.

## What’s next?

The Workflows SDK joins Custom Entities, Services, API Routes, Subscribers, and Cron Jobs in the Medusa toolbox. With Workflows, Medusa provides a primitive for building custom business flows spanning multiple systems. It has built-in failure handling and rollback logic to ensure your critical Workflows run smoothly and your data is kept consistent. You can start using the Workflows SDK without migrating to Medusa’s commerce modules, making it an excellent tool for integrating your digital commerce stack and building customizations for customer experiences and internal operations.

Visit [our docs](https://docs.medusajs.com/development/workflows) to get started with Workflows. And follow us on [X](https://twitter.com/medusajs) to stay tuned for updates on Long Running Workflows and information about our Commerce Module releases as we prepare for [Medusa 2.0](/blog/toward-medusa-2/).


Announcing the Medusa Workflows SDK

We are excited to announce Medusa’s Pricing Module - a standalone pricing service that enables granular pricing configurations. The Pricing Module ships as an npm package that can be installed in any Node project requiring advanced pricing logic and is integrated into Medusa experimentally behind the `medusa_v2` feature flag as part of our efforts to [release Medusa 2.0](https://medusajs.com/blog/toward-medusa-2/).

In Medusa, the Pricing Module is used to set prices for Product Variants conditional on currencies, regions, customer groups, sales channels, and more. You can read more about the Pricing Module functionality [here](https://medusajs.com/pricing-module/). Now, the Pricing Module’s logic works entirely independently and can be used to configure prices for anything specific to your needs.

The Pricing Module has two key functionalities:

1.  Creating a set of prices for a resource with pricing rules governing when each is applicable.

2.  Choosing the correct price to use given a context.

## Using the Pricing Module

Imagine you want to differentiate the prices of tickets to a tech conference based on the customer’s location. You want to offer cheaper tickets to local companies. With the Pricing Module you first configure your pricing rules:

```ts
const myTicketPriceSet = await pricingModuleService.create({
  rules: [{ rule_attribute: "city" }],
  prices: [
    { amount: 1000, currency_code: "usd", rules: {} },
    { amount: 500, currency_code: "usd", rules: { city: "New York" } },
  ]
})
```

The above code returns a PriceSet to associate with your ticket.

The Pricing Module provides a `calculatePrices` function to get the correct price to charge a customer. Before calling the function you will collect the city your customer is in; for example, based on the IP address, and pass it as context `calculatePrices`.

```ts
const [priceToCharge] = await pricingModuleSerivce.calculatePrice(
	{ id: [priceSet.id] },
	{ context: { currency_code: "usd", city: "New York" } }
)

priceToCharge // { calculated_price: 500, currency_code: "usd" }
```

You can configure as many rules as you need, and the Pricing Module will always provide the correct price to your customer, considering things like overlapping applicability and rule priorities.

## Serverless support

The Pricing Module is ready for serverless environments, making it possible to run price calculations from tools like Lambda, Vercel, or Netlify Functions. To use the Pricing Module in a serverless function, initialize the Pricing Module with the initialize function.

```ts
// my-next-app/app/api/price/route.ts

import { initialize } from "@medusajs/pricing"
import { headers } from 'next/headers'

export async function GET(req, res) {
  const headers = headers()
  const ipCity = headers.get("x-vercel-ip-city")

  const pricingModule = await initialize({ /* db credentials here */ })
  const [price] = await pricingModule.calculatePrices(
		{ id: [priceId] }, 
		{ context: { currency_code: "usd", city: ipCity } }
	)

	res.json({ price: price.calculated_amount })
}
```

With serverless support you can offer your customers fast and highly personalized experiences.

## What’s next?

At Medusa, we build tools for developers to create custom digital commerce applications. The Pricing Module is another step toward preparing Medusa for version 2.0. [Read more about what’s to come here.](https://medusajs.com/blog/toward-medusa-2/)

Try the Pricing Module today by installing `@medusajs/pricing` from npm. For more details on how the Pricing Module works - including details about the Pricing Module’s Price List feature - visit our [docs](https://docs.medusajs.com/modules/price-lists). We are excited to hear your feedback.


Announcing Pricing Module

We are excited to announce a new Scheduled Jobs API that significantly improves the developer experience of a core concept in Medusa’s extensibility toolbox.

## Scheduled Jobs

Scheduled Jobs in Medusa is a feature that lets developers schedule tasks or cron jobs to automate repetitive tasks. For example, you can push daily updates to an external ERP system or generate weekly sales reports.

With the new Scheduled Jobs API, setting up recurring tasks can be achieved with only a few lines of code with a syntax that is familiar to any JavaScript developer.

```
// src/jobs/daily-erp-update.ts
import { ProductService, ScheduledJobsConfig, ScheduledJobsArgs } from "@medusajs/medusa"
import ErpService from "../services/erp"

export default async function ({ container }: ScheduledJobsArgs) {
	const productService: ProductService = container.resolve("productService")
	// Service for interacting with external ERP system
	const erpService: ErpService = container.resolve("erpService")
	
	const products = await productService.listAndCount()

	await erpService.update(products)
}

export const config: ScheduledJobsConfig = {
  name: "daily-erp-update",
	schedule: "0 0 * * *" // At 00:00 every night
}
```

The above example illustrates a few key points of how to use the new Scheduled Jobs API:

*   Exports from files in `/jobs` control the behavior of the action performed in your task. The default export is a function with the logic to run, and the config specifies the name and schedule of the task.

*   The handler is a function that gets invoked each time the job runs. In the given example, it lists products in Medusa and forwards them to the ERP system.

*   The config assigns a name to the job and sets the schedule for the job. In the provided example, the schedule is set to repeat the job every night at 00:00.

You can read more about the new API [in our documentation](https://docs.medusajs.com/development/scheduled-jobs/overview).

We are excited to hear your thoughts about our new Scheduled Jobs API. If you have any feedback or experience issues, don’t hesitate to post on our [GitHub Issues](https://github.com/medusajs/medusa/issues) board or [GitHub Discussions](https://github.com/medusajs/medusa/discussions).

Track our progress on [X](https://twitter.com/medusajs) and in our [changelog](https://medusajs.com/changelog/).


Announcing Scheduled Jobs API 

Medusa Next.js Starter Redesign Announcement thumbnail

The Medusa [Next.js Starter Template](https://medusajs.com/nextjs-commerce/) has been a popular starting point for Next.js developers working with Medusa. We thought it deserved some love, so the Starter just got a big update with a complete design overhaul, Medusa UI components, Next.js 14, and better product search.

The goal of the Starter is to provide a foundation for developers to build on. It consists of a fully functional ecommerce frontend, already connected to a Medusa backend. We aimed for a design that is fresh but neutral so you can easily customize it to fit your brand.

## Medusa UI Support

We redesigned the Starter to work with [Medusa UI](https://docs.medusajs.com/ui) components and icons. This results in a fresh, recognizable design language and components that allow for easy customization.

Medusa UI is a React implementation of the Medusa design system. The collection includes components, hooks, utility functions, icons, and [Tailwind CSS](https://tailwindcss.com/) classes. It's designed for building a consistent user interface across Medusa Admin and other Medusa applications.

## Ready for Medusa 2.0

While we [work toward Medusa 2.0](https://medusajs.com/blog/toward-medusa-2/), you can already try out some of our cutting-edge serverless modules with the Next.js Starter. The Starter has support for both the [Product](https://docs.medusajs.com/modules/products/serverless-module) and the Pricing module, as well as Remote Query to build your own serverless product endpoints. If you’re feeling adventurous, you can enable these experimental features by enabling the `MEDUSA_FF_MEDUSA_V2` feature flag in both the Starter and the server.

## New design showcase

### Home

The homepage has been cleaned up and now shows featured product collections.

![](/images/Screenshot%202023-11-23%20at%2009.43.56-12d8a5f8.jpg)

### Product detail page

The product detail page has a new layout and now uses Medusa UI components.

![](/images/Screenshot%202023-11-23%20at%2009.43.45.jpg)

### Product overview page

The product overview page has been redesigned and now features sorting out of the box.

![](/images/Screenshot%202023-11-23%20at%2009.45.30.jpg)

### Product search

The Starter already supported Algolia and MeiliSearch out of the box, but now has a revamped instant search UI and a server-rendered search results page.

![](/images/Screenshot%202023-11-23%20at%2009.46.41.jpg)

### Cart

The new cart design is built almost exclusively from Medusa UI components.

![](/images/Screenshot%202023-11-23%20at%2009.47.51.jpg)

### Checkout

The redesigned checkout process provides a streamlined experience, making it easier than ever for customers to finalize their purchases.

![](/images/Screenshot%202023-11-23%20at%2009.50.39.jpg)

### Get started with Next.js and Medusa

See the full new design in action in our [updated hosted demo](https://next.medusajs.com/).

Want to build with the Starter yourself? To get started, [clone the Medusa Next.js Starter Template from GitHub](https://github.com/medusajs/nextjs-starter-medusa).


Announcing Next.js Starter Redesign with Medusa UI support

Developers

Solutions

Company

Main Menu

Learn More

This plugin does not have a README.

If you want to learn how to use this plugin, we recommend one of the following steps:

1. Join our [Discord community](https://discord.gg/medusajs) and ask for help on how to use this plugin.
2. Reach out to the plugin's author to learn how to use it.

Careers

Change how commerce is built

Software Engineer, Core