How to use a Apollo GraphQL query result as the input of another one? Aka: request chaining - graphql

I know this has been asked a couple of times before, but I have found no definitive solution to whether this is possible with GraphQL. And I have a strong feeling this should be possible as it should be relatively easy to implement due to GraphQL queries running sequentially in Apollo.
I have a situation where I'm doing a GraphQL mutation first on the client, and then immediately after doing a query which uses the results from the previous query. This causes a needlessly long response time waiting for the server to respond to both requests. The requests look like this:
mutation createWebSession($authId: ID!) {
webSession: createWebSession(authId: $authId) {
token
userId
}
}
query listUserPaymentMethods($userId: ID!) {
userPaymentMethods: paymentMethods(userId: $userId) {
id
}
}
I know that one simple band-aid solution to avoid making 2 round trips to the server is creating a new single GraphQL mutation endpoint that does both services on the back end. But that seems to defeat the purpose of writing modular, reusable GraphQL endpoints. As such, I'm curious if someone knows if Apollo GraphQL supports a cleaner way to chain 2 requests in which the results from the previous one are available to the next one as inputs.
Any help would be greatly appreciated, thanks.

This is a limitation that specific to GraphQL in general. There is no way to do this in a single request for a couple of reasons:
While a GraphQL document may include any number of operations, only a single operation will be executed. If a document includes multiple operations, all operations must be named and the request must include an operationName parameter that specifies which operation to execute. In other words, while you can combine multiple queries into a single operation, or multiple mutations into a single operation, you cannot cannot mix-and-match queries and mutations.
Given any two fields that share the same "parent" field, both fields will resolve at the same time. The only exception to this are root level mutation fields, which do resolve in sequence. As such, GraphQL does not support any syntax that would let you reference another field and use it as the input to some argument.
One possible workaround is to include a field in your createWebSession payload type whose field is the Query type. I illustrate this approach in this article as a means of refetching queries but it would work for what you're trying to do as well.

Related

How to derive values in apollo client

I have a few react components that mutate my server data and for now I have refetchQueries: [{query:myQuery}]. I need to restructured the data as a map for faster lookup time. How can I accomplish this? In Redux, I would have used reselect and in MobX I would have used #computed. As far as I can tell, apollo doesn't support this functionality yet.
I looked into:
#client directive, but this doesn't work for me since I have to compute the data on the server response.
reactive variables don't work either since I will have to change the variable everywhere I mutate the data, far from ideal.
There seems to be very little information out there about computed/derived values when using Apollo Client, the only reference I found was this one:
Apollo GraphQl Storing derived data
How about if you define in your schema & in your resolver some alternative (union) response structure? (not sure if this would work actually)
type Query{
books(mapBy:String): [Book]|JSON
}
so if you query (using it instead of mutation for simplicity)
query{
books(mapBy:"id")
}
it would return JSON
{
123: { __typename: "Book", name: "Dune"}
}
And if you don't want to return all of the Book fields in JSON, maybe pass extra param which would list actual structure you need.
Didn't encounter such problem myself yet, interesting. But otherwise, it should be done on client side.

Is it possible to map a subscription parameter to an array at the mutation output?

I have a theoretical question. As I know subscription parameters must exist as a field in the returning type of the mutation. This means that the type of parameter must also match the type of the field in the returning object of the mutation. Am I right? Suppose I get an array with channels ids in the mutation response. I only send one channel id as a parameter in the subscription. Is it possible to map a subscription parameter to an array at the mutation output? If the channel id exists in the array (field channelsIds), the subscription must work. Is it possible to write this logic in the scheme itself, or is it technically impossible?
GraphQL schema:
schema {
mutation: Mutation
subscription: Subscription
}
type Mutation {
testMutation(input: TestMutationInput): TestMutationOutput
}
type TestMutationOutput {
channelsIds: [String!]!
userId: String!
userEmail: String
userPhoneNumber: String
}
type Subscription {
watchTestMutation(channelId: String!): TestMutationOutput
#aws_subscribe(mutations: ["testMutation"])
}
If I understand you correctly you want to filter based on if the mutation's returned value is in an array that is passed as an argument to the subscription. Sorry to say that is not possible at this time. Subscription filters only evaluate to true or false and cannot accommodate any logic other than that.
At the end of October 2020, I contacted AWS support for advice on this issue. I think this answer may be useful to someone, so I post their answer.
Please allow me to inform you that the use-case that you have
mentioned in the case is currently not possible via AppSync. I
understand that the lack of the feature may be causing inconvenience.
There is an internal feature request already with the AppSync team to
incorporate this feature and I have added a +1 on your behalf. It is
worth noting, that once this feature request is with the team, it will
be up to the team as to if/when this potential infrastructure feature
is implemented, and because of the limited visibility into the
progress of internal development processes, I won’t be able to provide
an ETA regarding its release. I would request you to keep an eye on
the what's new page or the AWS Blogs as all new feature requests and
enhancements are posted there[1-3].
However we can suggest a couple of workarounds in this case:
Filter the required fields on client side itself after receiving the values on the client-side from AppSync.
If the values to be filtered are very limited we can use a fake mutation made with the help of a resolver mapped to “None” Data
source. In this flow, we would create a lambda function that uses a
DynamoDB stream as the trigger. The Lambda function is triggered
whenever there's an update to the DynamoDB table.

