actions: Allow to reuse already existing types

[xzilja]

Current Behaviour

We have to explicitly define action types for inputs and outputs, even if we are returning types that already exist (i.e. want to return characters type associated to already existing characters table, yet have to type it all out manually in action as a new type).

This creates few barriers, especially when we have to type out larger responses. It creates a lot of duplicate types, which get in the way when using tools like https://graphql-code-generator.com
And makes it really hard to work with typescript, where it expects some values to be of enum type, but we can't re-use enums in actions (See #4513)

Right now this is a single peace of functionality in hasura (at least for our team) that requires a lot of manual work / workarounds to get them working correctly with typescript and apolo cache (apollo cache doesn't get updated correctly as actions don't return existing types we use with queries for example).

Right now editing / deleting custom types doesn't update hasura's hdb_custom_types correctly as well, making this issue of "a lot of unnecessary types" even worse (See #4967)

Doing so with approach described here https://hasura.io/docs/1.0/graphql/manual/actions/reuse-types-actions.html is viable, but perhaps a simpler method where we just define return types would be better?

Expected Behaviour

Actions should allow access to all types that already exist in our graphql schema (those generated when we create tables / enums etc...). We should be able to create actions without defining any custom types if action output uses already existing type (i.e. see characters example above). When "Derive Action" option is clicked from Graphiql, generated action should reuse types from the code we typed out in Graphiql instead of creating it's own custom types. Generated action schema should have correctly inherited __typename fields, so if it returns an existing type it will work correctly with tools like apollo cache.

I am not sure about this one, but it would add to dev experience if we could get type auto completion in actions text fields as well.

[katya450]

Not sure if I should open another ticket about my problem, but as it seems to be quite similar with this one, I'll just comment here (stressing the importance of this while ticket doing so :) )

I have a (derived) action like this:

Type Mutation {
  InsertStuff (
    name: String
    type: MyTypesEnum
    colors: SelectedColors
): InsertStuffOutput
}

My issue is with the "type" and "colors" -field types.

I already have "type" defined in Hasura as an enum-table, and Hasura has auto-generated a type of it; "hasura_stuff_types_enum". I have similar auto-generated Hasura-type defined for colors, which is a list of objects; "[hasura_stuff_colors_insert_input]".

Now, when I try to use these existing, auto-generated types as my action's input types, they get not accepted as they are not defined in custom types.

It works if I re-define the same things as MyTypeEnum and SelectedColors in the Action console Types definition - but I'm having really hard time believing that this is the wanted and proper way to do this, because Hasura should already know these types. As my mutation is really much larger than this example I wrote, the action would create over 2000 lines of custom types required by this, some of which are enums already once defined in the schema.

Like mentioned above, there is a Hasura manual page about re-using existing types, but that seems to work only with output-types. My issue is with the input-types.

[pacwoodson]

Up ! This becomes really problematic with typescript, not to say that defining the same enum in different places is bad design.

[jjangga0214]

In my humble opinion,

• Cool

  Actions should allow access to all types that already exist - @iljadaderko

  => Not forced to rely on Relationship.

• Necessary

  Like mentioned above, there is a Hasura manual page about re-using existing types, but that seems to work only with output-types. My issue is with the input-types. - @katya450

  => Existing types as input, especially for enum in practical.

I guess the limit is introduced by technical uncertainty.

For instance, what should be done when existing types 'directly'(not depending on Relationship) used in action schema are modified or deleted? Should action be cascaded, or the change restricted?

For another example, for existing types directly used by actions, is it enough for an action handler to respond with just pk?

Current

type MyCustomType {
  fooId: String!
  # foo: Foo! # This will be dynamically created by Hasura by Relationship, if you set.
  bar: Int!
}

Expected

type MyCustomType {
  foo: Foo!
  bar: Int!
}

And action handler can return pk only, similar to the way Apollo Federation works?

{
  "foo": {
    "id": "helloworld" // This is pk.
     // foo's other fields are automatically queried by Hasura, if a client requests.
     // Action handler does not have to do that.
  },
  "bar": 123
}

There are a few things to decide first, and I feel the issue can be resolved, at least it looks far from being impossible.

[rfieve]

Up !
Manually duplicating types representing the same entities is indeed error-prone and introduces unnecessary overhead.
Allowing actions input types to consume enums from the schema is required to maintain a single source of truth regarding typing.

[omieliekh]

Upvoting for this one. I'm trying to setup custom Action with Metadata Config v2.

I expect that adding new mutation should be as straightforward as this

# metadata/actions.graphql

type Mutation {
  insert_users_one_custom(object: residents_insert_input): users
}

# metadata/actions.yaml

actions:
  - name: insert_users_one_custom
    definition:
      kind: synchronous
      handler: '{{ACTION_BASE_URL}}/insert_users_one_custom' # custom route that's defined separately
      forward_client_headers: true
custom_types:
  enums: []
  input_objects: []
  objects: []
  scalars: []

Where

• insert_users_one_custom : our custom mutation (and insert_users_one is existing one that we are trying to wrap with custom functionality)
• residents_insert_input : existing input
• users : existing type

But looks like it's not possible to do with current setup 😕

[MarkNBroadhead]

When attempting to use an existing input object, the following error message reason is produced:
"Inconsistent object: in action "myAction"; the type: "user_set_input" is not defined in custom types or it is not a scalar/enum/input_object"
If this takes a while to fix, I would suggest changing the error message to include: "the type "user_set_input" must be defined in custom types and be of type scalar, enum, or input_object"

[joelbqz]

I wish this could be implemented soon 😢 I'm facing an issue where I have a large table of 60+ columns, then I'm using an insert_ mutation but I need to validate some data with other services, then it becomes a mess of custom duplicated types when tried to derivate into an action.