[BerislavLopac]

Have you tried Graphene? [1] I haven't, but have read its documentation a lot, and it looks quite powerful.

I'm not happy that it introduces yet another data object library, but at least it's possible to build plugins for existing ones -- SQLAlchemy and Django are already there, and it would be nice to add ones for attrs, Schematics and of course the 3.7 native data classes.

Regarding the popularity of REST -- even if it wasn't intended for CRUD originally, it fits perfectly with that paradigm, and I think this is why many people were able to implement it easily when they started using it.

[1] http://graphene-python.org/

[somada141]

I've actually worked with both Graphene and Graphene-SQLAlchemy a fair bit. Honestly I found that the documentation , albeit well-written, was insufficient (especially for the SQLAlchemy extension). That being said, having to expose an SQLAlchemy ORM via Graphene did not lead to much code-duplication as much of the ORM is automatically accounted-for in the GraphQL schema (there's a fair bit of duplication when it comes to mutations but I reckon that's just a matter of someone doing the work in the extension).

Moreover, the community around it in both its GitHub and StackOverflow isn't as active as the equivalent GraphQL communities in other languages/ecosystems.

All in all I believe that increased adoption of GraphQL will lead to even better tooling and I'm sincerely hoping it'll catch on :).

My primary 'beef' with REST has always been the "10 ways to do 1 thing" especially when it comes to less standardised features like pagination, type-definition/validation, etc. GraphQL introducing some of these things out-of-the-box would hopefully reduce the comfort-zone-based bikeshedding that comes with any new REST API being developed.