Is it OK to have extra custom logic on a graphql (input) type?

[dimitarizpitaime]

In our project we have a RoR GraphQL API.

In our mutations what we do right now is we take the incoming arguments, in the resolve method we transform them into a pure hash (nested if needed) and pass them on to the many service objects we have to do their business.

I guess we do that for 2 main reasons: 1 - once the project was an MVC rails project and so hash arguments were I guess the thing , 2 - everybody is comfortable using hashes, they are easy and straightforward to use

But some time ago we started playing around with the idea to use the input type objects graphql provides instead of always transforming them into hashes. This was we don't have to "prepare" the incoming arguments, but also we can have some logic in the graphql classes that makes sense to be there.

This is an example of what we do now / are talking about doing: (We are using Rails 6.1.3.2, ruby 2.7.2, graphql 1.9.11 - updating right now to 1.12.24)

Mutation: ...

argument :items, [Types::ItemInputType], required: true
argument :payment_info, Types::PaymentInfoInputType, required: true
argument :privacy, String, required: false

def resolve(args)
  options = build_options(args)
  .... pass the options on to services ...
end

def build_options(args)
  {
    items: args[:items].map(&:to_h),
    payment_info: args[:payment_info].to_h,
    privacy: args[:privacy]
  }
  ... some complex transformations here as well ...
end

The PaymentInfoInputType for example is:

argument :name, Enums::NameEnum, required: true
argument :size, Int, required: false

The ItemInputType for example is:

argument :count, Int, required: true

And later in the services we have all the inputs nicely prepared to use, we can easily do for example:

payment_info_attributes = options[:payment_info]
payment_info_attributes[:some_extra_attr] = payment_info_attributes[:size].present? ? 'some_value' : 'some_other_value'
PaymentInfo.create(payment_info_attributes)

The build_options (mutation, services,..) is way more complex than the example but it's just for an idea.

Let's say we want to start using the input object themselves, then for example we will have no building of the options, so:

Mutation:

def resolve(args)
  .... pass the args straight on to services ...
end

The PaymentInfoInputType for example will be:

argument :name, Enums::NameEnum, required: true
argument :size, Int, required: false

def some_extra_attr
  size.present? ? 'some_value' : 'some_other_value'
end

Then we'll have in the service:

payment_info_attributes = options[:payment_info].to_h
payment_info_attributes[:some_extra_attr] = options[:payment_info].some_extra_attr
PaymentInfo.create(payment_info_attributes)

The difference is not at all much in this simple example, but for us our mutations will become really slim after this change. Also some logic that is spread across the services just because, can be put inside the input object (when it makes sense). We can access the argument in the input objects as methods, instead of as hashes (some prefer this way).

My questions are: Does this make sense to do, is it ok to have some logic in the graphql input object classes, is it a better pattern NOT to build and use hashes, or is it somehow an anti pattern? Any thoughts are appreciated