search

aws-amplify / amplify-cli

The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development.
Apache License 2.0
2.81k stars 821 forks source link

Approaches to managing development flow? #479

Closed rcwestlake closed 5 years ago

rcwestlake commented 5 years ago

Which Category is your question related to? amplify-cli

What AWS Services are you utilizing? appsync, amplify, amplify-cli

Provide additional details e.g. code snippets I've started a side project with appsync and started using the CLI to create resources. It's simple and helpful in a nice way. But to be honest, I am confused about how it fits into a development workflow... one that can standup in a production environment. Based on research and articles it seems the options are:

Option 1: Handle everything through the CLI

This means that the resources are created. But once they are created, you need to update and manage everything in the AWS console (besides the schema.graphql. If you want to modify the resolvers, you have to do that in the console. If you modify the schema in the console and then run amplify push locally your changes are overridden with what you had locally even though it's out of sync.

So: good for getting started but little flexibility because most things are abstracted and if you need to update, you're in the AWS console. You wouldn't want to check the backend api into your repo because it gets out of sync.

Question about this option: is there a better way to manage things locally? to keep it in sync with changes in the console?

Option 2: Manage yourself via cloudformation, terraform, serverless

Take most of the abstraction out of it and handle resources yourself. The schema is local, the mapping templates (resolvers) are local and deployed based on your configuration. This provides more control and can handle different stages (dev, release, prod). Since you are controlling things locally, you can check into your repo... run thru your normal development cycles. The downside is you don't have some of the abstraction magic... all of the resolvers aren't created for you. My understanding, though, is that once you push the schema to appsync.. you could run amplify codegen and get all of the queries, mutations, subscriptions locally.

Question about this option: If you don't attach a mapping template to a field, does appsync create it for you or does it just not have a one attached? For example, if I has an @aws_auth directive as part of my schema, would I get that for free if I push up my schema without a resolver or do I need to handle that myself?

Thanks to the team for all the work you are putting in. It's an impressive product and I'm sure will only get better.

kaustavghosh06 commented 5 years ago

@rcwestlake Just to give you an idea, we're close to complete with the beta version of team-workflows and CI/CD flows as part of the Amplify CLI and working actively on our documentation. As soon as we launch it, I'll update this thread (expect an announcement sometime next week). This release should answer all your questions above.

cojack commented 5 years ago

@kaustavghosh06 any progress?

kaustavghosh06 commented 5 years ago

@cojack Please take a look at #508

cojack commented 5 years ago

Yeah, but the #508 is more about how to provide a flow and not about how to locally create a datasource map them to specific source type like Lambda and then attach field to resolver that we create in a step before. This part is missing in amplify @kaustavghosh06 and it has to be done manually in amazon console if you don't follow the CloudFormation schema.

nipuna-perera commented 5 years ago

Looking for a way to modify resolvers locally and push to amplify.

kaustavghosh06 commented 5 years ago

@nipuna-perera You could maybe use the amplify push —no-gql-override command.

kaustavghosh06 commented 5 years ago

@cojack Please take a look at #74 The code for this is currently in PR stage.

kaustavghosh06 commented 5 years ago

Hey guys, we released support for custom resolvers as part of the CLI versions > 1.0.0. please feel free to check it out and let me know if you've suggestions regarding the same. Looking forward to your feedback.

SebastianKirsch123 commented 5 years ago

Hey guys, I'd like to harken back to the original question by @rcwestlake as I still feel some questions are unclear. My situations is as follows I'm managing a project that consists of an iOS App, an Android App and a ReactJS based WebApp. They all connect via AppSync to existing DynamoDB tables. In the future new and existing tables may be added or removed. MobileHub doesn't fit that requirement, so I've been experimenting with Amplify/AppSync. The only way I managed to get to the aforementioned setup is by creating an AppSync API and adding the tables via the console, autogenerating the graphql statements, and then running

Overall I'm very impressed with Amplify, so I hope there is a way to use it in production for our project.

rcwestlake commented 5 years ago

@SebastianKirsch123 believe they've come up with something that solves that... I remember reading about it when it first came out. Because I didn't have the time to wait, I went ahead and used Serverless to manage all the infrastructure and stages (dev/prod). It has worked well so far.

A couple resources: https://github.com/sid88in/serverless-appsync-plugin https://read.acloud.guru/deploy-a-graphql-service-on-aws-with-the-serverless-framework-7af8fc22a01d

I might come back to amplify-cli once it's a bit more proven / I have the time to dig in.

SebastianKirsch123 commented 5 years ago

I've come up with a configuration that, while far from perfect, works for my scenario. I've only tried it using an API key for authentication and iOS/Android/ReactJS I'll detail the process. May help some people who need to maintain a separation of environments across multiple frontends:

Pick one of the local directories (I chose iOS/Xcode ) Create a new amplify project on the command line: amplify init -> choose dev as environment in the setup client Create the api locally with: amplify create api Now create the schema for the dynamoDB tables locally in your "schema.graphql" file (located at /amplify/backend/api/your_project )

Repeat the same process for all the other amplify features you need

Push to the cloud with: amplify push This autogenerates the api and database tables according to your local schema and any other resources you've created locally.

Create the test environment: amplify env add -> choose test as environment in the setup client Then run: amplify push

repeat the same steps for your prod environment. This creates a mirror image of the dev resources in the cloud: new api, new db tables, etc. DO NOT add any resources locally while you are in test or prod, since your environments will be out of sync.

Now you can go to the AppSync console. You'll see three different environments. Head into the dev simply follow the steps listed there for integration with your other frontends. In this setup one project holds the cloud backend locally, whereas the others only get the API endpoint.

This way you can work in the dev environment

Once you move into the testing/production stages, you'll go to your project with the cloud backend, change into your desired environment and run amplify push.

In your other projects you need to change the API endpoint and access key in your local awsconfiguration.json or aws-exports.js files.

Once you go back to development, change the endpoints and keys back to dev. To make the process safer you should probably version control the local backend via git. I left this out for simplicity's sake The important thing to keep in mind is to only add backend resources locally in your chosen project while you are in the dev environment.

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.