feat: log graphql requests

[jsstevenson]

This PR does two things

• Logs query types and variables for things that you type into the search bar, basically.
• Logs the complete query and variables for requests made to the API endpoint NOT from the frontend client.

For example, the frontend logs look like:

# Logfile created on 2024-10-24 15:35:22 -0400 by logger.rb/v1.5.0
I, [2024-10-24T16:24:18.135312 #77300]  INFO -- : {:user_ip=>nil, :query_type=>"drugMatches", :query_variables=>{"searchTerms"=>["BRAF", "NTRK1", "NTRK2"]}}
I, [2024-10-24T16:24:25.670429 #77300]  INFO -- : {:user_ip=>nil, :query_type=>"drugMatches", :query_variables=>{"searchTerms"=>["IMATINIB"]}}

and the API logs look like

# Logfile created on 2024-10-24 15:35:22 -0400 by logger.rb/v1.5.0
I, [2024-10-24T16:20:56.239529 #76634]  INFO -- : {:user_ip=>nil, :query=>"query interaction($id: ID!) { interaction(id: $id) { gene { name conceptId } drug { name conceptId } interactionTypes { directionality type } interactionScore publications { id pmid citation } sources { fullName } interactionAttributes { name value } } }", :query_variables=>{"id"=>"a80d7cbb-d350-45c9-9800-6044db8dace0"}}
I, [2024-10-24T16:20:58.727886 #76634]  INFO -- : {:user_ip=>nil, :query=>"query gene($conceptId: String!) { gene(conceptId: $conceptId) { conceptId name geneAttributes { name value } geneAliases { alias } geneClaims { source { citation } } geneCategories { name } } }", :query_variables=>{"conceptId"=>"hgnc:3765"}}

Similarly, I was thinking it'd be nice to grab a reduced list of ambiguous results when those come up, but I haven't had a chance to look through the way to explore the query tree and I'm sort of supposed to get this thing shipped.

[jsstevenson]

^

[acoffman]

You might want to double check that it works as expected, but it looks like (based on this example here) you can set an HTTP Header when your initialize the graphql client.

That might be better than stapling it into each query individually.

[jsstevenson]

@acoffman yeah, I was a little unsure of whether we wanted to set different headers for different queries and to filter out noisier or less informative ones. We should probably set a base one at client initialization and then maybe use an additional one for chosen queries if we go that route.

[acoffman]

A couple small things, but its looking good overall!

[mcannon068nw]

per our discussion, this looks to be capturing what we are intending for our research goals.

approved but I would also defer to @acoffman 's feedback on his earlier requested changes. If those look good, we should be good to go

[acoffman]

One minor question, looks good overall!

[acoffman]

I think this needs to be inverted right? We skip analytics if it is an introspection query.

[jsstevenson]

Ugh, thanks, I always goof these

[acoffman]

LGTM!