# ziff-davis

Published articles for ziff-davis.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## RetailMeNot GraphQL Federation

DevFeed: [RetailMeNot GraphQL Federation](<https://devfeed.tech/articles/retailmenot-graphql-federation-20365.md>)

Original publisher: [Read original article](<https://engineering.ziffmedia.com/retailmenot-graphql-federation-3bb36dac5aaa?source=rss----d6bb34696ef5---4>)

Author: Kartik Kumar Gujarati

Published: 2021-10-08T15:01:45Z

Content type: article

Language: en

Sources: [RetailMeNot](<https://devfeed.tech/sources/retailmenot.md>)

Topics: [GraphQL](<https://devfeed.tech/topics/graphql.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [Graphs](<https://devfeed.tech/topics/graphs.md>), [Android](<https://devfeed.tech/topics/android.md>), [iOS](<https://devfeed.tech/topics/ios.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [browser](<https://devfeed.tech/tags/browser.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [extension](<https://devfeed.tech/tags/extension.md>), [graphql](<https://devfeed.tech/tags/graphql.md>), [graphql-federation](<https://devfeed.tech/tags/graphql-federation.md>), [ios](<https://devfeed.tech/tags/ios.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [rest-api](<https://devfeed.tech/tags/rest-api.md>), [rest-apis](<https://devfeed.tech/tags/rest-apis.md>), [retailmenot](<https://devfeed.tech/tags/retailmenot.md>), [web](<https://devfeed.tech/tags/web.md>), [ziff-davis](<https://devfeed.tech/tags/ziff-davis.md>)

### AI overview

This article describes how RetailMeNot addressed REST API versioning, over-fetching, and under-fetching by adopting GraphQL and transitioning from a GraphQL monolith toward GraphQL Federation. It covers the company's application and backend rebuild across Android, iOS, web, and browser extension experiences.

### Source excerpt

Did you ever have to maintain multiple versions of a REST API because the change you needed to make would break existing clients? Does your native app have to call multiple REST endpoints to get all the data it needs? This blog post is about how we addressed these common problems using GraphQL and our transition to GraphQL Federation at RetailMeNot. RetailMeNot, part of Ziff Media, Inc, makes everyday life more affordable for shoppers. We are a leading savings destination providing online and in-store coupons and cashback offers to our users. Today, we serve millions of monthly active users from our desktop, mobile web, native (iOS & Android) apps, and browser extension (Deal Finder™) experiences. For the last 10 years, RetailMeNot's engineering teams have built several highly performant, scalable, and efficient systems to bring savings data to our users through our experiences. And like many companies, RetailMeNot used REST APIs to serve the data. However, as the company and the systems grew, we started to experience problems like versioning, over-fetching, and under-fetching with REST APIs. For more details on the classic problems that arise from REST services and how GraphQL solves them, see this blog post. For an introduction to GraphQL, see this blog post. How it started: A Monolithic Graph In 2019, we took a step back to rethink where we are headed in terms of our tech stack and how to best serve future experiences. We decided to rewrite our native Android and iOS apps and the backend that supports them. In addition to this, we also built a brand new browser extension (Deal Finder™) and re-wrote several parts of our core website. As we started to rebuild our native apps, we wanted to solve the above problems we faced with REST APIs. GraphQL seemed like a great solution for this. Enter GraphQL. In our first iteration with GraphQL, we built a GraphQL monolith. Monolith Graph The GraphQL Monolith at RetailMeNot was a single GraphQL Server used by our Native Andro