Add GraphQL parent context within `Parse.Cloud.define()`

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

It is currently not possible to get context of the "GraphQL parent". So it is not extend the GraphQL schema like so:

extend type MyParseClass {
  myParseClassCustomField: Any! @resolve(to: "myParseClassCustomField")
}

and query like this:

query GetMyParseClassAndCalculatedField($myParseClassId: ID!) {
  myParseClass(id: $myParseClassId) {
    objectId
    myParseClassCustomField
  }
}

But instead, we have to do extend it like this:

extend type Query {
  myParseClassCustomField(myParseClassId: ID!): Any! @resolve(to: "myParseClassCustomField")
}

and query like this:

query GetMyParseClassAndCalculatedField($myParseClassId: ID!) {
  myParseClass(id: $myParseClassId) {
    objectId
  }

  myParseClassCustomField(myParseClassId: $myParseClassId)
}

The above assumes there is a MyParseClass parse class defined like so:

type MyParseClass {
  objectId: ID!
  # ... other properties of MyParseClass
}

The above is a very simple example, but you can see how it gets really complicated to run cloud code functions within GraphQL when doing nested queries, like myParseClasses.edges.node.myParseClassCustomField.

This also means doing the waterfall approach when the objectId is not defined, where the query for the customField has to wait until you get the objectId from first query, then query for custom field using that id.

Feature / Enhancement Description

Add parent GraphQL context to Parse.Cloud.define request argument.

interface FunctionRequest<T extends Params = Params> {
  installationId?: string | undefined;
  master?: boolean | undefined;
  params: T;
  user?: User | undefined;
  parent: {
    typename?: string | undefined;
    objectId?: string | undefined;
  }
}

It should at minimum contain the typename and objectId of the parent, so that we can easily query using that objectId:

Parse.Cloud.define('myParseClassCustomField', (request) => {
  if (request.parent.typename === 'MyParseClass') {
    return calculateUsingObjectId(request.parent.objectId);
  } else {
    throw 'This function can only be called from within MyParseClass';
  }
});

Example Use Case

Functionality explained above.

Alternatives / Workarounds

Current workaround is to extend type Query instead of the actual class we want to extend and add all required params (objectId or other) to filter/get the class instance we want within the Parse.Cloud.define definition.

Start by tracing the Parse.Cloud.define request handling and the GraphQL @resolve path described in the issue. Determine how the GraphQL parent typename and objectId can reach the function request, then verify that nested class fields expose both values without requiring an additional objectId argument.