eminetto / clean-architecture-go

Clean Architecture sample
629 stars 92 forks source link

Doubts using gqlgen for graphql endpoint #9

Open frederikhors opened 4 years ago

frederikhors commented 4 years ago

@eminetto thanks for your project.

https://github.com/bxcodec/go-clean-arch is a similar one and I opened a PR (https://github.com/bxcodec/go-clean-arch/pull/39) for understand how to use https://github.com/99designs/gqlgen with Clean Architecture.

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,
}
eminetto commented 4 years ago

I didn’t create a graphql layer in my projects yet, but I probably would implement using the same idea you suggest. I see this as a new way to access the UseCases. As we have an api and a cli, i would create a graphql package to handle this kind of access.