[didericis]

I was familiar with GraphQL before integrating it into a Django project, so my experience may differ, but I had a good experience using graphene: https://docs.graphene-python.org/projects/django/en/latest/t...

Since efficient querying is a concern, I highly recommend just biting the bullet. It's extremely easy to underestimate the complexity of caching state on the frontend and to end up accumulating an unmaintainable frontend state management situation. It's totally possible to do what OP suggested without running in to those kinds of issues, but typically that involves more frequent fetching from the server.

It depends how quickly you need to make the prototype/whether you'd be willing to refactor it/how efficient the querying really needs to be/whether you think you can keep state management simple and structured enough to avoid it ballooning/how quickly you think you can grok the basics of GraphQL/etc. Apollo doesn't really care what your schema looks like, unlike relay, so the learning curve isn't as steep. When I picked up GraphQL/Apollo for the first time the terminology felt pretty obtuse, but once the basic idea clicked it felt pretty natural. Most of the devs I've worked with have had similar experiences.

[gitrog]

I'd like to get the prototype out quickly, and then there will probably be quite a bit of time before the final product is launched.

Things like this worry me about getting up and running with GraphQL though, especially "Common GraphQL problems: Server/Client Data Mismatch":

https://www.freecodecamp.org/news/five-common-problems-in-gr...

[didericis]

Out of all those problems I'd say the most difficult one to tackle is related to performance, but if it's an api that only you are hitting, you can usually avoid doing anything too costly.

The recommended solution of using graphql on the server for the server/client data mismatch problem is a good one, but it's not really applicable in your case. That's geared towards people using both javascript and nodejs. If you're using javascript on the frontend and python on the backend, you can't share code/there's inevitably going to be a mismatch. A mismatch isn't always a bad thing, either; often you don't need to expose all of the database models to the client, and want a lighter weight abstraction.