Motivation

DjraphQL was created to ease the burden of standing up and maintaining a GraphQL API in a Django application.

The problem

We have a Django app and want to expose a GraphQL API. We’ll reach for Graphene, which is an amazing library for building GraphQL schemas in Python. Let’s go!

We’ll create a Graphene class defining the GraphQL type for our first model. Simple enough. Then, we’ll create another class to read a list of those models. And a class to get an instance of the model by its primary key.

How about mutations? We need a class to insert an instance of our model. That requires two classes, one for the insert operation and one for the input to that operation. Same for updates. Well, at least deleting by primary key is a single class. And, we obviously want searching and sorting, too, so a couple more classes to handle that.

Okay, so to expose a single Django model in our API, we’ve created ten or so classes.

Hmm. Our Django app is quite large. It has hundreds of models. As the number of Django models we expose via our API grows, these classes will become a significant maintenance burden. As our app continues to grow, how do we ensure each of our classes remains secure, consistent, and performant?

Maybe we should just use REST?

Taking a step back

Indeed, a common GraphQL complaint is that the developer experience is great for frontend engineers – who get to have all the fun – and poor for backend engineers, who are tasked with the burden of maintaining the hundreds of classes needed to serve our GraphQL schema.

Even aside from the sheer amount of code to maintain to serve a GraphQL schema, there are other issues lurking.

• Performance: engineers must be careful to avoid the dreaded N+1 pattern, which is a common GraphQL pitfall.

• Security: in a graph-based API, avoiding IDOR issues requires a diligence which becomes more difficult to achieve as the API surface area grows larger and larger.

Removing this burden is the motivation for DjraphQL.

Use cases

Consider using DjraphQL to build a GraphQL schema if your application is mostly C.R.U.D. operations on your Django models.

DjraphQL is perhaps not a fit in situations where your Django models are largely hidden from your API consumers, i.e., your models do not map to entities in your API.

Shortcomings

There may be some features in the GraphQL specification that DjraphQL does not handle.

For example, Union types are not yet supported.