Open frossi85 opened 4 years ago
Hey @frossi85 You ran into some limitations of custom types with Hasura.
Read more about custom types here.
However, not getting a valid feedback on an error is a bug, so I am rescoping this issue to return proper feedback when an error happens.
Thanks for the quick response, I did not get this:
For a more complicated structure, the object types can be connected to the rest of the graph via relationships.
I read the docs but not sure how that can be achieved with my current API. Are you suggesting that I split my API in 2, one for the root object, and other for the metadata object and then relate them in some way?
Also, the Hasura team has plans to implement Interfaces and Union types as custom types? If it is a yes, do you have an estimate like 2020 Q4 or some approx?
Also in cases like this, I think that having a way to define some mapping function in the actions to map API responses to the output type, plus cache over those API calls and relationships between Actions not only with a table will solve this issue without implementing that objects can contain objects.
How? In my example, I would create two actions calling the same API URL, in one I would define the type:
type Metadata {
ceo: String
headQuarters: String
foundedAt: Int
employees: Int
other: String
}
with a mapping function like this: response.map(x => x.metadata)
Then define another action with this type:
type Asset {
friendlyName: String!
description: String!
symbol: String!
type: AssetType!
logo: String
}
And then define a relationship from Asset to Metadata.
So if the cache is in place my API will be called just one time and I will be able to construct more advanced graphql schemas without changing my old API.
The idea to create a graphql server to overcome the limitations of Hasura goes against the philosophy of Hasura (at least si what I see that you are trying to do) of developing Graphql API as fast as u can without friction and with the ability of reuse old APIs that you already built.
I know you are doing the best guys and this is great but this is just an idea on how maybe you can enhance the product because mapping function will not help just in this scenario but in many other, like my old API use this casing in the response: { my_prop } but with Hasura we are trying to use this: { myProp } or the other way around.
I hope the feedback helps you to keep rocking it.
FYI, I have stumbled across this issue trying to use Actions to deliver results to Dart types (Flutter), using Artemis to code gen all the types based on the gql schema and queries. I'll have to rethink how to strongly type nested Actions outputs.
The somewhat cryptic error I get is the type "HourlyResult" of the field "hourlyResult" in the object type "Hourly" is object type which isn't allowed
any roadmap for implementing the feature?
@abdullah2993 as you can see, work had started in #5434 and it's been stalled at the moment. The changes on the console are done, and similar changes on the CLI were required. We will pick this up again, soon.
cc @beerose
@frossi85
And then define a relationship from Asset to Metadata.
According to docs you can define only relation between action and table, but not between 2 actions. Probably I missed something?
We need to make a response for an action.
And the response must contain a list of objects. But we get an error that the type of the field cannot be an object.
Hasura v 1.3.3
We found such a solution - use jsonb
type Response {
items: jsonb!
}
Also in cases like this, I think that having a way to define some mapping function in the actions to map API responses to the output type, plus cache over those API calls and relationships between Actions not only with a table will solve this issue without implementing that objects can contain objects.
How? In my example, I would create two actions calling the same API URL, in one I would define the type:
type Metadata { ceo: String headQuarters: String foundedAt: Int employees: Int other: String }
with a mapping function like this:
response.map(x => x.metadata)
Then define another action with this type:
type Asset { friendlyName: String! description: String! symbol: String! type: AssetType! logo: String }
And then define a relationship from Asset to Metadata.
So if the cache is in place my API will be called just one time and I will be able to construct more advanced graphql schemas without changing my old API.
The idea to create a graphql server to overcome the limitations of Hasura goes against the philosophy of Hasura (at least si what I see that you are trying to do) of developing Graphql API as fast as u can without friction and with the ability of reuse old APIs that you already built.
I know you are doing the best guys and this is great but this is just an idea on how maybe you can enhance the product because mapping function will not help just in this scenario but in many other, like my old API use this casing in the response: { my_prop } but with Hasura we are trying to use this: { myProp } or the other way around.
I hope the feedback helps you to keep rocking it.
did u fix that issue?
Gents, I have a service that will return a complex object as output, I need all those arrays of objects and other properties as objects to serve my front end. Without this feature I will have to make my front end do a call to this service to then call hasura with the returned data. actions without been able to do arrays of object types and object types as properties seem only to work when you don't need much data from other datasources
We found such a solution - use jsonb
type Response { items: jsonb! }
Having the same problem but yeah, using just jsonb solves it
Hi,
I am trying to create an action to call one of my rest endpoints but it seems that Hasura does not support fully GraphQL specs. Here is the action definition:
When I click on the Create button basically nothing is happening, there is not error or any feedback. So my guess was that probably union was not supported, even if it was part of GraphQL spec. So when I removed all the metadata related types and field the action was created. Then I tried to create just one metadata type with all optional types like this:
I got this error:
validation for the given custom types failed because the type "Metadata" of the field "metadata" in the object type "Asset" is object type which isn't allowed
Which is strange because GraphQl also supports it, and seems a really important feature to be able to a couple already implemented APIs with Hasura Action. The first issue while I would love to see it is not a real stopper but the seconds one it is.
So the question if these are bug or current limitations, and when you are planning to implement them if that is the case.
Thanks