Custom Pipelines handled through Appsync

[akilisosa]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

In generation 1, I can create custom mutations + queries, just by stating the name, input and return type. Then i can handle the custom logic, "data pipelines" invoking other lambda functions inside the appsync console.

In generation 2, it seems like you have to do all that logic in template files somewhere else and maybe its the same, but it is confusing for me.

Describe the solution you'd like
A clear and concise description of what you want to happen.
I just want a way to add in my custom mutation, specify the input, and the output like I did in generation 1, and maybe there is a key word or some other attribute that I add that lets it know that there doesn't have to be a specified resolver, and that appsync will handle the logic for it.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

I have tried to figure out what the current template thing is but the documentation is a little sparse and doesn't go over how you would invoke a lambda function or build it into a pipeline of lambda functions.

Additional context
Add any other context or screenshots about the feature request here.

one more annoying thing is that in gen1, if you create a lambda endpoint resolver a different way( in the function part) it sometimes clears out the custom logic that you did in appsync.

[chrisbonifacio]

Hi @akilisosa 👋 thanks for raising this issue! I've marked it as a feature request for the team to consider.

[stocaaro]

Hello @akilisosa ,

Do you have examples of what you've tried in Gen 2 and what you where expecting? You're probably looking at the Function Setup docs, is there a specific step or part of the overall function setup experience that could be clarified to help?

Thanks,
Aaron

[akilisosa]

Hello @akilisosa ,

Do you have examples of what you've tried in Gen 2 and what you where expecting? You're probably looking at the Function Setup docs, is there a specific step or part of the overall function setup experience that could be clarified to help?

Thanks, Aaron

I have tried to integrate an emailing service, and the translation service, and other lambda functions into my pipelines.

I just want to do it like i did it in generation 1.

I want to be able to use the console and have amplify just let appsync take over control.

The gen 2 docs dont make sense and for some reason some of the other built in type safety features and other things don't work in angular.

[akilisosa]

so i've tried basically doing this:

  likePost: a
    .mutation()
    // arguments that this query accepts
    .arguments({
      postId: a.string()
    })
    // return type of the query
    .returns(a.ref('Post'))
    // only allow signed-in users to call this API
    .authorization(allow => [allow.authenticated()])
});

but i do not want to do the other stuff, in amplify. I just want to use appsync instead of making these other files.
it is not clear how to make pipelines,
it is not clear how i would integrate other data sources that aren't defined in the app.

For example i created a email lambda function. This was turned into a data source in appsync. -> I create a custom mutation, with a pipeline, I make a function that invokes the lambda function, all within appsync. Thats how i do it in gen 1.

It would be nice if you could just do:

  likePost: a
    .mutation()
    // arguments that this query accepts
    .arguments({
      postId: a.string()
    })
    // return type of the query
    .returns(a.ref('Post'))
    // only allow signed-in users to call this API
    .authorization(allow => [allow.authenticated()])
.appsync(true) // have this be optional and default to false, have appsync handle the rest. 
});

[stocaaro]

You can provide a lamda handler by name for a function that is managed outside of amplify. See the comment at the bottom of this docs example.

Working from your example, it would look something like:

likePost: a
    .mutation()
    // arguments that this query accepts
    .arguments({
      postId: a.string()
    })
    // return type of the query
    .returns(a.ref('Post'))
    .handler(a.handler.function('name-of-existing-lambda-fn'))
    // only allow signed-in users to call this API
    .authorization(allow => [allow.authenticated()])

[akilisosa]

thats cool however i just want this functionality to be handled by appsync directly like it was in gen1.

I just want to do with the aws console.

[stocaaro]

Hello @akilisosa ,

I hadn't seen the pipeline resolvers from Gen1 used to make manual function edits in the AppSync console. I have gone back to see how this feature behaves. In Gen2, the closest match for this behavior would be to add a Custom Query or Mutation to your schema, which will generate a pipeline resolver function that you can manually edit in the AppSync console. Unfortunately, every deployment will overwrite the changes with the script content from the resource definition.

In ./amplify/data/resource.ts

const schema = a.schema({
  example: a
    .query()
    .arguments({
      input: a.string(),
    })
    .returns(a.string())
    .authorization(allow => [allow.publicApiKey()])
    .handler(
      a.handler.custom({
        entry: "./Test.js",
      })
    )
});

In ./amplify/data/Test.js

export function request(ctx) {
  return {};
}

export function response(ctx)  {
    console.log('Hello world');
    return "My test function 2";
}

I would agree that there is a feature we should consider adding, allowing these custom operations to have undefined or empty handlers that can be modified in the AppSync console without being overridden with each redeployment (which will happen with every backend change in the developer sandbox process).

As a work around for now, you can reproduce this experience with named lambda's today (as discussed above), or if you're prototyping, you can follow the pattern of making modifications in the console and then once working, copying the behavior back into your codebase so that it will be persisted on redeployment.