Learning how to develop GraphQL solutions with .NET

Screen Shot 2019-08-26 at 11.04.33 PM

If you are building a data-driven web or mobile application, then key concerns you need to address is how data will be surfaced to the client and how the client can update the state on the server. This is not a new problem, and one that we have been solving for decades.

GraphQL provides one way to address this problem and uses an approach that provides significant benefits over previous RPC-based approaches. GraphQL was originally created at Facebook several years ago. It has been widely adopted since by Github, Concur, Airbnb and more. We’re even now adopting it at DocuSign. If you are doing React development, GraphQL has become the de-facto way to query from React clients.

What is GraphQL?

At its heart, GraphQL is several things.

  • A schema that allows defining a structured view of data that will be surfaced to / queried / updated by a GraphQL client.
  • A query language for interacting with a GraphQL endpoint to retrieve, update, and subscribe to notifications.
  • Tooling and SDKs for building GraphQL clients and servers, or interacting with GraphQL endpoints such as the GraphiQL editor, clients like Apollo and Relay, servers like Apollo, GraphQL for .NET, and more.

A few things that have stood out for me that I have really liked about GraphQL.

  • It provides a standard way to query and update data including non-crud based actions. It supports “graphs” of data allowing queries to pull hierarchical data.
  • It puts power in UI teams hands to be able to hand craft queries with the data they need, without having to constantly send custom requests to the API team.
  • It has GraphiQL which is an awesome intellisense-driven tool for querying GraphQL endpoints that you can provide to developers for interacting with the endpoint.
  • It can work side by side with, and wrap existing “REST” APIs
  • It is not opinionated about where data resides, it is not bound to a database. Data  could live in MongoDB, SQL, in documents like S3/Azure Blob, or even in memory. It is really easy to make GraphQL work with any data store
  • It allows full control from the server-side as to what data is exposed.

There are also plenty of tradeoffs with GraphQL vs traditional APIs and it is not a silver bullet. Fortunately it is not mutually exclusive and can live side by side with “REST” APIs. Still you should go in with eyes open (as with any other technology or approach).

GraphQL with .NET

Yes you can develop GraphQL solutions with .NET! There are several open source projects that enable this, my favorite one being GraphQL for .NET. GraphQL for .NET lets you create GraphQL schemas and queries in C#, and then surface them via an ASP.NET core endpoint. It also provides a C# client which you can use to issue queries from an application such as as a Xamarin mobile client. All of the libraries are also available on NuGet. If you head to the GraphQL for .NET documentation you can find out more.

I’ve also created an ASP.NET Core example endpoint which can be ran on Windows, Mac or Linux which you can download from here. The readme contains lots of example queries you can run using the GraphiQL editor that is built in.

Check out my LinkedIn Learning Course

If you are interested in learning more about GraphQL for .NET, you can also check out my LinkedIn Learning Course: API Development in .NET with GraphQL. In the course I’ll take you through building the Orders GraphQL endpoint above from scratch in ASP.NET Core. I show you how to use GraphQL for .NET to define your schema, queries, and mutations, and subscriptions and expose them via ASP.NET Core. It’s heavily code based so you can follow along and build it with me. If you check out the course, let me know what you think.

GraphQL is growing

GraphQL is exploding in traction, with more and more companies adopting it as the standard. All signs are that will continue. It is exciting that this powerful ecosystem is available now to you as a .NET developer!

This entry was posted in ASP.NET, ASP.NET Core, GraphQL. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.codebetter.com/glennblock Glenn Block

    HI Joao

    I agree, but that is easy to do. Because GraphQL relies on a functional / resolver model you can pretty much have the endpoint talk to anything. In my code I used an in-memory data store for simplicity, however I deliberately did that through injecting services via an IoC to show a model that could easily work against a real data store. GraphQL for .NET also supports async, so you can have async calls being made to get your data.

  • Joao Paulo Grassi

    Nice write up. Would be nice to see some examples with real use cases, and with databases not just in-mem stuff. Folks use EF Core/Dapper mostly and would be cool to see an implementation using those data access frameworks.

  • http://www.codebetter.com/glennblock Glenn Block

    Agreed that it is not where node is, but disagree about the todo list. I know of several major companies that are using it in production.

  • http://blog.puredev.eu/ Pure Development

    But the .NET support is still far-far behind nodejs.
    It is not feasible to use that for production and for anything more complex than Todo List