GraphQL is a great approach to API design that allows clients to get only stuff they need and facade some of the more macabre internal details of your servers.

Graphene-Django is also attractive in its simplicity, since you can expose everything you need in just a few lines of code, be done with web API and move on to the next task on your JIRA board.

However, Graphene, and especially Graphene-Django, did not work well for us, and this approach turned out to be a trap.

As Graphene-Django exposes everything even if you didn’t ask it to do so, a lot of time needs to be spent to make sure it doesn’t expose things you don’t need to expose. As it maps to your ORM, it also has access to all the reverse relations, m2m relations and similar stuff, and before you know it you can access data of other users from just about any query if you dig deep enough. On top of that, access management requires a lot of boilerplate.

Nested queries are not a great benefit, too, when you need to account for database access optimization and response size in general. Some pagination is possible, but it’s very convoluted to integrate into Graphene and further complicates queries for your client applications. Database optimization is also not pretty as there’re tons of contexts where a type can be accessed, and you need to account for lots of them.

That’s why we chose Django Rest Framework. When you account for all the necessities it requires less code and provides much more control over what, how, when and why your web APIs expose. Also, there's a lot of experienced developers on the market and it's easier to teach inexperienced ones.

BestDoctor

Company Members