Our Journey in Adopting a Federated GraphQL at SSENSE
Over the last 6 months, SSENSE developed a federated gateway to our presentational micro-services (commonly referred to as the back-of-the-front-end). During this period, we also planned and migrated a single code path on the website to use the newly minted gateway. This article gives a brief look into how and why we chose this pattern to evolve our consumer applications at SSENSE.
SSENSE runs on a rich micro-service architecture, with many teams in many different domains. Here is a quick visual representation of the number of services needed to render our product listing page:
The complexity of our data, in concert with our average website traffic (astronomical, sometimes), makes the case for an equally complex architecture. Our data has a high variability of cache TTL (for example, inventory availability needs to be refreshed faster than static text content), and some domains have specific ownership requirements (for example, some devs, though not the canonical owner of product data, own part of the product data).
A few years ago, we made the decision that these two factors warrant a discreet service(s) for certain teams/data, and decomposed our monolith API into many micro-services. Initially, this application was a huge improvement over our legacy set-up — teams were shipping faster, data was less coupled, objectives were clear. Eventually, though, as we hired more teams, those teams worked on features that required coupling of data (for example, personalization needing both user and product data). Since we didn’t want the business logic living on the client, we built several “aggregation” services.
