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.
@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
inmain.go
for thegraphql.Resolver{}
:and I use that usecases in
resolver.go
:What do you think about?
Am I respecting the principles of "clean architecture"?
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
inmain.go
file for