Add support (or at least documentation) for connecting to existing Appsync project

[atlowell-smpl]

First off, this may simply be a documentation problem rather than the features actually being missing, but to a potential end user it has the same effect. As someone who has an existing appsync API that I want to start managing with serverless, there seems to be no way to connect this plugin to my existing API. The documentation and tutorials I was able to find all assumed that a developer was starting from scratch, which ignores the very real use case of a user migrating from an existing service or finding that manual deployment has become too tedious or confusing.

[bboure]

@atlowell-smpl There is no way (that I know) to link an existing API to a serverless stack.
This is because of how serverless works under the hood (it uses Cloudformations).
The resource has to be linked to the cloudformations stack.

The recommended way to migrate from a manual deployment to serverless is to create a brand new stack that clones the existing one. After that, you should point your existing clients to the new API.

I just made a quick search and I found this:
https://aws.amazon.com/blogs/aws/new-import-existing-resources-into-a-cloudformation-stack/
This could be a clue, but I hav enever done it

[atlowell-smpl]

Sorry to bring this back up so late, but I discovered the serverless Appsync component today, and it seems based on their readme that they've been able to accomplish this, so it seems theoretically possible.

https://github.com/serverless-components/aws-app-sync

This does lead me to ask, as someone considering options. Is there any advantage to using one vs. the other (the plugin vs. the component)?

[bboure]

@atlowell-smpl the Component and this plugin are two different concepts.
The first one (the component) uses AWS's SDK (api) in order to perform actions.
This makes what you are looking for possible by just using the appsync ID.

As I mentioned before, this plugin uses CloudFormations internally, which makes it impossible (or hard) to achieve.

Note that both Components and Plugins are part of the Serverless framework. They are just 2 different ways to do it.

As for the advantages/inconvenients on one before the other, well, as often, the answer is "it depends" 🙂. Depending on what are your priorities or what is important to you or your project.

This plugin implements lots of great features that the component does not (AFSIK), like:

• Schema stitching
• Template Variable Substitutions
• offline support

The component is meant to be faster to deploy, as it does direct calls to AWS's API without usingCloud Formations (it updates only what has changed).

[atlowell-smpl]

Alright, thanks for the info. I'll leave the issue open in case someone ever wants to try to see if they can figure out a way to do it, but feel free to close it if you decide it's not worth pursuing.

[bboure]

Hi,

There is a PR that attempts to add support for re-using existing API.
If you are still interested in this feature, your review and experience with this are more than welcome!

#388

[shawnmclean]

Schema stitching

@bboure is there documentation for this? I'm looking into sharing my internal graphql schema with a public package so I don't need to rewrite my schema.

[sid88in]

Making this the canonical issue for "use this plugin with an existing AppSync API," since a
few others (#307, and related #344/#395/#595/#612) are the same theme.

Status: the active work is #647 (draft), which re-introduces an apiId option to attach
resolvers/data sources to an existing API across stacks — it supersedes the older #388 I
linked earlier (via #597). That covers the "add resources to an existing API by id" half,
including APIs created by CDK/Terraform.

The other half — having this CloudFormation-based plugin take over/manage an API that was
created outside it — still isn't feasible without CloudFormation's "import existing resources"
flow, which is an AWS-level operation. The practical migration path remains: stand up a new
stack and repoint your clients (the Component can target an existing API directly because it
uses the AWS SDK rather than CloudFormation).

I'll close this when #647 lands. Schema-stitching docs (the other question in this thread)
are now covered in doc/general-config.md.