Amplify-cli: AppSync Pipeline Support w/ overriding auto-generated resolvers

[lookitsatravis]

* 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:

type Mutation {
  createInvitation(input: CreateInvitationInput!): Invitation
}

Which fails to push because I don't have the Amplify-generated CreateInvitationInput type. So, I added that type in manually like this:

input CreateInvitationInput {
  id: ID
  owner: String
  token: String
  invitationUserId: ID!
  acceptedAt: AWSDateTime
}

type Mutation {
  createInvitation(input: CreateInvitationInput!): Invitation
}

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.

[mikeparisstuff]

@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.

[kawallis]

Is there any update on this issue? Me and my team are hoping to implement this

[venkatesh-kadiyala]

@mikeparisstuff
Do you have an update on this issue ?

[artista7]

@mikeparisstuff Anything?

[babu-upcomer]

@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.

[babu-upcomer]

@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,

type UserDevice
    @model
    @auth(rules: [
      { allow: owner, ownerField: "userDeviceUserId", identityField: "sub" }
    ])
    @key(fields: ["userDeviceUserId", "deviceKey"])
{
    deviceKey: String!

    userDeviceUserId: String!
    user: User @connection(name: "UserDevices")

    isActive: Int

    createdAt: String
    updatedAt: String
}

I don't want the userDeviceUserId to be passed by the user due to security reasons. This needs to be auto assigned with the value of the current user sub. String! is needed because I get InvalidDirectiveError: The primary @key on type 'UserDevice' must reference non-null fields. error if I remove !. If I leave it that way, I get required userDeviceUserId on calling create mutation. The resolver has been generated to assign the user sub though. This is a clear conflict of requirements.

Update: If I pass userDeviceUserId with a value other than the current user sub, I am getting "Not Authorized to access createUserDevice on type UserDevice" error which I guess is not allowing records to be created with other user ids. So, we can consider this as partially resolved but a better documentation could have saved a lot of time.

[paulnolan7]

@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.
This could work as a short term fix until the properly solution is available.