strawberry-django-plus / relation to relay / response type

[blb-ventures]

strawberry-django-plus / relation to relay / response type

[bellini666]

Hey @gersmann ,

Although that is an edge case, it should not be hard to implement something like that. If you look at DjangoCreateMutationField for example, it basically inherits from the input mutation and calls the create resolver. You can inherit from it (or define your own function) and call the resolver by hand, and return a payload that has the model in a subfield. That would make it a union of OperationInfo (in cases where the error totally prevented the creation of the object), and your payload, which could contain other related stuff.

Maybe there's a way to add an api to integrate that to the CRUD mutations here without having to sacrifice the current simple support...

[bellini666]

Hey @gersmann , I'm really glad you liked it :)

1st: are CRUD mutations considered a relay only feature? because at the moment, even if the input type does not inherit from Node, the mutation expects a relay global ID.

It is because the auto field. I added a config that converts the pk to GlobalID instead of ID. It is True by default (https://github.com/blb-ventures/strawberry-django-plus/blob/master/strawberry_django_plus/settings.py#L29), but you can change it to use ID instead by setting STRAWBERRY_DJANGO_FIELDS_USE_GLOBAL_ID = False in your django settings.

My second question would be about the return type of mutations. If I am not mistaken, the Union Type between the Return Type and OperationInfo is a work around for the difficulty of defining a dynamic attribute name on a generic python class, right?
Have you considered adding a response attribute to the generated return type? I think that could be easier to deal with in a lot of client libraries than a union type, and it also allows to pass validation errors along with the updated object.

Yes, that is actually what I used to do with graphene. I got the idea of the union from the strawberry documentation (https://strawberry.rocks/docs/guides/errors#expected-errors) and thought it was better than having to the the response as Optional always because it could fail.

The frontend guys that I work with use apollo client + graphql-codegen to generate hooks and typescript types from the queries, it works really well! It should type the return type's __typename as the possibilities of the union, so if you check if (res?.data?.__typename === "OperationInfo") for example you can narrow res.data to the error type (the same for the other possibilities, like the success payload).

Does that work for you?

[gersmann]

Hi @bellini666

I have overlooked that config option, thank you for pointing it out, works like a charm.

About the second question, we are using graphql-codegen as well, and it would work as described by you. I was just thinking that checking for if (res.data.payload) would be easier on the eyes than if(res.data.__typename === "UserType"), but the second option also works, not a big issue.

The only remaining question / argument could be, that the GraphQL spec kind of recommends the ability to return partial results, in combination with error messages.

E.g. an 'address form', that does some kind of normalisation, the API could return an updated address and error messages to the client. We used that pattern in the past for a different very CRUD driven application we were building with graphql-ruby (which is awesome as well by the way ;))

[gersmann]

I guess that would be optimising for an edge case. I'll close this.