Filter Transaction list based on Request Body contents

[ArjanSM]

:warning: Is your feature request related to a problem? Please describe

We are using Chucker to inspect our https requests & responses and that also includes GraphQL. But due to the diverse and numerous modules in our application making network requests, the transaction list can sometimes become huge. Filtering on the basis of the URL doesn't help because the endpoints for all the GraphQL requests are just the same(because all our GraphQL requests are POST requests).
Filtering the transaction list on the basis of the request body content would be extremely helpful to filter specific transactions not limited to just GraphQL.

:bulb: Describe the solution you'd like

A very naive solution, without requiring any UI change, would be to update the SQL query in the HttpTransactionDao's getFilteredTuples() function to search the user entered text in the request body as well. Eventually updating the query to:-

 "SELECT id, requestDate, tookMs, protocol, method, host, " +
            "path, scheme, responseCode, requestPayloadSize, responsePayloadSize, error, isGraphQLRequest FROM " +
            "transactions WHERE responseCode LIKE :codeQuery AND (path LIKE :query " +
            " OR requestBody LIKE :query) ORDER BY requestDate DESC"

:bar_chart: Describe alternatives you've considered

Nothing so far.

:page_facing_up: Additional context

:raising_hand: Do you want to develop this feature yourself?

• [x] Yes
• [ ] No

[cortinico]

Filtering the transaction list on the basis of the request body content would be extremely helpful to filter specific transactions not limited to just GraphQL.

I'm afraid this feature will actually have unwanted side effects. Specifically:

1. You might end up not really filtering the list. As we widen the search surface, the result list can increase and reduce the effectiveness of the filter.
2. Users might not really understand why a certain transaction is shown. HTTP Body can be really complex, with both request and response, so users won't really know why a certain transaction is show, till they effectively open it and look through the bodies.

I see your use case though, so I'm not totally against this. I think we should consider it somehow, but I'd like to collect more opinions on this.

[vbuberen]

Agree with the opinion above and also don't think it is needed as it will be confusing for people.

[ArjanSM]

Hi All, 👋 I may have oversimplified my solution here 😅. But I do think there's an opportunity for an enhanced filter. @cortinico concerns above are totally understandable.
One solution to tackle the hurdles mentioned by Nico would be to let the user decide their filtering criteria i.e Filter on the basis of Request code, Body, Url etc.
I can understand that this may appear to be a little overwhelming to implement on top of the existing filter that Chucker already has. My concern is that, while this may be a nice-to-have feature in the non-GraphQL case, it definitely limits Chucker's usability from a GraphQL context. I can also understand any inhibitions the team may have to apply this feature for all use-cases therefore, would considering the feature to be GraphQL specific help?

[cortinico]

it definitely limits Chucker's usability from a GraphQL context.

Can you elaborate more on this?

[ArjanSM]

Sure, We are using GraphQL pretty extensively with the help of Apollo-Kotlin. Since graphQL works by having all requests be HTTP POST requests to the same endpoint, the only way to distinguish between different requests is by looking at the GraphQL queries in the request body

While developers can filter the graphql requests on the basis of the path but it still requires a pretty substantial trial and error effort to get to the transaction containing the GraphQL Request they are actually interested in. The status code doesn't help either because the status code is always OK in the event of errors until unless its a 4** or 5** event.

[cortinico]

Since graphQL works by having all requests be HTTP POST requests to the same endpoint, the only way to distinguish between different requests is by looking at the GraphQL queries in the request body

How about including graphQlOperationName https://github.com/ChuckerTeam/chucker/blob/3611a02a3fc7056b2875005ba9ec32536ace3466/library/src/main/kotlin/com/chuckerteam/chucker/internal/data/entity/HttpTransaction.kt#L58

as part of the search query?

[ArjanSM]

Ah! That works! 🙌 But it may not work for vanilla graphql implementations.

[cortinico]

I know but I would refrain to over complicating the search just for the sake of GraphQL

[ArjanSM]

Cool! That's understandable.

How would you prefer the filter experience be? Would you prefer the user mention a prefix text to when attempting to filter a GraphQL operation? like operationName=GetSomeQuery

[cortinico]

I would just search GetSomeQuery over several fields with a logical OR

[ArjanSM]

cool! Can I work on it then?

[cortinico]

Please do

[ArjanSM]

@cortinico @vbuberen Thank you for accommodating this request. I'll close this request. What sort of timeline are we looking at for the next release?

[cortinico]

What sort of timeline are we looking at for the next release?

Whenever we have time :( I'm extremely busy at the moment. We're looking for other maintainers also :)