Building a Modern App Stack with Apollo GraphQL and MongoDB Atlas

Sumedha Mehta and Phil Prasek
June 13, 2022 | Updated: March 12, 2024

Delivering new app experiences with legacy architectures is slow and painful. Many organizations invest massive amounts of resources to make their infrastructure more resilient and flexible yet find they’re still not delivering products at the speed they seek. API complexity means that, rather than delivering new experiences, frontend and backend teams must navigate scattered microservices, versioned REST endpoints, and complex database management. This article explains how teams can reduce complexity through the use of Apollo GraphQL and MongoDB Atlas.

GraphQL can help teams integrate these scattered REST APIs and microservices into a unified schema that frontend developers can query, fetching only the data required to power an experience while being agnostic to where the data is sourced from.

However, running everything through a single GraphQL server (read: monolith) with multiple teams rapidly contributing changes creates a bottleneck. The complexity of the API layer grows exponentially as the number of client devices, applications, and developers increases — and backend teams can no longer work autonomously or push changes on their own releases schedules.

To be efficient with GraphQL, developers need:

  • A unified API, so app developers can rapidly create new experiences

  • A modular API layer, so each team can independently own their slice of the graph

  • A seamless, high-performance data layer that scales alongside API consumption

Apollo GraphQL + MongoDB Atlas: An app stack that delivers

A supergraph is a GraphQL API designed to benefit frontend and backend teams simultaneously. It’s a unified API layer built with Apollo Federation, which is a declarative, modular GraphQL architecture.

Unlike a monolithic schema, a supergraph is composed of smaller graphs called subgraphs, each with their own schema. Teams can evolve their subgraphs independently, and their changes will be automatically rolled into the overall supergraph, allowing them to deliver autonomously and incrementally.

However, the efficiency of a supergraph depends on the capabilities and reliability of the underlying data layer. MongoDB Atlas — MongoDB’s fully managed developer data platform — comes with that promise. It offers a flexible document model that gives developers an intuitive way to work with GraphQL’s nested data structure, while providing a reliable data layer that can run anywhere, be deployed across multiple regions and cloud providers, and scale horizontally due to its distributed nature.

Together, a supergraph and MongoDB Atlas create a composable app stack that eliminates complexity and empowers teams to innovate faster than ever before.

Diagram of an app architecture with Apollo Federation and MongoDB Atlas
Figure 1: Simplify app architecture with a composable supergraph and unified data access layer using Apollo Federation and MongoDB Atlas

Why GraphQL supergraphs?

App dev experience

When crafting a new app experience, developers will want to browse a unified schema, create queries that fetch exactly the data needed, measure API performance, and use the API in minutes instead of dedicating days or weeks trying to find the right API to stitch into each web, Android, iOS, tablet, and watch app individually. However, when apps have to use lots of REST APIs directly, the developer experience and end-user performance suffers. According to PayPal, UI developers were spending less than one-third of their time actually building UI. The remainder of that time was spent figuring out where and how to fetch data, filtering/mapping over that data, and orchestrating API calls.

With a supergraph, developers can query a single GraphQL endpoint for all the data they need and discover, consume, and optimize without having to navigate a sea of REST APIs and microservices.

A key characteristic of a principled GraphQL API is an abstract, demand-oriented schema, which provides the data needed to power the customer experience and abstracts the microservices and data layer underneath.

The most powerful graphs serve as a facade on top of existing microservices by abstracting the lower-level backend domain models into a curated customer experience model that provides the high-level information displayed in the UI. This experience model allows for a consistent UX across web, mobile, and wearable apps.

API dev experience

Backend developers want the freedom to build and evolve services and capabilities autonomously. But this is a tall order when clients are simultaneously consuming services. It’s nearly impossible to refactor without introducing breaking changes and harder still to understand what the impact of those breaking changes will be. The result is that almost any change to the API requires coordination with all the client teams.

With a supergraph and a flexible data layer behind it, teams can deliver changes independently to modular subgraphs that compose into the overall supergraph. Apollo Federation’s declarative architecture and powerful directives keep teams working autonomously without breaking clients.

What database works best with GraphQL?

Building a scalable supergraph starts with choosing the right data layer to power backend services. In the past, relational databases required ORMs or manual mapping of the underlying relational format to an object/document structure that apps could use, such as JSON. An impedance mismatch between what the database provided and what client apps needed resulted in performance and maintenance issues that slowed down app development and app performance.

