Right now, we're returning all the results of a given repository's
advisories, which can be extremely large if targeting a monorepo, or
just a repo with a lot of dependencies.

To prevent potentially retrieving and then sending hundreds or thousands
of results to the caller, we can instead set up pagination.

This uses offset-based pagination, but with an encoded cursor, mentioned
in [0] and seen across other APIs. We use offset-based pagination as we
don't have a stable identifier for a given row, and so it's easier to
think of it in terms of an offset.

To do so, we need to change the structure of our GraphQL response, which
allows us to surface pagination information.

We can also add an explicit `pageSize` limit in our schema, so it's
clearer to the user what the default behavior is.

However, this is a breaking change as we're changing the structure of
the GraphQL response, which needs to be flagged appropriately with a
`compatible_since` bump.

This requires that we use a named variable for sqlc for `limit` and
`offset`, otherwise we get errors such as:

    missing argument with index ...

Due to the rest of the query having numbered indexes generated by sqlc.

Closes #564.

[0]: https://betterprogramming.pub/understanding-the-offset-and-cursor-pagination-8ddc54d10d98

As part of #235, we want to be able to source information about the
packages we depend on which are looking for financial support.

We should also produce this data in our GraphQL API to make it possible
for consumers to feed it into their own tooling.

As part of #406, we should also make it possible to expose this over the
GraphQL API to use for other means.

As it may not always be set, we need to make this an optional field.

Now we've implemented #237, we should also make it possible to query a
repository's `libyears` via the GraphQL API.

Jamie Tanna authored 1 year ago and Jamie Tanna committed 1 year ago

As part of #260, we introduced the `dependency_health` table and data to
indicate more information about the health of a given dependency.

We should also expose this on our GraphQL API to make it possible to
query independently.

If we're not specifying the version in our query, then it'd be very
useful in the report result to list the version + current version in the
response.

For the command-line report, we don't reflect the version / current
version back if it was requested, only the values that aren't set.

This also wires this in for GraphQL queries, so we can have relevant
data.

Closes #326.

To allow for us to make it possible to expose both the owner's name and
notes, we should refactor this into an `Owner` object, rather than a
plain string.

This requires a bit of wiring in for the different queries that use the
field, as well as making sure it gets resolved.

As part of #151 we also want to be able to query a list of given
repositories, which can be defined through their `RepositoryKey`s.

This implementation is almost exactly the same as `RepositoriesLike`,
due to it operating on a list of repository keys.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

Closes #342.

As part of #151, this requires we introduce the ability to list
repositories based on `LIKE` SQL syntax, and then performing the
per-repo lookups.

Right now, we're not wrapping this up with Goroutines to improve
performance, and we'll optimise it in the future if needed.

We need to make sure we look up whether `totalAdvisories`,
`totalDependencies` or `totalPolicyViolations` are found in the query
and then generate the total values as needed, as we cannot wire in the
resolver (via GQLGen) to wait until the `repositories` field has
executed.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

This is the first GraphQL query from #151 that provides some more
significant querying of data, and so requires we wire in a new sqlc
querier.

This introduces queries that are largely taken from other places, to
retrieve the core data required by the query.

We can make sure to create lighter-weight queries for `Count`ing data,
as well as provide a helper method to convert DB types to GraphQL types.

To make sure that we can reference values that are having pointers
pointed to them, we need to make sure we handle loopvars correctly.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

As part of the implementation of a good first GraphQL API, we can use
the code from the `dependenton` report to produce the same data via
GraphQL.

As part of #151.

Similar to the underlying code that performs the reporting, we need to
add some complex conditionals to perform the right query.

To make sure that we can reference values that are having pointers
pointed to them, we need to make sure we handle loopvars correctly.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

As a design-first approach to considering how we will interact with
objects in the database using GraphQL as part of #151, we can introduce
the relevant types and enums.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

As a step towards #151, we can introduce the start of our GraphQL API.

We can start by adding support for DMD's inbuilt metadata table, which
right now has just the version of the CLI that was used to bootstrap the
database.

This introduces a separate CLI, `dmd-graph` that can be used to serve
the GraphQL API, as well as wiring it into the `dmd-web` CLI.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

Closes #320.