Amplify-cli: Ability to create multiple front-end apps (React plus Swift, Android, etc.)

[chrisl777]

Is your feature request related to a problem? Please describe.
We would like to be able to create a website _and_ mobile apps for a project. It is not clear if/how it possible, plus the /amplify folder setup files appear to be wired for one front-end app only.

Describe the solution you'd like
It would be awesome if there was a way to add another front-end app with the CLI. For example, with a command like amplify frontend add or as a part of the amplify init workflow.

For example, let's say I have a React app already and now I'd like to add an iOS Swift app. Going through the CLI, perhaps I can enter the amplify init flow:

? Do you want to use an existing environment? Yes
? Choose the environment you would like to use: master
? Do you want to add another frontend? Yes
? Choose your default editor: 
❯ Xcode
  Sublime Text 
  Visual Studio Code 
  Atom Editor 
  IDEA 14 CE 
  Vim (via Terminal, Mac OS only) 
  Emacs (via Terminal, Mac OS only) 
  None 
? Choose the type of app that you're building (Use arrow keys)
  android 
❯ ios 
  javascript 
? Enter the name of your source directory: ../packages/my-mobile-app
...

Note that it would be great to be able to specify Xcode as an IDE, as well as a different folder for the mobile app's source code. This different folder would be helpful for doing a codegen, for example.

Perhaps the amplify/.config/project-config.json file could hold an array of these frontend projects:

{
  "frontends": [
    {
      "projectName": "my-website",
      "version": "1.0",
      "frontend": "javascript",
      "javascript": {
        "framework": "react",
        "config": {
            "SourceDir": "../packages/my-website/src",
            "DistributionDir": "build",
            "BuildCommand": "npm run-script build",
            "StartCommand": "npm run-script start"
        }
      },
      "providers": [
        "awscloudformation"
      ]
    },
    {
      "projectName": "my-mobile-app",
      "version": "1.0",
      "frontend": "ios",
      "ios": {
        "config": {
          "SourceDir": "../packages/my-mobile-app"
        }
      }
      "providers": [
        "awscloudformation"
      ]
    },
  ]
}

Describe alternatives you've considered
The current work around I've been toying with is to use lerna to create multiple packages. In that approach, I have a packages directory that contains a sub-folder for each frontend. However, for one thing, this approach gets problematic when wanting to generate code for an API. Also, for the second front-end that you add, you have to go through a very manual process of trying to 'hack' the pieces together for it to work and worry about not breaking the existing app. And there are some files that don't support multiple front-ends, such as project-config.json.

[UnleashedMind]

Thanks for the feedbacks, marked the feature request, we will have a discussion among the team on this.

[chrisl777]

@UnleashedMind Excellent, thanks for considering it!

[kawells924]

+1 on this feature request, in our case React Native / React Web / and a CLI.

(Also would like two graphql endpoints, one with cognito auth and one with an api token as auth)

[mkelitz]

Same need here. Needing to evolve a previous MobileHub project (stuck in AWSSDK 2.6.x) and when everything seemed great in Amplify I ended up with this.
In my case the product has two apps, one iOS and the other one Android, and they both need to use same storage folders (private, protected, public) for same logged in user and for backend code coherence.

Please any ETA would be appreciated.

[ChristopheBougere]

+1 for the feature!
And what is the recommended way to achieve this as of now? Where should you initialize your amplify project?
Thanks!

[brunoguedes]

https://aws-amplify.github.io/docs/cli/init#amplify-configure-project
Maybe this helps @ChristopheBougere

[ChristopheBougere]

Thanks @brunoguedes !
So if I have a monorepo with 3 frontend apps, I have to setup amplify in the first app, and then copy the config files in the other apps folders?
Couldn't this be problematic if I use the multi-env feature as well? Or maybe it's better to create a symbolic link between the amplify config files rather than copying them?

Anyway, it would be great to have a way to setup amplify config separately from the frontends.
Something like amplify init at the root of your repo and then amplify attach react/amplify attach ios/... in your frontend folders)

[tafelito]

What happens after you copy your amplify/ throughout the front end projects and you need to update anything from the backend, like the schema or add functions? You need to copy the updates again?

[brunoguedes]

Hi @ChristopheBougere and @tafelito. Sorry to disappoint but I was just having the same issue as you guys. I'm trying this for the first time now as well and found that link I sent.
I hope some one from the Amplify team pick this feature request soon, or give us a bit more guidance.
Cheers

[ajhool]

@ChristopheBougere I've found that this procedure (even with multi-env) is not too bad. It works fairly well and is easy enough to maintain. I agree that this feature should be available natively, but the workaround isn't a dealbreaker.

I would recommend manually copying the files instead of using a symbolic link, but that's a preference issue.