In contrast to relational databases, MongoDB’s document model and GraphQL share a simple nested data structure, which means developers can easily use them together without having to map GraphQL to relational data and define relationships. The added composability of Apollo Federation lets developers easily federate across multiple collections or databases, between single and multi-cloud Atlas clusters running in different regions, and even between Atlas and on-premises clusters.

In this way, developers gain the flexibility of MongoDB’s document model and the freedom to iterate on their GraphQL schema with safety and confidence ensured by automated schema checks.

How to connect your Apollo supergraph to MongoDB

When it comes to choosing how to connect the subgraphs to the data layer, a few options are available:

Traditional subgraph (microservices plus database)

In many environments, there are years’ worth of existing microservices, REST APIs, and SOA services in production. Subgraphs (written in any of 20-plus languages and frameworks) can be added as a new layer on top of these existing microservices and composed into an experience-driven supergraph that serves as a ViewModel backend to power new app experiences for web, mobile, and wearable devices. This is a highly effective and proven model.

Graph-native subgraph (direct to MongoDB)

When new subgraphs are added in greenfield environments or to add net-new capabilities, the subgraphs can be designed to talk directly with the database without microservices or REST APIs in the middle. This approach isn’t always the right answer, especially for companies that have standardized on REST or gRPC in the backend. However, it is a simpler setup that can improve performance by removing a layer.

Traditional subgraph (microservices plus MongoDB Atlas)

MongoDB Atlas is a fully managed, multi-cloud, multi-region data layer for traditional microservices. With options such as the official MongoDB Drivers for 16 languages, a fully managed HTTPS–based Data API, or community managed ODMs such as Mongoose, developers have a range of options to build their supergraph's data layer with Atlas. Developers get the flexibility of choosing a path that provides them with an idiomatic and familiar way to work with the database in the language and development style that they are most familiar with.

MongoDB Atlas GraphQL API (hosted subgraph API)

MongoDB Atlas’s GraphQL API is automatically generated based on the underlying database document schema and can be directly composed as part of a supergraph. Developers who choose this approach can reduce the amount of time spent writing custom GraphQL resolvers, as these are automatically generated by MongoDB Atlas.

When the document model closely matches the query shape — a paradigm that is common within document databases such as MongoDB — the queries can be served without transformation or mapping. This setup also applies to relationships between different types of documents in different collections; thus, the generated GraphQL schema will also allow devs to query collections that other teams may own in the same graph.

If developers’ desired query shape differs from the underlying document model, such as when shaping schemas in a Server Driven UI (SDUI) pattern, they can leverage the @requires schema directive to pull in and transform multiple document fields into an experience-oriented property tuned for rendering by frontend apps. In this way, devs can benefit from both efficient data access and custom model mapping when needed.

Diagram of a supergraph
Figure 2: Composing a supergraph with Apollo Federation, custom built resolvers for MongoDB, and the hosted MongoDB Atlas GraphQL API endpoint

Expand business use-cases with a developer data platform

Supergraphs make it easy to compose microservices, but when it comes to hosting, managing, and storing the data that performs the business logic, MongoDB's developer data platform - Atlas - can help teams build their app requirements faster.

Need a search bar? The same data stored in an Atlas Cluster can be search-indexed and use Atlas Search to perform full-text search operations without additional setup or syncing data to another search technology.

Want to embed graphs and charts? A time series collection can make it easy to query large chunks of data by timestamp, and MongoDB Atlas Charts lets devs use the same database to build these inside applications. Other services, like custom Data APIs and Data Federation, help ensure that data can be queried and stored in the way that best fits a team’s needs.

Scale faster with Apollo GraphQL and MongoDB Atlas

Engineering teams need to be able to anticipate both current and future needs. MongoDB Atlas delivers a developer data platform that spans multiple regions, clouds, and deployment types to solve the data challenges of transactional workloads, modern apps, and microservices. Self-healing clusters ensure that developers are not scrambling to diagnose issues with their data nodes, and multi-region and multi-cloud deployments provide automatic failover for both models, respectively.

Together, Apollo GraphQL and MongoDB are committed to providing developers with the effective tools they need to simplify their architecture, improve app performance, ship faster, and grow their businesses.

