-
Notifications
You must be signed in to change notification settings - Fork 818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AppSync Pipeline Support w/ overriding auto-generated resolvers #867
Comments
@lookitsatravis Thanks for bringing this up. I agree that this would be useful and we are looking into how to best support use cases like this. In general, we can move to a model where all resolvers are pipelines by default and any auto-generated logic will be encapsulated in reusable functions. Ideally you would be able to compose your own functions with those that are auto-generated in order to implement complex workflows for auth, auditing, etc. We have a few RFCs in development and one of them will comment on this so keep an eye out for that. I will try to remember to tag this issue when it is out. |
Is there any update on this issue? Me and my team are hoping to implement this |
@mikeparisstuff |
@mikeparisstuff Anything? |
@mikeparisstuff This is needed in case I assign ownerField to a custom one and want to exclude that field from the Input type so that the mutation works without passing that ownerField and auto assigned by the identifyField. Right now, I'm remvoing that field from the Input type in the AWS Console Schema editor. But it gets overridden everytime I amplify push. |
@mikeparisstuff Any update on this? It's been a long since this has been reported. I am not seeing any progress in this one. Consider this model,
I don't want the Update: If I pass |
@mikeparisstuff Is there a way to disable the type check, as I need to bring up and maintain about 40 input type from the build output schema.graphql to the source schema.graphql file. It will be very difficult to maintain these. It would be good to disable the check on codegen because the types are all there in the build schema.graphql. It's just the pre check before the build. |
Hello guys, can you please tell me how did you fix the issue? |
@matmedsaid did you find a fix to this issue? I am facing kind of similar issue, but in my case, I want to change the input type of autogenerated mutation for eg.
I also created |
I am able to solve this issue, read more
And it worked like a charm. Cheers 🥂 |
Hi folks - a couple of things. The original issue required function pipeline resolvers, you can chain them as such: https://docs.amplify.aws/cli/graphql/custom-business-logic/#chaining-functions Useful docs:
@-mention me if this is still an issue otherwise I'll leave this closed for now. |
This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs. Looking for a help forum? We recommend joining the Amplify Community Discord server |
** Which Category is your question related to? **
API - AppSync with custom stack + resolvers (#574 + #581)
** What AWS Services are you utilizing? **
AppSync Pipeline Resolver with Lambda - using @aws-amplify/cli v 1.1.0
** Provide additional details e.g. code snippets **
I've added a stack to represent a Pipeline resolver using a Lambda function as one of the data sources. During deployment, the resulting CloudFormation stack failed for the following reason:
Only one resolver is allowed per field.
I tried to update my
schema.graphql
to add a custom Mutation like this:Which fails to push because I don't have the Amplify-generated
CreateInvitationInput
type. So, I added that type in manually like this:This also fails to push with
Conflicting input type 'CreateInvitationInput' found.
.So, the question is...how can I use this pipeline in place of the auto-generated resolver? I don't want to have to duplicate the input type and have a Mutation named like
createInvitationCustom
if I can help it. The docs indicate how to use custom VTL templates in place of the auto generated ones, and it indicates how to use a Lambda resolver with a new field, but it doesn't indicate how to replace the auto-generated VTL resolver resource with a custom one.The text was updated successfully, but these errors were encountered: