Closed fjtirado closed 2 months ago
@gmunozfe FYI
After careful reviewing the specification, I do not think it makes sense to implement it. The specification, as written in 0.8, force a user that is already fluent with graphql and probably knows which query he should invoke to split it into three different parts (the operation, where he specifies operation type and schema type; the function ref argument, where he specifies the filter part of the query; and the function ref selection set, which contains the selection part of the query ), just for the implementation to rebuild the query from that information. I think it will be easier for this kind of graphql fluent user to directly use custom rest functions
This spec example can be modelled in the following way.
In the workflow definition, user has to defines the graphql rest function (with the path to the graphql endpoint and post as method)
"functions": [
{
"name": "graphQLQuery",
"type": "custom",
"operation": "rest:post:/pets/graphql"
}
]
and the graphql function invocation (passing the graphql query he wish)
{
"name": "getPetId42",
"functionRef": {
"refName": "graphQLQuery",
"arguments": {
"query" : " { pet (id: 42) { id name favoriteTreat { id } }}"
}
}
}
In application properties he will define the graphql host
kogito.sw.functions.graphQLQuery.host=https://example.com
Add support for https://github.com/serverlessworkflow/specification/blob/0.8.x/specification.md#using-functions-for-graphql-service-invocations to kogito-runtimes