[WIP] Add AppSync support for sam local

[bramkoot]

Which issue(s) does this change fix?

#551

Why is this change necessary?

sam local start-api is awesome for all API gateway based setups, but as more and more people start using AppSync they do not have a way to test their code locally.

How does it address the issue?

It adds an extra command sam local start-graphql-api that is similar to start-api but uses the template to determine a GraphQL schema and the direct lambda resolvers. It'll setup a GraphQL server and uses the local lambda invocations as resolvers.

What side effects does this change have?

Checklist

• Write design document (Do I need to write a design document?)
• Write unit tests
• Write/update functional tests
• Write/update integration tests
• make pr passes
• make update-reproducible-reqs if dependencies were changed
• Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[es50678]

this would be awesome

[bramkoot]

Anybody from the maintainers that can have a look at this and tell me what they think? I'm happy to continue in this PR but haven't gotten any response so far, so I'd love some pointers on what still needs to be done apart from some functional tests and documentation.

[praneetap]

@bramkoot @es50678
Thanks for sending this pull request. We are hesitant to merge this today because with the current resources we would not be able to commit to maintaining this feature in the long run - maintain feature parity and fix issues with the implementation in a timely manner. Given the reaction we can see that this is important to the community and we recommend one of the two alternatives -

1. We highly recommend you to use SAM Accelerate to test this in your development environment in the cloud. Here is a helpful video to learn more about it, and here is the installation instructions for the beta version. Please let us know if this helps with your testing needs.
2. If testing in the cloud is not an option for you, we are considering adding plugin support if there is enough interest. Upvote and comment on this tracking issue, if building this as a plugin would be something you would be interested in instead.

[revmischa]

Thanks for sending this pull request. We are hesitant to merge this today because with the current resources we would not be able to commit to maintaining this feature in the long run - maintain feature parity and fix issues with the implementation in a timely manner. Given the reaction we can see that this is important to the community and we recommend one of the two alternatives -

This is a highly discouraging response to hear. AppSync is a tool for developers to build applications. The biggest obstacle right now to building an application of any complexity on AWS is the lack of local development support. It is the biggest frustration, a serious roadblock to iterating quickly during development, and expensive. No other way of building web applications has this drawback and it's the biggest reason to not develop complex applications using AWS tooling.

Despite this, an enterprising user has gone to great effort to do AWS's job for them and created this PR to fix this major gap that makes developing a GraphQL API using AWS tooling (e.g. CDK) a lot harder than it should be. For their efforts they're told no thanks.
You won't get more feedback because you'll close this issue and then when new developers are deciding whether or not they should build their application around AppSync they'll see this and think "oh forget it."

Furthermore it will discourage others from trying to contribute to this project to make it better. I would be happy to contribute to maintaining the feature because I need it right now. But if radio silence on a much-needed PR for ten months is then followed by this I'm going to have to give up on SAM again and go back to Serverless or try out SST.

I would consider Amplify but it still doesn't support postgres with AppSync.

We highly recommend you to use SAM Accelerate to test this in your development environment in the cloud. Here is a helpful video to learn more about it, and here is the installation instructions for the beta version. Please let us know if this helps with your testing needs.

My application is split into nested stacks per AWS recommendation and the lambda hotswap feature does not work with nested stacks in CDK. I tested it with sam-cdk-beta.

[praneetap]

I absolutely understand your frustration, we can only apologize for the radio silence on this PR. We are organizing ourselves to do better going forward. We thought about this and debated long and hard. Ultimately, we feel that testing against a real environment in the cloud is the best way to ensure that the results are accurate and include all pieces of the equation - for example IAM permissions. I am happy to get on a call with you to talk more about your specific use case - feel free to DM me.

My application is split into nested stacks per AWS recommendation and the lambda hotswap feature does not work with nested stacks in CDK. I tested it with sam-cdk-beta.

With SAM Accelerate we have added two new features to the SAM CLI: The sync --watch command that monitors the file system for changes and synchronizes them with the cloud resources in a matter of seconds - what CDK's hotswap feature is based on; the sam logs --tail command to aggregate and tail all log streams for all resources of an application to present you with a complete application log. We are tracking SAM Accelerate support for nested stacks here. In April we started testing a CDK support in the SAM CLI and we plan to support CDK applications in SAM Accelerate too. You can track progress in the integration on this issue.

[johnc44]

@praneetap - I too would love AppSync support. I do think that some kind of plugin system for sam would be a huge benefit. There are no doubt plenty of other things that might be quite complex to solve generically (e.g. authorizer support) but might be otherwise quite easy to do. So please +1 for plugins.

Running locally was the reason we started using sam. In a team it means none of us will interfere with each other until we are ready to deploy. If we were all to run our own stacks then it can become quite complicated.

[jfuss]

I am going to close this PR as we currently not accepting more local emulations into the CLI. We are still heavily talking about local internally and how we could meet the customer need here for Appsync and other resources/services. So this is NOT a signal that we are ignoring customer wants in this area but the team does feel like we need to find a better solution than accepting local emulations directly into the CLI (aka. possible through a Plugin system).

I would like to move further conversations into #3265. We do need feedback for Plugins to help us scope and make sure we balance things correctly but more importantly that it does support what Appsync or other emulations would need.

Thank you @bramkoot for spending the time on this and want to apologize the radio silence from us. Our speed to respond to PRs (across our repos) is slow. As a team, we are working on ways to address this going forward and trying to stay on top of incoming PRs first and (at the same time) work through our PR backlog.