Hacker News Reader

Comment by dopeboy | Hacker News Reader

(I realize this library is about PHP - read on for a slight tangent in the Django world)

For the Djangonauts in the crowd, has anyone moved from REST to GraphQL in their teams? How's the transition been and what kind of tools did you use?

I'm giving a talk at this year's PyBay and am looking to solicit some stories / experiences.

View on HN

Yes. The transition has been frustrating. We won't go back because of the benefits inherent in GraphQL's design, but graphene-django has so much boilerplate that a more complex application becomes very convoluted. In my opinion there's a lot of work to be done to get it to a point where it's not a frustrating experience to implement.

Similar experience. While the django rest framework is a joy to use, I’m almost inclined to call graphene a headache. Poor docs, lots of spread our third party extensions that really should be in the core... I have even found myself wondering if the stark discrepancy between drf and graphene reflects or hints at a decline of django as a framework.

I don't know about decline but in the UK there are currently 65% more Django roles than Rails on Indeed.co.uk if you search by title:Django or Django title:Python.

You won’t go back because of the gains but would you have done it again from the start? Or is it more of the supporting libraries being the problem.

Even outside of python many people seem to be on the fence when talking about actually implementing it.

It's the supporting libraries. GraphQL itself is fantastic and solves so many of the issues that crop up when using REST, especially around excessive requests, extraneous data and poor transaction support. My team's core knowledge is in Python and Django so that's where we're most productive, even hamstrung by the tools, but with a bit more flexibility in timelines I'd probably go the typescript/node/apollo route.

We just started using it for parts of our frontend API in production. We started with Graphene but it ultimately fell very short of our expectations, so I actually wrote my own GraphQL library from scratch. It's far from spec-compliant, but it supports the bare minimum needed to be able to run queries and mutations, and provides a lot of performance escape hatches that most GraphQL libraries simply don't (like batched resolution for lists of items, as well as a pre-resolver step for big-picture optimizations).

I plan to open source it in the coming weeks. Email me if you're interested and I will reach out when it's on GitHub.

Is it based on the graphql core next library?

I actually didn't know about this port, so no. It was originally built on graphql-core, but I found it difficult to use as a base for higher-level abstractions (not to mention it really is a 1-to-1 port of the JS lib and is thus incredibly un-Pythonic), so everything was written from scratch, including the parser. (Hence why it's not fully spec-compliant yet—a few GraphQL language features are still not implemented.)

Well,if that’s the case I’m very interested in it. I have been maintaining a private fork of graphene for a while, with a desire to improve performance but I’m stymied by having to go through graphql-core.

All the python graphql libraries are based on it, so your work is going to be very valuable I expect.

We have a public DRF api for third parties. But when creating our own, new, client app we found it easier to create a GrahpQL endpoint.

It was good, but comes with a lot of boilerplate. Then there is the learning curve of GrahphQL in the client. Also the bloated client with it's bucket of features (caching, etc).

We just tend to add GraphQL endpoints as we need. Found the best approach was to open the model, put in the GQL optimizer. Then when the client has settled, freeze the models by putting in some `only` settings to limit fields requested.

Yes, we're using graphene-django for our internal APIs and maintaining/exposing data through REST for public APIs via DRF. My colleague is looking at Ariadne.

Reply on news.ycombinator.com