Use Struct Field Resolver instead of Method #194

0xSalman · 2018-04-11T16:40:06Z

This fixes #28. Essentially, it reduces lot of boilerplate code by making use of struct field as resolvers instead of creating methods for each struct field.

Now, methods are required only when

a struct implements a GraphQL interface. In this case, you create methods for fields which overlap
a struct exposes a GraphQL field that accepts additional arguments i.e., first: Int, last: Int etc.
there is GraphQL union type

By using struct fields as resolvers, one could also benefit from DRY codebase by not having a pair of a struct which look the same (one for GraphQL and one for DB)

Does this break existing API?

No. This change is completely transparent and you can continue using your existing codebase.

Can I still continue using methods as resolvers?

Yes, by default, it uses method resolvers.

How can I use struct fields as resolvers?

When invoking graphql.ParseSchema() or graphql.MustParseSchema() to parse the schema, you pass in graphql.UseFieldResolvers() as an argument. For an example, take a look at ./example/social/server/server.go

Additional Notes

also fixes Allow returning string for an ID field? #124
for an example, take a look at ./example/social/social.go & ./example/social/server/server.go
Unit tests are missing

Use Struct Field Resolver instead of Method

0xSalman · 2018-04-11T16:41:55Z

@tonyghita, please take a look at this when you get a chance, thanks.

mytototo · 2018-04-18T22:04:27Z

Finally ! Thanks a lot @salmana1 this looks promising.
Any milestone to see support this officially out-of-the-box ?

Also updated `social.go` example

Handle parsing of `time.Time` type struct fields

Fixed bug to handle Union type

mbinge · 2018-04-25T00:54:26Z

please merge request!!!

0xSalman · 2018-05-08T15:57:29Z

@tonyghita any ETA on when you would have some time to review (and approve) this?

pavelnikolov

This is an awesome PR! Thank you very much 🎉
I'd would vote 👍 for this change!
However, it would be better if you submit unrelated changes in separate PRs. Please, submit a separate PRs for:

