What are cross cutting concerns? Typically within a system we can consider something a cross cutting concern if it has to be involved with every action (in this case a request), these things tend to be security, logging, validation and more. Using middleware The idea of a pipeline of middleware that serves every request makes the process of adding some cross cutting concerns to our GraphQL service really quite easy. The Hot Chocolate framework allows you to add “request middleware” that runs for every request, or “field middleware” that runs on every field within that that request. We may use ..read more

Over the last year or so I’ve helped onboard a number of engineers at Pushpay to how we do GraphQL. One question that often comes up is How can I select all fields on a type? GraphQL doesn’t have the equivalent of SELECT * FROM Object, you can only get the fields in the response that are in the query that was sent and in my opinion this is a very good thing. So why is that? The major reason for me is the ability to make safe breaking changes to a schema. Occasionally (ideally as little as possible) we’ll need to make a breaking change to a schema, the way we tend to approach these schema cha ..read more

Whenever we have a web application we’ll typically want to be able to observe it in production. Typically common questions will be: Which endpoints are being exercised the most? Which endpoints are running slower than normal? Which endpoints are returning errors to our users? Eagle eyed readers will notice all of these quetsions are about endpoints or routes. Most Application Performance Monotiring (APM) products will have a built in knowledge of HTTP and easily be able to show this to you. New Relic which I’ll use for the rest of my examples even has an understanding of MVC built in and wil ..read more

Late last year I wrote about Securing a GraphQL endpoint, using ASP.NET Core policy based authorization. The short version of this is that we can create authorization policies and use Hot Chocolate to apply those policies to fields in our schema. If the current user cannot fufill those policy requirements then the execution of that field is stopped and null is returned. It’s impotant to note that this doesn’t stop the entire query but just the field in question. What is “resource based authorization”? All of the examples used in the above articles we can think of “declarative authorization” wh ..read more

What is Relay? The GraphQL spec isn’t very prescriptive on the structure of your schema leaving the design completely in your hands. This means we’re likely to see quite a few different approaches to certain patterns between different services. One specification that has become pretty common across services is Relay. If you check out their webpage you’ll notice that it advertises itself with Relay is a JavaScript framework for building data-driven React applications powered by GraphQL, designed from the ground up to be easy to use, extensible and, most of all, performant. Relay accomplishes t ..read more

With the release of Hot Chocolate 11 comes a very slimmed down approach to building custom scalars in GraphQL. What are custom scalars? In GraphQL fields can be complex types such as objects, interfaces and lists or they can be scalar values. The GraphQL spec lists all the built in scalars such as ID, Int and String. However we also have the ability to define our own custom scalars, we do this because we want to be able to take advantage of the strong type system that GraphQL provides. With custom scalars we can: Make invalid data for types an error before it even reaches your resolvers. Bett ..read more

One of the first things we’ll typically want to do when building out any API whether its’ GraphQL or REST is to secure it against users who should not have access to it. I’ve seen a few articles about this recently when it comes to GraphQL but these are usually about securing the entire /graphql endpoing with a single authentication / authorization policy which isn’t very nuanced, especially given the nature of GraphQL. Defining requirements Let’s start by definining our requirements for authentication and authorization. A valid JWT is required to be authenticated. This includes validating cl ..read more

The Hot Chocolate GraphQL framework does an excellent job building a schema from your C# types by convention. An easy example would be to see a C# type such as: public class User { public string Username { get; set; } public string? Name { get; set; } public bool IsVerified { get; set; } } and it will build a GraphQL object that looks like the following: type User { username: String! name: String isVerified: Boolean! } One point to notice is that differences in casing between C# properties and GraphQL field names, this is where we have a difference in naming / casing conventions betwee ..read more

Declaring our schema When we build a GraphQL service we define our schema, we typically do this via two different mechanisms. The first is often referred to as schema first where we declare the schema using the SDL that may look something like: type Query { product(id: ID!): Product } type Product { id: ID! name: String! } The the other approach is usually referred to as code first which will look very different depending on which GraphQL server framework you’re using, below is an example from the excellent .NET GraphQL framework Hot Chocolate. public class QueryType : ObjectType<Quer ..read more

The GraphQL specification for errors when resolving a field state the following. If an error is thrown while resolving a field, it should be treated as though the field returned null, and an error must be added to the errors list in the response. As an example imagine we the query below and that for whatever reason we couldn’t resolve the reviews. query { product(id: "42") { name price { amount currency } reviews { title content } } } This would lead to a response that looks like the JSON below. { "data": { "product": { "name": "Olympic Barbell", "price": { "amount": "199.95", "currenc ..read more