We'll start with the model which exists in our CosmosDB store (I've populated a CosmosDB instance with a dump from OpenTriviaDB, you'll find the JSON dump here). Like our previous demos, we'll use the trivia app. We'll come back to this though, as we need to create our GraphQL schema first. This base class comes from the NuGet package and works similar to the startup class in an ASP.NET Core application by giving us a method which we can work with the startup pipeline and add items to the dependency injection framework. Then we have the Startup class which inherits from FunctionsStartup. This tells the Function runtime that we have a class which will do some stuff when the application starts.
assembly level attribute which points to the Startup class. There's two things that are important to note about this code, first is that we have the [assembly: FunctionsStartup(. Public override void Configure(IFunctionsHostBuilder builder) Let’s start by creating a new class to our project called Startup: To make this work we’re going to need to configure dependency injection for Functions. Something you might notice about this function is that it’s no longer a static, it has a constructor, and that constructor has an argument. Return await _graphQLFunctions.ExecuteFunctionsQueryAsync( Public GraphQL(IGraphQLFunctions graphQLFunctions)
Private readonly IGraphQLFunctions _graphQLFunctions This will create a generic function for us and we'll configure it to use the GraphQL endpoint, again we'll use a snippet from the proof of concept: With the skeleton ready, it's time to make a GraphQL endpoint in our Functions project, and to do that we'll scaffold up a HTTP Trigger function:įunc new -name GraphQL -template "HTTP trigger" These versions are all the latest at the time of writing, but you may want to check out new versions of the packages if they are available.Īnd the last bit of getting started work is to bring in the proof of concept, so grab all the files from the GitHub repo and put them into a new folder under your project called FunctionsMiddleware. Next, we'll add the NuGet packages that we're going to require for the project: Getting StartedĪt the time of writing, Hot Chocolate doesn’t officially support Azure Functions as the host, but there is a proof of concept from a contributor that we’ll use as our starting point, so start by creating a new Functions project:įunc init dotnet-graphql-cosmosdb -dotnet NET framework, Hot Chocolate, so there’s going to be some slightly different types to our previous demo, but it’s all in the name of exploring different options. NET for GraphQL previously in the series, for this post we’re going to use a different GraphQL.
Why CosmosDB? Well I thought it might be timely given they have just launched a consumption plan which works nicely with the idea of a serverless GraphQL host in Azure Functions. But for todays scenario, we’re going to use a HTTP triggered function, our GraphQL endpoint, and then work with a database, CosmosDB. This could be useful in the scenario of a function being triggered by a file being uploaded to storage and then writing some metadata to a queue. If you’re new to Azure Functions, bindings are a way to have the Functions runtime provide you with a connection to another service in a read, write or read/write mode. NET GraphQL with Azure Functions is that it provides a unique opportunity, being able to leverage Function bindings.
Npm serverless graphql apollo how to#
A few months ago I wrote a post on how to use GraphQL with CosmosDB from Azure Functions, so this post might feel like a bit of a rehash of it, with the main difference being that I want to look at it from the perspective of doing.
0 kommentar(er)