resolving IDs as strings (I'd vote 👎 )
<field_name>Resolver to be used if available (I'd vote 👎 )

Sending multiple changes in a single PR makes it much harder to review. Also, if someone doesn't agree with all of the changes, it would take a lot of time to get your PR merged.

Thanks again! 🥇 🏆

pavelnikolov · 2018-05-10T05:11:42Z

example/social/README.md

+
+To run this server
+
+`go ./example/field-resolvers/server/server.go`


Did you mean go run?

pavelnikolov · 2018-05-10T05:22:41Z

example/social/server/server.go

+
+func init() {
+	opts := []graphql.SchemaOpt{graphql.UseFieldResolvers(), graphql.MaxParallelism(20)}
+	schema = graphql.MustParseSchema(social.Schema, &social.Resolver{}, opts...)


(minor) Is there any reason for these to be in the init() func? They could easily be just live in a var( block or live in main().

pavelnikolov · 2018-05-10T05:23:18Z

example/social/social.go

+	type Query {
+		admin(id: ID!, role: Role = ADMIN): Admin!
+		user(id: ID!): User!
+        search(text: String!): [SearchResult]!


Fix indentation, please.

pavelnikolov · 2018-05-10T05:38:05Z

internal/exec/resolvable/resolvable.go

 	case *string:
-		implementsType = (t.Name == "String")
+		// allow ID of type string
+		implementsType = t.Name == "String" || t.Name == "ID"


This is unrelated change. Please, send a separate PR for it.

pavelnikolov · 2018-05-10T10:45:20Z

example/social/social.go

+}
+
+type user struct {
+	Id        string


Please, renameId -> ID.

pavelnikolov · 2018-05-10T11:20:13Z

internal/exec/resolvable/resolvable.go

-func (b *execBuilder) makeObjectExec(typeName string, fields schema.FieldList, possibleTypes []*schema.Object, nonNull bool, resolverType reflect.Type) (*Object, error) {
+func (b *execBuilder) makeObjectExec(typeName string, fields schema.FieldList, possibleTypes []*schema.Object,
+	nonNull bool, resolverType reflect.Type) (*Object, error) {
+


Please, remove empty line.

pavelnikolov · 2018-05-10T11:28:06Z

internal/exec/resolvable/resolvable.go

+		// 	1.2) Or field has arguments
+		//	1.3) Or it is configured to use method
+		//	1.4) Or it is an interface
+		// 2) Otherwise use resolver type's field


Please, reformat the comment as:

// 1. Use method resolver when: // a. __Type and __Schema requests; or // b. The requested field has arguments; or // c. The schema is not configured to use field resolvers; or // d. It is an interface // 2. Otherwise, use a field resolver

pavelnikolov · 2018-05-10T11:34:21Z

internal/exec/resolvable/resolvable.go

+		//	1.4) Or it is an interface
+		// 2) Otherwise use resolver type's field
+		if isResolverSchemaOrType(rt) == true || len(f.Args) > 0 ||
+			b.schema.UseFieldResolvers == false || rt.Kind() == reflect.Interface {


UseFieldResolver is already a boolean, right? Can't you just use !b.schema.UseFieldResolvers? Or you want it to be more verbose?

imho, ! can be overlooked sometime so more verbose make it clear that it's a check for false. I can change this to !

I prefer using ! because it'll be consistent with the rest of the code in this library.

pavelnikolov · 2018-05-10T11:41:27Z

internal/exec/resolvable/resolvable.go

-		}
-		if err := b.assignExec(&a.TypeExec, impl, resolverType.Method(methodIndex).Type.Out(0)); err != nil {
-			return nil, err
+	if b.schema.UseFieldResolvers == false || resolverType.Kind() != reflect.Interface {


again <bool> == false vs !<bool? Do we want the more verbose version? IMHO, it's better to use !...

pavelnikolov · 2018-05-10T11:49:14Z

internal/exec/resolvable/resolvable.go

 func findMethod(t reflect.Type, name string) int {
+	resName := name + "Resolver"


This is completely unrelated change (i.e. finding method with name <field>Resolver). Please, send this in a separate PR. I'd personally, vote 👎 for this specific change, since adds unnecessary complexity to the library. Less is more in this case.

This is not an unrelated change. As mentioned in the PR notes, when a struct implements an interface, then struct's resolver methods are used for each interface field. Hence, when a struct has a field Email and interface has the same field, then there will be a conflict between struct field and resolver method. So a Resolver suffix can be used to resolve that conflict. If you can suggest something else to achieve the same goal then I will be happy to implement that

As a workaround you can just use different struct fields. If you are implementing an interface, it's just the methods that will be used, right? This would mean that you can use differnt field names.

pavelnikolov · 2018-05-10T12:01:32Z

@tonyghita, please, review this change as it is opt-in and would save us from writing a lot of boilerplate code. 🎉 🆒 😎 👍 ❤️

I'm curious to see the benchmark comparison between the field and method resolvers. 📈 📉 📊

pavelnikolov · 2018-05-10T12:45:34Z

@neelance, is this getting a step closer to what you suggested in #88 (comment) or is it a move in a different direction?

0xSalman · 2018-05-14T16:54:15Z

@pavelnikolov thanks for reviewing the code and I will fix most of them.

I totally understand what you are saying about multiple PRs. Please note that, this PR is coming from downsteam master branch which has bunch of fixes and we needed them for our usecase. I do not have the permission to change dowstream branch so I will try to do some git magic to avoid multiple things in this PR.

resolving IDs as strings (I'd vote 👎 )

I think this is useful change and it's working well for my company. We don't have to wrap or unwrap graphql.ID to string every time. But I can create a separate PR for it.

<field_name>Resolver to be used if available (I'd vote 👎 )

This is relevant to this PR and I have replied to your review comment

pavelnikolov · 2018-05-15T11:45:48Z

This is relevant to this PR and I have replied to your review comment

I'm still not 100% convinced that this is necessary. You can definitely change the field names in the struct or use a different struct and still implement an interface. I think that it should live in a separate PR.

pavelnikolov · 2018-05-16T08:06:34Z

I'll create a test schema and will run benchmarks comparing the master branch against your branch with both fields and methods

spiffyjr · 2018-06-23T00:19:35Z

Can this get some attention? This is pretty handy for reducing the amount of boilerplate needed.

iamtakingiteasy · 2018-08-15T12:18:52Z

+1, This feature would be very practical.

eveld · 2018-08-22T08:40:11Z

In large applications this would take away a lot of boilerplate code. Is there anything that still needs to happen for this to be merged?

pavelnikolov · 2018-08-22T22:32:41Z

@tonyghita is this in your roadmap? Any feedback about this PR?

marcinwyszynski · 2018-09-03T10:10:42Z

Thanks for working on that @salmana1 ! 🙇🏼‍♂️

ppwfx · 2018-10-06T12:25:52Z

push

pavelnikolov · 2018-10-08T00:36:23Z

@salmana1

I totally understand what you are saying about multiple PRs. Please note that, this PR is coming from downsteam master branch which has bunch of fixes and we needed them for our usecase. I do not have the permission to change dowstream branch so I will try to do some git magic to avoid multiple things in this PR.

I'd be happy to consider the struct field resolvers once you split this PR.

bazaglia · 2018-10-09T22:04:48Z

+1!!

This is a must-have for reducing drastically the codebase.

pavelnikolov · 2018-10-10T22:37:06Z

@salmana1 are you willing to split this PR? I'd be happy to review/merge the field resolvers.

bazaglia · 2018-10-11T01:35:37Z

@salmana1 Let me know if you need any help.

Also, when passing graphql.UseFieldResolvers(), it ALWAYS uses the value from struct, except in the cases you described (like a field has arguments). What I expected was to use the struct value only if fieldResolver doesn't exists. Is that possible at all with the current implementation?

pavelnikolov · 2018-10-11T02:28:14Z

@bazaglia Thanks for the feedback. Any feedback is highly appreciated! Can you please add some samples / unit-tests?

bazaglia · 2018-10-11T20:25:20Z

@pavelnikolov I don't have enough Go experience to write unit tests. I just tested the functional part of the PR, and it worked really well, resulting in much cleaner code. My only consideration is the way it's currently implemented, it looks like the developer has to choose OR to use struct fields as resolver OR to use the methods as the resolver (which is the standard in current graphql-go).

My suggestion is to go for a hybrid approach: resolve data from the struct value, which is the default way, but also allows to override the struct value, using a method to do it. This approach is also really close to graphql-js implementation: there's a default resolver, which is the value of the field from struct, but also allows implementing a function, to set the resolver.

I really wish I had experience with Go to help with this functionality, I think this PR is so great as it makes the code much more legible & readable.

0xSalman · 2018-10-12T19:11:15Z

Sorry for not replying sooner.

I will try to update this PR soon. I don't have access to the original forked branch; so, I will probably have to close this PR and recreate it.

On a separate note, I would recommend to take a look at gqlgen library. At my last job, we switched to that library after we realized this library was not actively developed and PRs weren't getting merged.

pavelnikolov · 2018-10-13T11:02:30Z

Thanks for your contribution, it is highly appreciated!
This project is now actively maintained again and PRs/issues are responded promptly.

P.S. It might take a wile until all existing issues and PRs are cleaned up. Thank you all for your patience. The current priority is subscriptions...

tobstarr · 2018-10-25T16:45:24Z

I would really like to see this PR getting merged!

pavelnikolov · 2018-10-28T23:48:43Z

@tobstarr I am thinking of an implementation that would keep the current method implementation as default but would allow the users of the library to override the resolving implementation as they see fit. I'll post an update soon. Chances are that this PR will not be merged in its current form.

bazaglia · 2018-10-29T00:03:59Z

@pavelnikolov nice, that's my upvote also, just like I commented before.

0xSalman · 2018-10-30T03:03:31Z

I will be pushing out a cleaned up PR tomorrow and will close this PR.

@bazaglia

Your suggestion is really good and I am happy to discuss it with you guys in detail.

0xSalman · 2018-10-30T13:29:40Z

Closing this PR - please see the new PR #282

Salman Ahmad and others added 3 commits April 11, 2018 12:30

Use struct fields as resolvers instead of methods (graph-gophers#28)

95f2b85

Addex example and fixed bugs

de4e1e1

Merge pull request #1 from DealTap/impl-field-resolver

2fcff20

Use Struct Field Resolver instead of Method

Salman Ahmad and others added 4 commits April 20, 2018 01:23

Handle parsing of time.Time type struct fields

4946780

Also updated `social.go` example

Merge pull request #3 from DealTap/handle-go-time

c869a3d

Handle parsing of `time.Time` type struct fields

Union types are not handled when using field resolvers

3c3c15b

Merge pull request #4 from DealTap/bug-union-type

de6fb84

Fixed bug to handle Union type

pavelnikolov requested changes May 10, 2018

View reviewed changes

pavelnikolov mentioned this pull request Jun 27, 2018

add GetFieldName Support #220

Closed

pavelnikolov added help wanted and removed help wanted labels Oct 13, 2018

0xSalman mentioned this pull request Oct 30, 2018

Use Struct Field Resolver instead of Method #282

Merged

0xSalman closed this Oct 30, 2018

mjarkk mentioned this pull request Nov 26, 2019

(docs) graph-gophers now supports Struct Field resolving 99designs/gqlgen#939

Merged

2 tasks


		To run this server

		`go ./example/field-resolvers/server/server.go`

		func findMethod(t reflect.Type, name string) int {
		resName := name + "Resolver"

Use Struct Field Resolver instead of Method #194

Use Struct Field Resolver instead of Method #194

Conversation

0xSalman commented Apr 11, 2018

Does this break existing API?

Can I still continue using methods as resolvers?

How can I use struct fields as resolvers?

Additional Notes

0xSalman commented Apr 11, 2018

mytototo commented Apr 18, 2018

mbinge commented Apr 25, 2018

0xSalman commented May 8, 2018

pavelnikolov left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavelnikolov May 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pavelnikolov commented May 10, 2018 • edited Loading

pavelnikolov commented May 10, 2018 • edited Loading

0xSalman commented May 14, 2018

pavelnikolov commented May 15, 2018

pavelnikolov commented May 16, 2018

spiffyjr commented Jun 23, 2018

iamtakingiteasy commented Aug 15, 2018

eveld commented Aug 22, 2018

pavelnikolov commented Aug 22, 2018

marcinwyszynski commented Sep 3, 2018

ppwfx commented Oct 6, 2018

pavelnikolov commented Oct 8, 2018 • edited Loading

bazaglia commented Oct 9, 2018

pavelnikolov commented Oct 10, 2018

bazaglia commented Oct 11, 2018

pavelnikolov commented Oct 11, 2018

bazaglia commented Oct 11, 2018 • edited Loading

0xSalman commented Oct 12, 2018 • edited Loading

pavelnikolov commented Oct 13, 2018 • edited Loading

tobstarr commented Oct 25, 2018

pavelnikolov commented Oct 28, 2018

bazaglia commented Oct 29, 2018

0xSalman commented Oct 30, 2018 • edited Loading

0xSalman commented Oct 30, 2018

pavelnikolov left a comment •

edited

Loading

pavelnikolov May 10, 2018 •

edited

Loading

pavelnikolov commented May 10, 2018 •

edited

Loading

pavelnikolov commented May 10, 2018 •

edited

Loading

pavelnikolov commented Oct 8, 2018 •

edited

Loading

bazaglia commented Oct 11, 2018 •

edited

Loading

0xSalman commented Oct 12, 2018 •

edited

Loading

pavelnikolov commented Oct 13, 2018 •

edited

Loading

0xSalman commented Oct 30, 2018 •

edited

Loading