join-monster VS pycon-graphql

GraphQL could be efficiently translated into SQL and things certainly try, but the only thing close to a "bulletproof" implementation I found was Join Monster (https://github.com/join-monster/join-monster) in NodeJS-land and even that I think is now mostly abandoned. GraphQL as a system was built assuming random-access to data stores is ~free because that's what Facebook has, but the rest of us don't :)

REST is not a strict specification and it's not a single implementation, you can just start doing it.

That said, I wouldn't recommend going the allow everything flexible resolver way like GraphQL: it's terrible for performance (eg. most APIs use N+1 queries unless you have something like https://github.com/join-monster/join-monster), the complexity of the codebase skyrockets and having to specify all the fields you want is not exactly ergonomic in most situations.

I just got done doing a talk on GraphQL for PyCon2022 and I do agree with some of the points here. Performance work can be tedious and is not bi-directional in the graph so the number of dataloaders can blow up making debugging hard. Identifying where n+1 queries are in the API can also be difficult, but I used this open source package to help: https://github.com/tatari-tv/query-counter. I think the article failed to mention two of the things that GraphQL does really well: dense queries and built-in pagination. You're able to do the work of many serialized REST queries in one query using the node context of the GraphQL graph structure, which is a huge win if you're hitting performance issues related to requests per second to your API. Also pagination using the cursor, before/after, etc. is very helpful and Flask_Graphene enables some slick caching there to make subsequent queries at that cursor to be extremely performant. I have code with my sample implementation which simple, but shows the power of DataLoaders: https://github.com/lame/pycon-graphql.