1. Introduction


KBT Threads Logo

Congratulations on joining KBT Threads! KBT Threads has been a successful brick and mortar store dating back to 1972 with a focus on outdoor sports and adventure clothing. While KBT Threads has a long successful history, we have been struggling against our more digital native competitors. We have invested in several digital channels including Web, iOS and Android Apps, and store pick-up options.


Customer satisfaction

Despite investments over the years, our current digital offerings have failed to delight and impress our customers. In our customer research, we have found that our customers

  • are frustrated by the different capabilities across our different offerings, along with the fact that our stores are not tied in with what customers have purchased through our digital channels
  • complain about performance issues with our mobile and web experiences, and that these often behave and look very different.

Front-end development lifecycle

Our current back-end infrastructure is a microservice architecture. Our back-end teams have mature patterns and processes for spinning up new capabilities quickly. Unfortunately, the performance and delivery capability of our backend services hasn't translated into new features quickly dropping within our mobile and web experiences. These features need to be combined across various services, and that "glue" code work leads to a lot of duplicated work in our frontend applications.

What are the common challenges with REST services for front-end developers?

Back-end delivery expectations

Implementation with ReST Services

Building small fine-grained microservices was done in the hope of allowing us to move quickly and keep up with other digital native competitors. However, this has resulted in a microservice sprawl and has not provided customer satisfaction our business was hoping for.

In our internal research, we've found that more services caused our front-end teams to struggle finding new capabilities and orchestrate them together. This has substantially slowed down delivery and added complexity on the frontend code in order to maintain performance. As a result, teams have been asking the backend team to build and maintain new backend-for-frontends (BFFs) instead of the microservices that exist.

Opportunities for a new approach

With this feedback in mind, we have gone back to the drawing board. Our product and engineering leadership gathered feedback from front-end and back-end developers who have been with Activewear through this whole microservices process. Based on what we now know, we have decided to rework our digital footprint with the main goal of having a common customer experience in store, on the web site, and in the mobile apps. As part of our strategy to align our channels, we have settled on to power our backend interface and provide a unified API across KBT Threads.

Ultimately, our goal is to provide a better customer experience, without adding new layers of tech debt to our back-end developers.

By providing a single endpoint that uses GraphQL to expose all the sub services, we will

  • have data and CX component parity across our channels
  • de-duplicate the service combinations and chaining that was previously happening in the front-end applications
  • make it easier for both our back-end and front-end developers to deliver more

With decided on for the future of KBT Threads, we also needed to align on a back-end architecture that would successfully support our vision and scale as our digital business grows. We know we want to have a single API endpoint that was shared between all our front end services to ensure a consistent user experience. We won't repeat the mistakes of the past and build a monolithic architecture, so we have decided to build out a federated GraphQL architecture leveraging Apollo's , starting with a small MVP.

What to expect from this lab

We're really excited to have you join our developer team at this important point in time!

Our goal is for you to expose a small slice of our current services via a single, unified API. We're going to start with a modeling exercise as a team. Once we've finished the design process, you will have the chance to work through how you could expose services via our GraphQL API, and then connect those into a frontend experience. As you have more familiarity with the tooling and technology involved in using , we will give you the opportunity to go directly against new which aren't currently exposed via suitable helper services.

High level components diagram

Working through the upcoming labs, you will perform the following:

  • Setup an account and create a
  • Link with the
  • Build out the Orders by fetching data against a REST API
  • Build out a front-end application to make a
  • Create a curated view of the for third party consumption
  • Observe and monitor your

Up next

In the next section we'll set up your account and create the supergraph