Skip to content
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/GraphQL support #39

Open
tmaiaroto opened this issue Feb 13, 2019 · 0 comments
Open

AppSync/GraphQL support #39

tmaiaroto opened this issue Feb 13, 2019 · 0 comments

Comments

@tmaiaroto
Copy link
Owner

I'd really like to add AppSync support. Then have a router for resolvers.

  • handle resolvers with a new router
  • import/export/push/sync with AppSync

The Amplify CLI toolchain is great and all but, it's very heavy and does a lot. It also uses CloudFormation and as such there's a lot of stateful issues and limitations. For example, there is no ability to import and existing GraphQL AppSync API into the toolchain. However, the SDK has everything needed: https://docs.aws.amazon.com/cli/latest/reference/appsync/index.html#cli-aws-appsync

I see no tool out there that pulls down your AppSync API, allowing you to update the VTL and then push back changes. So if something was created via the web console for example...you're hosed. Amplify CLI wouldn't be able to deal with it. A sync (no pun intended) would really help.

I'm using AppSync GraphQL more and more and will replace a lot of my API needs with it. Not all, but a lot. Auth checks using Cognito are great and you can make multiple queries in the VTL templates (transactions etc) so checking for authorization based on data in RDS or something is pretty easy too. This eliminates a tremendous amount of need for Lambda functions.

Want to send an e-mail if a user invites another user to their group in your app? Sure, you're looking at Lambda. So there's no way to completely avoid it but, AppSync is a very powerful thing that people are missing out on and aren't connecting all the dots (and the examples don't really show the potential either really).

So being able to manage this from aegis fits in pretty naturally. Funny enough, one could use aegis then to build an entire API and never write any Go code at all. Technically speaking. Practically, of course you'd have more going on and would write some Go functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant