Modernize your GraphQL APIs with MongoDB Atlas and AWS AppSync
Modern applications typically need data from a variety of data sources, which are frequently backed by different databases and fronted by a multitude of REST APIs. Consolidating the data into a single coherent API presents a significant challenge for application developers. GraphQL emerged as a leading data query and manipulation language to simplify consolidating various APIs. GraphQL provides a complete and understandable description of the data in your API, giving clients the power to ask for exactly what they need — while making it easier to evolve APIs over time. It complements popular development stacks like MEAN and MERN , aggregating data from multiple origins into a single source that applications can then easily interact with. MongoDB Atlas: A modern developer data platform MongoDB Atlas is a modern developer data platform with a fully managed cloud database at its core. It provides rich features like native time series collections, geospatial data, multi-level indexing, search, isolated workloads, and many more — all built on top of the flexible MongoDB document data model. MongoDB Atlas App Services help developers build apps, integrate services, and connect to their data by reducing operational overhead through features such as hosted Data API and GraphQL API. The Atlas Data API allows developers to easily integrate Atlas data into their cloud apps and services over HTTPS with a flexible, REST-like API layer. The Atlas GraphQL API lets developers access Atlas data from any standard GraphQL client with an API that generates based on your data’s schema. AWS AppSync: Serverless GraphQL and pub/sub APIs AWS AppSync is an AWS managed service that allows developers to build GraphQL and Pub/Sub APIs. With AWS AppSync, developers can create APIs that access data from one or many sources and enable real-time interactions in their applications. The resulting APIs are serverless, automatically scale to meet the throughput and latency requirements of the most demanding applications, and charge only for requests to the API and by real-time messages delivered. Exposing your MongoDB Data over a scalable GraphQL API with AWS AppSync Together, AWS AppSync and MongoDB Atlas help developers create GraphQL APIs by integrating multiple REST APIs and data sources on AWS. This gives frontend developers a single GraphQL API data source to drive their applications. Compared to REST APIs, developers get flexibility in defining the structure of the data while reducing the payload size by bringing only the attributes that are required. Additionally, developers are able to take advantage of other AWS services such as Amazon Cognito, AWS Amplify, Amazon API Gateway, and AWS Lambda when building modern applications. This allows for a severless end-to-end architecture, which is backed by MongoDB Atlas serverless instances and available in pay-as-you-go mode from the AWS Marketplace . Paths to integration AWS AppSync uses data sources and resolvers to translate GraphQL requests and to retrieve data; for example, users can fetch MongoDB Atlas data using AppSync Direct Lambda Resolvers. Below, we explore two approaches to implementing Lambda Resolvers: using the Atlas Data API or connecting directly via MongoDB drivers . Using the Atlas Data API in a Direct Lambda Resolver With this approach, developers leverage the pre-created Atlas Data API when building a Direct Lambda Resolver. This ready-made API acts as a data source in the resolver, and supports popular authentication mechanisms based on API Keys, JWT, or email-password. This enables seamless integration with Amazon Cognito to manage customer identity and access. The Atlas Data API lets you read and write data in Atlas using standard HTTPS requests and comes with managed networking and connections, replacing your typical app server. Any runtime capable of making HTTPS calls is compatible with the API. Figure 1: Architecture details of Direct Lambda Resolver with Data API Figure 1 shows how AWS AppSync leverages the AWS Lambda Direct Resolver to connect to the MongoDB Atlas Data API. The Atlas Data API then interacts with your Atlas Cluster to retrieve and store the data. MongoDB driver-based Direct Lambda Resolver With this option, the Lambda Resolver connects to MongoDB Atlas directly via drivers , which are available in multiple programming languages and provide idiomatic access to MongoDB. MongoDB drivers support a rich set of functionality and options , including the MongoDB Query Language, write and read concerns, and more. Figure 2: Details the architecture of Direct Lambda Resolvers through native MongoDB drivers Figure 2 shows how the AWS AppSync endpoint leverages Lambda Resolvers to connect to MongoDB Atlas. The Lambda function uses a MongoDB driver to make a direct connection to the Atlas cluster, and to retrieve and store data. The table below summarizes the different resolver implementation approaches. Table 1: Feature comparison of resolver implementations Setup Atlas Cluster Set up a free cluster in MongoDB Atlas. Configure the database for network security and access. Set up the Data API. Secret Manager Create the AWS Secret Manager to securely store database credentials. Lambda Function Create Lambda functions with the MongoDB Data APIs or MongoDB drivers as shown in this Github tutorial . AWS AppSync setup Set up AWS Appsync to configure the data source and query. Test API Test the AWS AppSync APIs using the AWS Console or Postman . Figure 3: Test results for the AWS AppSync query Conclusion To learn more, refer to the AppSync Atlas Integration GitHub repository for step-by-step instructions and sample code. This solution can be extended to AWS Amplify for building mobile applications. For further information, please contact firstname.lastname@example.org .
Building a Modern App Stack with Apollo GraphQL and MongoDB Atlas
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. 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. 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. Register for Atlas today Learn more about the supergraph on the Apollo blog .
Introducing the MongoDB Atlas Data API, Now Available in Preview
As the leading data platform , MongoDB is hyper-focused on accelerating and simplifying how developers leverage their application data. This has led to the introduction of features like serverless instances and the Atlas Triggers that minimize the operational burden associated with traditional database workloads. Today, we’re excited to announce the next step forward in this mission with the introduction of the MongoDB Atlas Data API – a fully managed, REST-like API for accessing your Atlas data. The Data API makes it easy to perform CRUD and aggregations on your data in minutes and allows you to query MongoDB from your backend in any language, without the need for drivers. The next level of data access Organizations are increasingly relying on operational data layers to build distributed architectures like microservices for their modern applications to speed-up development and stay competitive in rapidly changing markets. These stacks often require scalable, highly available, and secure access to the data layer. The most popular way to architect these data services is to build APIs that communicate with MongoDB data over HTTPS using REST or similar protocols. However, creating a custom-built API typically takes a lot of time and effort. It's a painful process that introduces unnecessary operational burdens like provisioning additional servers, connection management, and scaling. With the Atlas Data API, customers can generate a fully managed, REST-like API for their Atlas data in seconds. Developers no longer need to worry about the underlying infrastructuring of their APIs, and instead can enjoy the efficiency of intuitive, out-of-the box data access, while still being able to leverage the always-on and highly available qualities of Atlas as the underlying database. This unlocks a whole new level of developer productivity for use cases that were previously time consuming to accomplish – such as building data-centric microservices, simplifying access from serverless functions, and integrating with third party services . The API even has built-in support for aggregation pipelines to use with services like Atlas Search . Try the Atlas Data API All customers now have the ability to enable the Data API for their Atlas deployment. We invite you to try it out today with a new or existing Atlas account. It’s incredibly easy to get started: simply choose the cluster you’d like to connect to and generate an API key. That’s all it takes to set up and start accessing Atlas data. Have questions? Check out our documentation or head over to our community forums to get answers from fellow developers. What's next for the Atlas Data API This preview release is just the beginning. Support for services like Data Lake and Serverless Instances will be added over the coming months. And, long term, we see the Data API as the next step in our journey to abstract and automate infrastructure decisions – to help developers build the future faster. Atlas Data API documentation can be found here