These are commands that I find myself using frequently:

amplify status
amplify env pull --restore
amplify env import

[NurdinDev]

@ajhool what the steps should I make to create a multi-frontend interface to the same backend?

[ajhool]

First off, I would also update amplify-cli to the latest version (yarn upgrade @aws-amplify/cli --latest) before doing any of this. The package has been evolving rapidly and the support for multiple environments has greatly improved. I would also create a new Environment in Amplify so that you don't mess up existing infrastructure.

I have only done this with two web-based / React projects, so it's possible that it will be more difficult for different frameworks. However, check out amplify configure project in the Usage section of the docs

https://aws-amplify.github.io/docs/cli/init

Basically, you need to copy over the Amplify directory from your existing project/framework to the root of your second frontend's directory. The Amplify directory contains information about the backend stack that you're using (by copying these files over, both frontends will use the same backend info). The Amplify directory also contains autogenerated files that will be overwritten (these files are mostly included in .gitignore and you should make sure that the .gitignore in your second project includes the appropriate Amplify files/dirs)

[tafelito]

@ajhool if you need to change anything on your schema, do you do it in any of the front-end apps and then you do the pull?

What about if you change anything directly in the AppSync console? How do you get those changes to from the cli?

[ajhool]

@ajhool if you need to change anything on your schema, do you do it in any of the front-end apps and then you do the pull?

Correct. I make the change in a front-end app, push the change, and then pull it into the other front-end apps. I always do the changes in the same front-end app, mostly for consistency's sake but also as a safety measure to avoid pushing/pulling conflicts.

What about if you change anything directly in the AppSync console? How do you get those changes to from the cli?

Hm. I don't believe that you can get those changes from the CLI. If you make a change to a mutation using the AppSync console, for instance, you need to use the no-gql-override flag on push. It looks like the team is building up some functionality like that though, this issue/conversation might be of interest: https://github.com/aws-amplify/amplify-cli/issues/74

[NurdinDev]

@ajhool I have an "ionic app" and "react admin dashboard",
can you correct me the step as I understand?
=== First Project ===
1 - create react app
2 - initialize amplify with "dev" environment
3 - amplify add API / add auth
4 - config the schema and user auth
5 - amplify push

=== Second Project ===
1- create Ionic App.
2- amplify init
3- copy project-config.json from the first project and added to this project
4- amplify env pull

is this correct?

[tafelito]

@ajhool when do you use no-gql-override? You mean if you change something on the appsync console and then on the cli, so you don't override the console changes?

[ajhool]

@NuruddinBadawi yes, I believe that is mostly correct although there are a few possibly missing details.

• Make sure your amplify/cli is up to date ( yarn global update @aws-amplify/cli --latest).
• The Second Project step 4 might need to be amplify env pull --restore which will update the local backend to reflect the actual backend.

• The Second Project step 3 needs more files than just project-config.json, I believe. It should be all of the files that aren't in your .gitignore file -- when I use VSCode and github, it's easy to tell which files I need. The files appear to be:

  1. .config/project-config.json
  2. team-provider-info.json
  3. The entire backend folder EXCEPT amplify-meta.json. Using the --restore flag on pull might rebuild this backend folder, I'm not sure. Copying is easy and not harmful.
  4. There's also a .graphqlconfig.yml in my root dir that isn't in my .gitignore, but I feel like this is a generated file that doesn't need to be copied over.

Please let me know how it goes!

[ajhool]

@tafelito yes, when you make certain changes on the appsync console (eg. adding a custom resolver) that you don't want Amplify to override.

By default, Amplify generates all of the AppSync resolvers, mutations, queries, etc. for your Amplify API, so if you make a change to your API schema and push, Amplify will overwrite any changes you've made to those resolvers on AppSync.

However, Amplify now supports custom resolvers (https://aws.amazon.com/blogs/mobile/amplify-adds-support-for-multiple-environments-custom-resolvers-larger-data-models-and-iam-roles-including-mfa/), so you might be able to write your custom resolvers in the frontend code instead of through the AppSync console.

[syriail]

@NuruddinBadawi I believe it is not correct to amplify init in the second project. Note that init will create a brand new project i.e. backend and will create AuthRole and UnauthRole.
The steps for first project are correct but for the second project you need:

1. Create Ionic project
2. Copy the whole Amplify folder from the first project to the root folder of the second project.
3. Call amplify configure project it guides you through the rest of choice.
   The last call will update the amplify configuration to work with your second project environment.

[ajhool]

I agree that "init" might not be needed. All I know is that it is "a" way to achieve it, which worked for me, even though it might not be "the" correct way to do it. I do agree that amplify configure project is probably a better strategy and my approach might be outdated

[jensk-dk]

I tried to make an experimental project supporting multiple fronteneds. I did as follows:
1) Created project with Android FE
2) Added API (and auth)
3) Created an Angular FE with ng and copied amplify/ dir from Android project dir to Angular project dir.
4) Ran amplify configure project

