Composable design throughout the stack at Salling Group

By Janus Boye

As Frontend Manager at Danish retailer Salling Group, Martin Hobert implemented shared modules that work in a composable fashion.

Having multiple projects with similar specs often leads to duplicate implementations or code. Similarly, having different vendors tends to add complexity, but aligning all of this can be challenging.

At Denmark’s largest retailer Salling Group, Frontend Manager Martin Hobert and his team solved this by implementing shared modules that work in a composable fashion.

In a recent member call, Martin shared a deep dive into the approach and the years of work that went into creating the solution that they use today. 

The world of digital experiences is changing. As businesses look from legacy suites to modern headless, composable architectures, they need to navigate a rapidly growing ecosystem of architectures and vendors. We’ve written quite a bit about composable design (see a few recommended links towards the end), but it’s always interesting to hear more about an actual customer implementation.

Below you’ll find my notes from the call and towards the end you can also download the slides and even enjoy the entire recording. Martin started by setting the stage for his frontend team.

The Frontend Team: Divided but one

Martin’s team is a part of the sizable digital team in Salling Group, which is currently around 120 employees. The Frontend Team is divided as he said, and they work on many projects. Each has the freedom to choose their own technologies. Still, they are one team, as they work and learn together in the three sub teams:

  • Nonfood, which includes supermarket company Føtex, toy company BR and hypermarket chain Bilka

  • Food, which includes BilkaToGo - an online click-and-collect solution for convenient grocery shopping

  • Home delivery, which at the moment is Føtex Home Delivery in Greater Copenhagen

Going one step deeper, he shared how each has its own tech stack. Here’s how they work at the moment:

  • Nonfood: Vue.js, Nuxt.js and Netlify

  • Food: Vue.js, Nuxt.js and Netlify

  • Home delivery: React, Next.js and Netlify

The team works on packages that they can share across teams and they also host biweekly knowledge sharing sessions. This is how things stand today, but to understand how Salling Group became a digital frontrunner, Martin took us back to how it used to be.

How it used to be: Monolith solutions

Sharing a grim photo of something that looked a bit from a horror movie, Martin outlined the problems they were facing before they went down the route of composability.

How Martin illustrated the situation before they went composable: The digital team faced several problems before they went composable. Low developer productivity, downtime and reinventing the wheel from project to project

Specifically, Martin focused on these three key problems that they were facing when he joined in 2020:

  • Frontenders needed the whole application installed, which meant that it took extra time to onboard new colleagues

  • They had downtime while deploying, which further reduced developer productivity

  • Duplicate implementations, which meant that they were wasting time on implementing the same features from scratch in each project every time.

A landscape with monolithic systems that lacked the agility and flexibility that modern businesses require.

Going headless as a part of the solution

To move away from this, they decided to go headless and work towards loosely coupled services. Still, you don’t just go headless and it isn’t without challenges.

Martin shared how they addressed some of the key headless challenges, including enforcing the usage of TypeScript in the entire team. TypeScript extends JavaScript and improves the developer experience. It enables developers to add type safety to their projects. Moreover, TypeScript provides various other features, like automatically checking for errors every time a change gets made, and the inline documentation helps you ship faster. As Martin simply said:

“Always TypeScript”

In practical terms this means that on the smaller projects, they want code to be easy to write and they can assume developers are familiar with the project. On larger scale projects, code must be ready to read as developers are generally unfamiliar with projects.

Another problem they faced were long build times (+1 hour) for their static site generation, in particular when they were deploying projects with many SKU’s. They solved it by creating better build scripts and since then the different frameworks have improved their build times substantially.

A high-level look at some of the shared packages that the frontend team at Salling Group has created - effectively building blocks that can be reused and extended across the application

A final part of the solution that Martin highlighted was their shared packages. With different implementations across projects they introduced shared packages, essentially shared functionality that can be reused and extended. As shown on the slide above, this includes authentication, search, checkout and other building blocks across the application.

A more detailed look at the shared modules. Note the Algolia service, which is used for search and the Magnolia service which is their CMS

Reaping the benefits of composable design

Today, with almost two years of experience down this path, the frontend team is reaping some of the benefits. Martin in particular mentioned three big ones:

  • Faster time to market, as they can now implement a feature once and easily migrate existing projects by using the packages. This reduces both time and complexity

  • Higher quality, as it is now much easier to test different parts and it ensures consistent behaviour across the application

  • Cross project collaboration, which is actually the benefit that Martin considers most valuable. By working as different teams, having shared packages means that they avoid knowledge silos in each team and this approach encourages and promotes knowledge sharing. Anyone from any project can step in at any time and help.

The shared packages were created using this microservice architecture

Following a few API details and insights into their services and actions, Martin shared their current approach to frontend improvements:

  • Plan according to existing roadmap initiatives. It’s generally hard to get the time required to do new shared modules without giving product owners a benefit early on

  • Code owners are assigned to each package

  • In-house open source approach – Everyone can and should contribute

Finally, Martin closed his presentation by saying that while they have come a very long way and things do look much brighter now than their point of departure, they are not done yet. There’s still more shared packages that need to be developed.

Learn more about composable design

Here’s three recent posts on the topic:

As a part of the Q&A, Martin also shared:

  • They looked closely at DXC vendor Uniform and were quite excited about their approach. As they have such a strong technical team, they instead decided to build something more native and more seamless to their stack.

  • Salling Group recently won an award for its impressive transformational AI/ML solution with battling food waste while limiting lost revenue, and freeing-up time for employees in stores. They did this by addressing a major pain point of manually marking down prices of products which are getting close to expiration date by digitising the procedure, enabling accurate tracking of markdown performance and ML/AI-based recommendations of prices.

You can also download the slides (PDF) or lean back and enjoy the entire recording below