Fix permissions graph performance

[escherize]

Improve permissions graph performance

Resolves: #30474

Context

The api/permissions/graph endpoint can be pretty slow when the graph gets huge.

The thing that is slow is querying for, and transmitting the entire, potentially-enormous permissions graph. It has a
combinatorial explosion of every permission group id * database id. The response payload has been observed to be
25MB.

We should simply not return the entire graph when possible.

Endpoints to consider:

Legacy, slow, remained untouched until this is complete:

GET api/permissions/graph/

Faster GET endpoints:

• Faster permission graph endpoints #36647

GET api/permissions/graph/group/:group-id
GET api/permissions/graph/db/:group-id

These Offer a filtered view of the graph, by either group-id or db-id, and return all graph entries for each
group-id or db-id respectively.

I have observed a 200x speedup when using these compared to GET api/permissions/graph/ with a large permissions graph.

Speedup PUT endpoint:

• add skip-graph query param to PUT api/permissions/graph/ #36651

PUT api/permissions/graph/

Should start observing an optional query param of 'full', which defaults to true. That way it will have the same behavior for callers.

When skip-graph=true, instead of returning the entire graph, we will return just the revision number.

• (Question for FE: does it make sense to return the affected portion?)

Frontend updates

Tasks

Beta Give feedback

1. FE support partial permissions graph #36797
   +0
   

Instead of relying on the global permissions graph we will need to have the client ask for parts of the permission graph.

On Admin > Permissions

http://localhost:3000/admin/permissions/data/group

If groups are selected, then, hitting GET api/permissions/graph/group/:group-id for the group-id will return the data needed.
If dbs are selected, then, hitting GET api/permissions/graph/db/:db-id for the db-id will return the data needed.

[escherize]

Done!