Graphql: directory structure/organization

Created on 27 Mar 2019  路  1Comment  路  Source: graphql-go/graphql

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!

Most helpful comment

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.

>All comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jiharal picture jiharal  路  5Comments

Fruchtgummi picture Fruchtgummi  路  4Comments

titanous picture titanous  路  3Comments

zbintliff picture zbintliff  路  3Comments

FrontMage picture FrontMage  路  5Comments