Hi, I am Shohan, from India, currently in second year of my undergraduate course
I was going through the project ideas listed and saw the one involving graphql. I have worked with graphene and django-graphene before. Does this project aim to integrate those two into django, or adopt those functionalities into ‘native’ django?
The project idea is more of a starting point - we’d expect you to think about how best to implement it. We’ll be looking for two main things:
A clear idea of the design you are going for, and why it is useful to Django. For GraphQL, this is particularly important as it’s quite a new concept, and there’s a chance we might not want it at all the way it’s proposed. It should have an idea of the API design and make sure it matches other Django conventions for settings, instantiation, and so on.
Clear technical understanding of the work involved, with a summary of what you believe needs to be done, a rough timeline, and what you think will be the most difficult parts.
It’s your call if you think it makes more sense to do it into “native” Django or if you want to somehow bring third-party projects closer, but we’ll want to see reasoning either way that shows why you think it is the best idea!
Hi, I am Yash Saini, currently a third year student of undergraduate course.
Hi! Hope this is the correct space to discuss any queries/ideads regarding this project.
So first thing first, I remeber when the project ideas were first being discussed on the mailing list, this particular project was described as ludicious. Was it because of its size/complexity (tbh I find it pretty exciting though)? Particulary, will that have an effect on this project getting selected?
Now, lately I have been reading a lot about GraphQL and other libraries that implement this; especially graphql.org and apollo were really helpful. The toughest thing I am facing right now is to gauge the width of this project because I haven’t worked on a project of this size before. Nonetheless, what I got so far was that mostly everyone is parsing the incoming graphQL styled queries into a syntax abstract tree. This AST is then run against an existing schema for validation and if validated, we pick up the fields requested in the query and format it into a nice result. I haven’t worked with AST’s before so that’s what I am looking into and how other libraries have implemented them.
One big question for which I am searching an answer for is, how should we be implementing the schema itself. While graphene does that natively in Python, I find it a big plus to be able to store the schema seprately and then be able to parse it into python later. This could be really helpful as then the frontend and backend teams could work almost independently, given the common schema file(s). However, I am worried about how will this turn when the schema grows in size and complexity. On the other hand, since we are going to write the resolvers in Python anyways, we might as well bind the schema with it. This will also cut down other work, say parsing the schema and ensuring it is in sync with our resolvers. So if someone could share their experience/advice, it’ll be really grateful.
One last thing, as the idea page itself states, given that Django REST is seperate, and also that it would very much be a bold step to build the support directly into the django core, I am thinking of keeping it seperate just like Django REST.
The ideas above are mostly the result of my brain dumping from last couple of days, so I do realize they aren’t well framed. But I do realize that it would be meaningless to simply submit a proposal without a general consent of the community and hence I thought of posting it here. Any other advice or headstarts, or something that I might totally be missing would be really awesome 
Cheers, and have a nice day!