We can then include logic in the Lambda function to filter the
required fields and perform a mutation to AppSync. In AppSync, the
mutation which was called by lambda would configured using a resolver
mapped to a “None” Data source. The None data source type passes the
request mapping template directly to the response mapping template.
And when we subscribe to this mutation, we will directly get the
filtered data from Lambda that was used to call this mutation. Please
refer to [4] for a step-by-step description of this process.
But please note that this workaround is cumbersome and would require a lot of changes if the required field values keep changing. Workaround 1(handling it on the client-side) is usually the preferred way to handle this use-case.
Resources:
[1] https://blogs.amazon.com/
[2] https://aws.amazon.com/new/
[3] https://aws.amazon.com/releasenotes/
[4] https://aws.amazon.com/premiumsupport/knowledge-center/appsync-notify-subscribers-real-time/

GraphQL - Difference between using alias versus multiple query objects when doing batch queries

I'm fairly new to GraphQL, so please correct me if I'm wrong where need be. I'm wondering what would be the best way, or the most appropriate way, to execute batch queries in a single request. I've seen examples that do this:
[
{
query: "query(param1)"
},
{
query: "query(param2)"
}
]
Or examples that use aliases to accomplish the same thing:
query {
alias1: resolver1(param1)
alias2: resolver2(param2)
}
In my opinion, I think the aliases is the more appropriate option as it's a single query and within that query I'm requesting data with different parameters. So, between the two options above, what would be the more appropriate option for executing batch queries in GraphQL, and why? Thanks!
Batching operations by sending an array of them to the server is something that's not supported by all libraries. This is not a feature of GraphQL as much as just a convenient feature supported by some server libraries. On the other hand, including multiple root-level fields in a single operation is supported by all GraphQL servers. So, if you're anticipating the backend you are querying to possibly change in the future, you may want to use Option #2 over Option #1 to avoid having to potentially refactor your code in the future.
On the other hand, batching is often desirable because it allows you to mix operation types. While you can include any number of root-level fields in a single operation, only one operation may be executed at a time -- that means you can't mix queries and mutations with Option #2. If this is something you need to do, batching is the only way to achieve it in a single request (assuming your server supports it).

ElasticSearch: Is it possible to use dfs_query_then_fetch with the explain API?

Did the Explain endpoint ever support search_type: dfs_query_then_fetch? If it does now (I'm on 7.1), how do I specify it?
I was thrown for a loop when using the Explain API on two identical documents, but seeing different score calculations. Learning the documents lived in different shards, and that the TF/IDF inputs were calculated per-shard explained the difference. Using dfs_query_then_fetch on the Search API normalized the scores, but the ElasticSearch .net client (both LowLevel and NEST) don't appear to expose a way to specify it for calls to the Explain API.
I also tried to form a request manually, passing it as a querystring or request body parameter. Both fail saying the argument is invalid. I thought perhaps the Explain endpoint didn't offer a way to specify dfs_query_then_fetch, but digging through some old issues it appears that it at least did at some point:
https://github.com/elastic/elasticsearch/issues/2612
Search type is not supported on the explain API. An approach that might work would be to use the Search API with dfs_query_then_fetch and explain, with a compound query that filters only to the document you're interested in (using IdsQuery), along with the query you want the explanation for.

Searching for two resource types and sorting according to date?

Is it possible with a FHIR search procedure to search for TWO resource types and sort them according to the date? I'd like a list of Observation and QuestionnareResponses, in a single response, returning the newest 10 regardless of resource type.
Searching for one would be:
http://apps.ehelselab.com/baseDstu2/Observation?_sort:desc=date
Any query using the standard "search" capability is always against exactly one resource type. You can include referencing and referenced resources, but filtering and sorting are always done against the "base" resource for the search. To do what you're interested in doing, you have a few options:
define a custom query using the OperationDefinition mechanism (only works if you've got a direct relationship between client and server systems so you can ensure all participants support the operation
Use a "Batch" to execute queries against both, then interpolate the results as you page through both result sets
You can do a query just on the "base", however there isn't presently a way to constrain the types of resources returned - you'd need a custom search criteria
You might be able to use the _filter mechanism - I haven't dived into it very deeply. But I suspect that it also uses the "single target resource type" approach.
The best bet is probably #3. If you submit a request to add a search criteria to "Resource" allowing constraining the resource type, that would probably let you do what you wanted.

Resources