Is it a waste when we scan from db into struct? about fastgql HOT 4 CLOSED

That looks cool, although I am against a fork, since we need to update against upstream changes always and maintain it.

Another caveat which makes me prefer the typed version, is if you have children logical resolvers, it won't work since they would require a u *model.User for the child resolver.

from fastgql.

In theory yes, but because the SDL expects a User model the gqlgen signature must be of type []*model.User. I am not sure if changing the signature on the resolver end will work with gqlgen since its main appeal is the types rather than working with interface{}.

I can give it a small research and play with it, but I am not sure if this optimization is worthwhile. The idea around the resolver functions is that you can change it and regenerate and it will keep your original implementation so you manipulate the data more after you resolved it from the DB, and its much nicer to work with types rather than interface{}

from fastgql.

@roneli I think we can ask for API change like:

opCtx := graphql.GetOperationContext(ctx)
opCtx.SetRawResponse(data) // data can be interface{} raw data from db without marshal waste
return nil, nil // no need to return data here as it has been set in raw response, the code will compile well

Then when execute the operation, it can check if it has raw response then use it to return json.
With this API change, it still works if you need to marshal data

PS: I found a way to do that but may need to fork and change some lines in the gqlgen lib:

graphql.GetFieldContext(ctx).Result = data

from fastgql.

Yeah you are right.
Btw do you know the lib join-monster on nodejs? It has the same idea with your lib, which turns graphql field selection into sql query. I think we can learn some from it to apply to your lib

from fastgql.