Description
Why is this needed?
I'm new to GraphQL in general, but I think in the original PR #323 the AppSyncResolverEvent
was based on AWS Amplify, so instead of reading parentTypeName
, we are reading typeName
.
It confused me that the code is consistent (in some ways) with AWS AppSync Context info:
type Info = {
fieldName: string;
parentTypeName: string;
variables: any;
selectionSetList: string[];
selectionSetGraphQL: string;
};
But we are assigning variables in a way they are not clear:
And we define different property names for reading the parentTypeName
:
This has the side-effect that when setting up an AppSync resolved in AWS like the following, it does not work out of the box and you have to pass typeName
to make it work:
import { util } from '@aws-appsync/utils';
/**
* Sends a request to a Lambda function. Passes all information about the request from the `info` object.
* @param {import('@aws-appsync/utils').Context} ctx the context
* @returns {import('@aws-appsync/utils').LambdaRequest} the request
*/
export function request(ctx) {
return {
operation: 'Invoke',
payload: {
fieldName: ctx.info.fieldName,
parentTypeName: ctx.info.parentTypeName,
typeName: ctx.info.parentTypeName, // Extra field which is exactly the same as the one above
arguments: {}, // Extra field
variables: ctx.info.variables,
selectionSetList: ctx.info.selectionSetList,
selectionSetGraphQL: ctx.info.selectionSetGraphQL,
},
};
}
/**
* Process a Lambda function response
* @param {import('@aws-appsync/utils').Context} ctx the context
* @returns {*} the Lambda function response
*/
export function response(ctx) {
const { result, error } = ctx;
if (error) {
util.error(error.message, error.type, result);
}
return result;
}
Which area does this relate to?
Event Source Data Classes
Solution
I'm not sure if it was the intention and it should stay the same, but I think we can improve this in different ways:
- If the old approach is not desired, we can just deprecate it and mention
parent_type_name
should be used - If the old approach is still valid, we can try to read
info
fromparentTypeName
aftertypeName
is checked. This way it is consistent with the AWS Resolver context here and with the Amplify structure
I can prepare a PR if the suggestion makes sense.
Acknowledgment
- This request meets Powertools for AWS Lambda (Python) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET
Metadata
Metadata
Assignees
Labels
Type
Projects
Status