When running "amplify codegen" it still generated Android GraphQL, so ran "amplify configure api"
Now, when running "amplify codegen" I get:
✔ Downloaded the schema
⠋ Generating GraphQL operations2019-05-07T13:37:44.768Z - error: uncaughtException: Language android not supported

I can see no mention of android in the amplify dir.
What is the proper way of supporting multiple frontends wth one backend? There seems to be no tutorials on this.

[Jexim]

I think we can use submodules for this situation. What thoughts about this?

[MartinTechy]

I think we can use submodules for this situation. What thoughts about this?

@Jexim Have you tried it ? It seems like a good solution if you want to work with a team and with multiple clients.

[houmark]

It's been a good amount of time with this one being discussed. Did anybody find a stable procedure to do this without any serious downsides?

This should really be out of the box, we are many out here making several individual web apps or using both React + React Native backed by the same backend.

[undefobj]

Hello - Looks like this issue was opened last year before the multi-env features were released which allow you to share projects between multiple frontends. This is documented here: https://aws-amplify.github.io/docs/cli/init#amplify-configure-project

Is there still an issue related to this? It's hard to determine from the thread as it goes back a while. Or is the issue that this isn't easily discoverable in the docs?

[houmark]

Thanks for your feedback @undefobj!

Maybe it's just me, but I don't see how multiple environments solves that without new issues.

For example, all my dynamo tables embeds the environment name as part of the table name, so if I have app1 and app2 I would not be able to share the same DB tables for both apps without modifying how Amplify names the different resources, which seems like an even bigger task, than the already proposed workarounds in this thread, and in addition I completely lose the chance to run an isolated dev and prod environment for each app also.

Is there something obvious I have missed here?

[undefobj]

@houmark Did you read through the instructions in the link and test out the workflow on multiple apps? I only mentioned multi-env as that was the release which introduced the functionality. It has steps to share a backend in a single environment. The page says "When sharing your backend infrastructure code with multiple frontends".

So to summarize: This is supported out of the box in Amplify today. The question is around the workflow and if more functionality is required.

[houmark]

I did, but I had a long session, so I probably better get some sleep and read it again and try it out. Thanks for now, I'll report back here in any case, so everyone else that may not have been aware of this can get an update.

[MartinTechy]

@undefobj I discovered that today and decided to give it a go.

The only thing I'm wondering is how does it work with conflicts ? What happens if two persons try to modify the same service at the same time ? Or if someone push changes before you push yours ?

I also think that it should be a little bit easier to find in the doc. A small example of the workflow would be great !

Thanks for your help

[houmark]

I also think that it should be a little bit easier to find in the doc. A small example of the workflow would be great !

Same for me. I did not really see how multiple frontends would be working from the docs you linked on configure. I saw this thing called "Do you want to use an existing environment?" elsewhere in the docs, where it did not mention multiple frontends, but I suspect that is part of this?

Still, having to manually copy over folders seems like a workaround/hack, so improved docs and maybe even an improved CLI to have a more guided flow to do this would be nice. I have considered different branches inside my main git for the different apps or the above mentioned submodule approach, but I don't have 1-2 days to spend on trying out options, but I need my second app out SOON and worry about how much time I will spend getting something decent working.

[undefobj]

Ok so it's a doc discoverability issue. @kaustavghosh06 tagging as an FYI for the refresh on the doc structure.

"manually copy over folders seems like a workaround/hack" What's the alternative to this? Does the CLI ask for the other destination project and copy things for you? Does the CLI copying to a different directory really seem like less of a "hack" then you manually copying?
What if it's on another machine? Then you really need some sort of copy process. I'm not sure a git workflow is correct here, but I'm happy to be wrong. If I have a React and an Android app with a single backend this really seems like a copy process.

[houmark]

Someone proposed to make it possible to add several folders inside the root folder so all apps live inside there, which makes copying the amplify folder not needed.

That way each of those in theory could be their own git and so could the amplify folder (maybe using submodule).

It seems like the copying is not creating any issues for people so I’ll try that to start with.

[houmark]

To clarify: Several folders from the root level, one for each front end and all created by a guided Amplify CLI flow so amplify knows about each citizen.

[ChristopheBougere]

Agreed with @houmark, having as single amplify project shared with multiple frontends would be the best. Something like this:

• /amplify
• /react
• /react-native
  The CLI could handle this with a amplify frontend add command, similarly to categories.

[houmark]

• /amplify
• /react
• /react-native
  The CLI could handle this with a amplify frontend add command, similarly to categories.

