Just wondering if there are any examples that show the directory structure people are using in production? I'm implementing this in a new app using chi router (first time I'm using chi as well as setting up a graphql server). the database I'm using is mongo so I'll need to save those mongo queries/models/etc. as well. Any recommended reading or examples on directory structure would be appreciated!
One way I tried to structure a graphql project is that I have 3 bigger packages, let's say db, models and resolvers.
db has a bunch of subpackages, and each subpackage is for a resource type/group, like posts handles all the queries/scripts that queries for a posts or update them or whatever... For example:
|- users
|- posts
|- comments
In the db package I had a Client structure which had all the subpackages in itself, so a query for posts was accessible with something like this client.Posts.All(ctx), or the comments for a post with the following client.Comments.GetCommentsForPost(ctx, postID). With this structure, I was able to initialize my database client once and in a fast way. And it was clear that in which folder should I start looking for a query for Posts.
models package stores all the models you want to use in the database queries and resolvers, all in one place.
resolvers package's structure is like db it has a bunch of subpackages too, and each one is responsible for one resource type/group. Like posts has all the types, mutations and queries that are for the Posts.
Looks like this:
|- users
|- posts
|- comments
In the root of the resolvers package, I had my schema definition. Again, I enjoyed the benefit that I knew where to find something and would be clear for anyone else where they should start looking for it.
I used and still using this structure in a project, helps me and others to have a clear structure. There're probably better ways to use, there always be.
Most helpful comment
One way I tried to structure a graphql project is that I have 3 bigger packages, let's say
db,modelsandresolvers.dbhas a bunch of subpackages, and each subpackage is for a resource type/group, likepostshandles all the queries/scripts that queries for a posts or update them or whatever...For example:
In the
dbpackage I had aClientstructure which had all the subpackages in itself, so a query for posts was accessible with something like thisclient.Posts.All(ctx), or the comments for a post with the followingclient.Comments.GetCommentsForPost(ctx, postID). With this structure, I was able to initialize my database client once and in a fast way. And it was clear that in which folder should I start looking for a query for Posts.modelspackage stores all the models you want to use in the database queries and resolvers, all in one place.resolverspackage's structure is likedbit has a bunch of subpackages too, and each one is responsible for one resource type/group. Likepostshas all the types, mutations and queries that are for the Posts.Looks like this:
In the root of the
resolverspackage, I had my schema definition. Again, I enjoyed the benefit that I knew where to find something and would be clear for anyone else where they should start looking for it.I used and still using this structure in a project, helps me and others to have a clear structure. There're probably better ways to use, there always be.