Today, we’re announcing the public preview of two GraphQL resolver types for Synthetic GraphQL in Azure API Management: Azure Cosmos DB and Azure SQL resolvers. If you ever faced the challenge of exposing your database through GraphQL, you’re aware of the complexities involved. It typically involves writing numerous lines of code, dealing with resolvers, and figuring out the nuances of database access. But is there a simpler way?
Enter Azure Cosmos DB and Azure SQL data types in Synthetic GraphQL for Azure API Management. Upload your GraphQL schema and expose desired data using familiar database concepts – a seamless and straightforward process. In this blog post, I will walk you through the process of adding a GraphQL resolver for a Cosmos DB backend and demonstrate how to test it.
Let’s look at the to-do list application as an example. Every to-do item has an id, title, and status. I already have some of the items in Azure Cosmos DB, which has the following structure, and want to enable a list of simple CRUD operations on it.
{
"id": "1",
"title": "Test1",
"completed": false
}
I can model this to-do item application by creating the following GraphQL schema:
type TodoItem {
id: ID!
title: String!
completed: Boolean!
}
input CreateTodoItemInput {
id: ID!
title: String!
completed: Boolean!
}
input ReplaceTodoItemInput {
id: ID!
title: String!
completed: Boolean!
}
type Query {
todoItems: [TodoItem]
todoItem(id: ID!): TodoItem
}
type Mutation {
createTodoItem(input: CreateTodoItemInput!): TodoItem!
replaceTodoItem(input: ReplaceTodoItemInput!): TodoItem!
deleteTodoItem(id: ID!): Boolean
}
To create this GraphQL API within the Azure API Management service:
With the addition of Azure Cosmos DB and Azure SQL, you can now select what data source you want to use when you’re configuring your resolvers – HTTP API, Azure SQL or Azure Cosmos DB. Let’s create a Cosmos DB resolver for a 'todoItem' query:
When you choose a specific data source, the resolver policy editor gets a pre-populated XML document that defines how to query a database and retrieve the data we need. For the todoItem query I need to get an element by ID, so I create the following policy:
<cosmosdb-data-source>
<connection-info>
<connection-string>”replace-cosmos-db-connection-string”</connection-string>
<database-name>tododemo</database-name>
<container-name>todo</container-name>
</connection-info>
<read-request>
<id>@(context.GraphQL.Arguments["id"].ToString())</id>
<partition-key>@(context.GraphQL.Arguments["id"].ToString())</partition-key>
</read-request>
</cosmosdb-data-source>
Note: For simplicity, I put a connection string directly into the policy. However, you should not store secrets as plain text. Instead, you should use Named Values connected to a secret in a Key Vault.
This is a relatively simple resolver. I specified my connection information for an Azure Cosmos DB including connection string, database name and a container name. In the following <read-request> section I take an id argument from the GraphQL request context and use it to perform a query against the database. You can use read, write, and delete requests, which hide some of the complexity of interacting with the database, but you can also write your own queries with the <query-request /> policy section.
Now when I uploaded the schema and created a resolver for a query, I can test it in a built-in GraphQL test console:
Having successfully obtained the necessary data from Azure Cosmos DB using a GraphQL API, we can now generate additional resolvers – one for each query and mutation following the same process that we used before. Check out the documentation for more information.
Azure Cosmos DB and Azure SQL resolvers are in public preview, give it a try and let us know what you think in the comments below!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.