feat: Add new GraphQL API for getting occurrences

[varungandhi-src]

This is the first stepping stone towards making our APIs more oriented around SCIP
rather than source locations.

Fixes GRAPH-126

Currently based on #62768 (base branch) and also #62789 (first commit) Base PRs were merged.

Test plan

• Add basic resolver test cases
  • All results in single page
  • Results split over multiple pages
• [-] Graceful error handling
  • [-] Bad document path Will do in integration test
  • Bad cursor

[keynmol]

I think we should tighten the result here even further -

Suggested change

	codeGraphData(filter: CodeGraphDataFilter): [CodeGraphData!]
	codeGraphData(filter: CodeGraphDataFilter): [CodeGraphData!]!

Just to indicate that we will never return null here, and it will always be an object. Unless there's a situation where null here is an acceptable response?

[keynmol]

The exact meaning of [...!]! is covered in https://graphql.org/learn/schema/#object-types-and-fields (see appearsIn attribute)

[varungandhi-src]

Making this non-null will affect error propagation; if there is an error getting the code graph data, then you won't be able to read other fields for GitBlob, which seems like a net negative from a client's POV.

[varungandhi-src]

We can also strengthen this to become non-optional later, that would be backwards-compatible.

[keynmol]

Suggested change

	will go through each provenance each provenance one by one
	will go through each provenance one by one

I wonder if we should delegate this priority fallback process to the client instead, and make the filter required. This will simplify the implementation and can give better guarantees on execution time of a single API call.

[varungandhi-src]

Delegating this to the client will likely cause redundant work, as the plan is to implement syntactic indexing internally using text search for a first-level filtering process.

[mmanela]

I like the idea of the server doing the hard work in order to make a simpler easier to use API.

[varungandhi-src]

Oh wait, my comment here was wrong.

Delegating this to the client will likely cause redundant work, as the plan is to implement syntactic indexing internally using text search for a first-level filtering process.

The point above applies to the usagesForSymbol API, not here. However, given that both of them will end up being:

    provenance: CodeGraphDataProvenanceComparator

It would be weird if the filter for usagesForSymbol followed Precise -> Syntactic -> SearchBased and the filter for codeGraphData didn't have fallback.

[eseliger]

GQL schema LGTM :)

[mmanela]

I like the idea of the server doing the hard work in order to make a simpler easier to use API.

[keynmol]

I think this is a good idea – I remember us discussing having a two-pronged approach, with relying on batch indexing for infrequently changing files, and doing online recalculation for missing data. Should be fast enough for a single file

[varungandhi-src]

I think we should do it post MVP. If we start taking lockfiles and similar into account, then there will be 2 sub-flavors of syntactic (with and without versioning information), so we will need some fuzzy matching support to take advantage of it.

[keynmol]

Why prefer this over explicit field naming?

[varungandhi-src]

To make sure we get an error when adding new fields and forgetting to add something here. This is a constructor function, so it's extra important that updating it doesn't get missed.

[keynmol]

Huh. I had no idea about this behaviour.

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

type Hello struct {
	Name string
	Age  int
	Nick string
}

func main() {
	fmt.Println(Hello{"asd", 25}) // FAILS
	fmt.Println(Hello{Name: "asd", Age: 25}) // OK
}

This is an unpleasant surprise 😬

[varungandhi-src]

Can I interest you in some blog posts?

https://typesanitizer.com/blog/go-experience-report.html
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride

[keynmol]

ohh I'm always down to read some fasterthanlime

[keynmol]

Phew, went through it.

Looks good!