Update March 12, 2024: The MongoDB Atlas GraphQL API feature has been deprecated and the End of Life date is set for 3/5/2025

Register for Atlas today

Learn more about the supergraph on the Apollo blog.

← Previous

Highlights From MongoDB World 2022, Day 3

As we said on Day 1 , MongoDB World is a developer-focused event. And on Day 3, we really set out to prove it. The day got going with a keynote from best-selling author, pioneering inventor, and futurist Ray Kurzweil. His encyclopedic knowledge covers a wide range of topics and subject areas, and his talk was equally broad and freewheeling, touching on everything from computational power to vaccine trials to life expectancy and literacy rates. Kurzweil’s general viewpoint was overwhelmingly positive. He cited global poverty and literacy rates, per capita income, and the spread of democracy as examples of how the world is steadily becoming a better place to live. Not shy of making predictions, Kurzweil anticipates computational power roughly doubling each year, bringing AI ever closer to emulating human intelligence. In fact, he predicts that some AI systems will be able to pass the Turing test by 2029. And he sees humans eventually connecting directly to AI systems, expanding our emotional and intellectual intelligence far beyond our current state. He refers to this eventuality as the “ singularity ” and with it, human life will be changed forever. Minds were blown, but not so much that the developers in attendance weren’t ready to get down to doing what they love to do: building apps and writing code. Immediately after the keynote, Builder’s Fest kicked into gear in the Partner Promenade. The floor of the Jacob Javits Center was transformed by dozens of pods where MongoDB experts, partners, and customers gave hands-on tutorials showing how their services and applications integrated with the MongoDB developer data platform. Booming over the main sound system was a super-sized, four-person Mario Kart battle royale, where the victors won prizes like a Nintendo Switch. Another pod hosted a Price is Right–style game show, The Database is Right, where contestants drawn from the audience answered trivia questions about MongoDB, document databases, and database functions. Adjacent to the Bob Barker cosplay, MongoDB senior product manager Rob Walters gave an eager audience a live demo of how to configure the MongoDB Connector for Apache Kafka to use MongoDB as a source or a sink. Our Kafka connector enables developers to build robust, reactive data pipelines that stream events between applications and services in real time. Over on the Google Cloud Coding Stage, four developers competed to see who could build the closest version of the Google homepage in 20 minutes — without previewing their work. The blind coding test resulted in some fairly primitive approximations of the real thing, but all four contestants were praised for their high pressure creations. The winner of each round took home a limited edition MongoDB track jacket. MongoDB CTO Mark Porter joined in a number of Builder’s Fest activities, delivered several short talks, and often drew a crowd for impromptu Q&A. At one point he gave a “Chaos Presentation” — an improvised talk guided by randomly selected imagery — about the outages that inevitably occur in the public cloud, despite the exceptionally resilient infrastructures and high service levels. “Mirror image is an illusion,” Porter said. “A laptop is not staging, staging is not production, and production is not production.” Different regions have different hardware and configuration patterns that can build up over time, he said. “Staging has had far more rollbacks than production,” he said. “Find weaknesses in your architecture by doing post-mortems after an outage. Make staging environments reproducible by blowing them away from time to time. By making staging more predictable, over the course of a few years, you can make production more predictable.” In response to an audience question about what’s more important, implementing a culture of committing to rollbacks or automating it, he said, “The culture of rollbacks is what’s important, but at scale — meaning a couple thousand engineers — culture won’t be enough. You’ll need to automate some of it. But make it so rollbacks are not a bad thing.” A few pods over, developer advocate from Prisma , Sabine Adams, gave a talk entitled, “Giving MongoDB Guardrails.” His talk included step-by-step instructions, using the brand new MongoDB Atlas CLI , on how to ensure data consistency by providing an easy-to-read schema and a type-safe database client. First, he set up a MongoDB cluster in the CLI, then he initialized a TypeScript project with Prisma to model the data, and then used the Prisma CLI to create and retrieve some data. The Prisma client provides an API for reading data in MongoDB, including filters, pagination, ordering, and relational queries for embedded documents. If you want more highlights about MongoDB World 2022, read our Day One and Day Two recaps. For all those who attended the event, we’re happy you made it. For anyone who missed it, we hope to see you at next year's event.

June 10, 2022
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024