Exactly, just like that.

[jensk-dk]

For what it's worth I contacted Amazon support regarding multiple app frontends.

Before that I tried using amplify configure project, as the doc says that it should be used "When sharing your backend infrastructure code with multiple frontends". But it was ultimately to no avail - I got all sorts of errors, especially with codegen for GraphQL API.

Instead, what they proposed was to init both frontends as separate projects. I keep the JS project as the main project, so the JS project is always in sync with the backend. I then added the API manually, using "amplify add codegen --apiId XXXXXX". When I change the GraphQL API, I run "amplify codegen", which pulls the new schema from the backend. After that the gradle plugin builds the types ec. Java classes.

It works, but I think the process is poorly documented, and I really would like to see an official tutorial.

[abFx]

We ended up doing almost the same, which means, we are sharing the same backend app across micro-frontends

We shared the backend amplify app as a submodule, so you can easily have access to the generated files, but then you also need to copy the aws-exports and the graphql generated files.

At the end it seems more like a patch, which at some point in time comes back to remind you that something is wrong. As, in we struggle the same trying to create our CI/CD pipelines.

For now it works, but doesn't seem to scale very well with multiple applications sharing one codebase.
We are now moving away from amplify and creating our own aws cloudformation templates with nested stacks.

[kaustavghosh06]

Hello guys, we've added more documentation around this topic in our docs. You can checkout the amplify env import command as mentioned in the docs to seamlessly copy over a project info into another frontend roject.

[magjack]

Hi I have been following the advice detailed here https://aws-amplify.github.io/docs/cli-toolchain/quickstart#multiple-frontends to create a multi frontend app with one amplify backend. It is working fine with respects to all backend auth and graphql the only problem I face now is Hosting as when I change the hosting of the app to another bucket and then push when I pull the env in the other app it is overwriting the hosting. Is there a way to make hosting separate to the rest of the backend setup?

[Nicosoft]

@magjack I have actually the same issue with hosting. I am stacked.
My Goal:

• same backend
• 2 apps written in React => 1 hosting solution (S3+Cloudfront) for each app.

Did anyone found a solution?

[magjack]

Yes, I did I used the Amplify console. So remove all hosting you do with the CLI and use the console as it configures hosting in a different way and deploys the CLI configured backend. You can see more here https://github.com/aws-amplify/amplify-cli/issues/2406. It is also really useful for setting up a CI/CD as well.

[swaminator]

@Nicosoft we added a new amplify pull and updated the multi-frontend doc to highlight the workflow: https://aws-amplify.github.io/docs/cli-toolchain/quickstart#multiple-frontends

[houmark]

@Nicosoft we added a new amplify pull and updated the multi-frontend doc to highlight the workflow: https://aws-amplify.github.io/docs/cli-toolchain/quickstart#multiple-frontends

NIIIIIICE!

[chrisl777]

@Nicosoft we added a new amplify pull and updated the multi-frontend doc to highlight the workflow: https://aws-amplify.github.io/docs/cli-toolchain/quickstart#multiple-frontends

Awesome!

[lukeramsden]

What about when both my front-ends are in one repo? I want to codegen to multiple different places, but it's not possible currently.

[jonmifsud]

@Nicosoft how would this work with 2 react apps exactly? As I don't think you can publish to a frontend (s3 + cloudfront) for the second app.

We were thinking of using the same cognito for backend/frontend access and we had split them into two different codebases.

[BennettSmith]

I see the issue has been closed. What was the recommended solution if you have React, iOS and Android apps?

Right now we are maintaining three repos (amplify+react, ios, android). We make all of our changes to the backend in the amplify+react repo. Then, we run amplify pull with the --providers, --frontend, and --amplify arguments in both of our native mobile repos. We also run amplify codegen for each. After all of this we end up with updated config settings in the native mobile app repos.

Our current approach is very painful. It is difficult to keep all of these settings in sync across the projects. Because of how amplify manages multi-environment projects it is also difficult to build a native mobile app that can talk to either the dev, test or prod version of the backend.

The whole approach currently seems like a workaround. Could an RFC be opened where we might collect everyone's thoughts on a possible better approach?

[fkoner]

@magjack @Nicosoft

How did you handle this flow?

One amplify backend.
2 React Apps (each one in different git repositories) and host them in the amplify console, and targeting the same backend?
Also, how to achieve each frontend to target to specific backend environment?

[nilooy]

+1 on this feature request, in our case React Native / React Web / and a CLI.

(Also would like two graphql endpoints, one with cognito auth and one with an api token as auth)

me too, i also need the feature, i thought to go with yarn workspace.

[hogarthww-labs]

I created this issue https://github.com/aws-amplify/amplify-cli/issues/6247 to address the folder structure problem