Doubts using gqlgen for graphql endpoint

[frederikhors]

I'm trying to use the amazing GqlGen (https://github.com/99designs/gqlgen) with your amazing project (thanks again for your work).

I created a PR (https://github.com/bxcodec/go-clean-arch/pull/39) for this integration (which you should not accept, it was a mistake: I just wanted to link here my forked branch!).

Is gqlgen in this case just a "third party" delivery layer?

I don't know if I'm doing this well: I'm using just graphql dir in root!

Because - as you can see - code is generated I can just inject usecases in main.go for the graphql.Resolver{}:

e.POST("graphql", echo.WrapHandler(handler.GraphQL(graphql.NewExecutableSchema(graphql.Config{Resolvers: &graphql.Resolver{
    ArticleUsecase: au,
    // <--- other usecases here --->
}}))))

and I use that usecases in resolver.go:

func (r *queryResolver) Articles(ctx context.Context) ([]*models.Article, error) {
    articles, _, err := r.ArticleUsecase.Fetch(ctx, "cursor", 1) // <--- example values because I don't want to change Usecase now
    return articles, err
}

What do you think about?

1. Am I respecting the principles of "clean architecture"?

2. Is there a more elegant solution?

---

A more extensive example of gqlgen in action can be found here: https://github.com/oshalygin/gqlgen-pg-todo-example. As you can see he's injecting db *pg.DB in main.go file for

Resolvers: &resolvers.Resolver{
    DB: db,
}

[bxcodec]

Hey @frederikhors so sorry for the really late response. Tough times back then. I'm back and alive now.

Yes, this way is already better. The core logic is already encapsulated in usecease/service layer. The idea is to keep them loose coupling; you did a great job there.

I'm closing this issue for cleanness' sake. Let's have a proper discussion on Linkedin/Twitter or directly to my email.

Thanks