When expressing data filters, via GraphQL, should we be creating explicitly-named fields for that filter or should we be adding a parameter to a more generic list-type field that would apply the filter?
For example, if I've got a field called teams but I want to provide the ability to filter the data, provided by teams, down to only the teams who are active (versus inactive), should I expose that filter via GraphQL as a param on the teams field, or should I create a new field called activeTeams?
I'm thinking the clearly, explicitly named fields might scale better and be less confusing in the long run because there won't be questions about how params works when paired with each other, etc.
I wanted to get feedback on how maybe Facebook approaches this, or how others are doing so.
You should add the filter as a param on the teams field as this is the more scalable approach. Introducing a new filter means only a single parameter needs adding. Whereas the multiple-fields approach requires an exponential number of fields for each possible combination.
Don't forget that you can also alias fields on the client if you wish to fetch multiple queries of teams within the same component:
query on Viewer {
activeTeams: teams(active: true) { ... }
inactiveTeams: teams(active: false) { ... }
}
Related
I know that ES supports sorting top hits by more than one fields, like sort: ["_score", "datetime"] suggested by this post: https://discuss.elastic.co/t/top-hits-query-with-same-score/107018
But how to do it using Java API?
The AggregationBuilders.topHits().sort() only receives one field as parameter.
Should I use
and SortBuilder as parameter?
If so, SortBuilder asks for a QueryShardContext parameter, which I don't know how to create. I have never used it before. None of the other requests uses this QueryShardContext.
Is there any simple way to do it, like, just pass in an array of fields into sort()?
Thanks in advance!
There are overloaded TopHitsAggregationBuilder.sort() methods, namely one that takes String name, i.e. the name of a field, so you can do it like this:
TopHitsAggregationBuilder thabuilder = AggregationBuilders.topHits("top");
thabuilder.sort("datetime", SortOrder.DESC);
thabuilder.sort("field2", SortOrder.ASC);
...
All the sort calls will add a new sort component to the top-hits aggregation.
Given the following GQL
query getMembers {
repository(owner: "nasa", name: "cumulus") {
mentionableUsers(first: 100) {
nodes {
login
organization(login: "nasa") {
login
}
}
}
}
}
(Query against GitHub v4 GraphQL)
the value for login under organization is either "nasa" or null
I am trying to figure out if it's possible to use #skip against the login/organization so that only contributors to the repo, who are members of the nasa org are shown. I believe for this particular query you can do it another way, but this is just an example.
How would you use #skip/#include with a non boolean. There is minimal documentation on this. While I could filter the response JSON in my client side app, it would be more efficient to receive less data sent over the network and then to parse in my app.
Playing in GraphQLi I received errors trying this various ways - maybe its only possible if the field returns a boolean itself?
e.g., I couldn't do login #skip(if login==null). I also tried setting a value to null in the variables section and the referencing it in the query, but none of the variations I tried work.
What I would really like to do is not include the parent if the child field is some value. e.g., if login=null then don't include that mentionable user. There is no search field option on mentionableUser. From my reading, I am guessing that the only way to do this would be if the API was modified to put a search or filter field on the mentionalbeUsers, otherwise I would need to do this with my client?
Couple of points.
Both the #skip and #include directives provide the same functionality -- allowing the client to arbitrarily chose whether a field should be included in the request.
Let's say we have a query like:
query ($skipBar: Boolean!) {
foo
bar #skip(if: $skipBar)
}
If I set skipBar to true, I am effectively just sending this query:
query {
foo
}
If I set it to false, I am effectively just sending this query:
query {
foo
bar
}
As a client, my logic has to determine the value to assign to skipBar, but I could just as easily use that same logic to decide between sending one of those two queries. In other words, like variables and fragments, #skip and #include are simply a convenient way to keep things DRY on the client-side. They cannot be used to filter the result returned by the server.
GraphQL syntax does not support expressions (or for that matter, any sort of references to parts of the response). Additionally, #skip and #include only take a single argument (if) and that argument must be passed a Boolean -- either as a variable or as a literal value. Even if you could somehow pass an expression to the if argument, though, the directives determine whether the field is included in the request, period. So if the skipped field is part of a returned List (like a List of nodes), it will be absent from every node when it's skipped.
So, is there a workaround?
Not really :( As you've already guessed, if the GitHub API doesn't provide a way to filter a field, there's not much you can do as a client -- you'll have to apply the filtering logic client-side.
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.
I have a REST service /accounts which returns all the accounts data (Number, Name).
Requirement :
Should Support the below search/filter pattern with any combination of "And" or "OR" rather than retruning the entire collection.
startsWith
endsWith
Contains
Question 1 : Are these below API design correct(RESTful) or any better way to do the same
e.g -
/accounts?name^My Account 123**or**number~ACC1234
(^"==> Starts with , "~"==> ends with)
/accounts?name^My Account 123**and**number~ACC1234
(^"==> Starts with "~"==> ends with)
/accounts?name$ACC123
($ ==> account collection contains ACC123)
Spring Controller:
Planning to get these Filter (Query Parameter) pattern as #RequestParam and have a Regex to parse the pattern and then apply & retrieve it from the data store. The downside is any new filter pattern would need a change in the Controller class.
Question 2: Is there any out of the box features available in Spring 3 to do search / filter from a collection?
Thanks!
From a design perspective, using Query parameters to specify search / filter parameters is fine. However, for more complex cases such as yours, I typically define a new end point, that only deals with searches.
As an example, if my logic for search is strictly "or" and "contains", I would define a book search as such:
GET /books/?author=john&keywords=how%20to%20use%20spring
Here, my API is strictly going to search for books where the author's name contains "john" and the words "how to use spring" appear in the content. The Search logic stays consistent, and the client has no flexibility.
In your case, if the client has the ability to specific their own search criteria, you need to build out a new end point, something like:
POST /books/search
And in the request body, post your own search criteria DSL like name^My Account 123**and**number~ACC1234
I store specific custom field for each transaction. I'd like to conduct a search by this field. I wouldn't like to retrieve too many transactions (can filter by payment method id, but still) and iterate through them on application side. So, I read a documentation, didn't find an ability to search by custom field (only by predefined). I didn't try it out, but probably it's possibly to do so by following the same pattern like
var stream = gateway.transaction.search(function (search) {
search.myCustomField().is("custom_field_value");
// or search.customFields.myCustomField().is("custom_field_value");
});
Thanks in advance
I work as a developer for Braintree. Searching on custom fields is not supported at this time. You can see all of the searchable transaction attributes listed here.
If you would like to discuss alternatives, I recommend emailing our support team at support#braintreepayments.com to see if there is another method to achieve what you are trying to do.