Amplify-cli: Multi-frontend Workflow broken

[danrivett]

Describe the bug
Attempting to follow the Multi-Frontend documentation is not successful and I can't create a secondary frontend connected to the Amplify backend managed by the primary frontend project.

Amplify CLI Version
4.27.3

To Reproduce
Given an existing separate front-end project/repository which manages the amplify directory,
When I continue at step 3 of the Multi-Frontend documentation, and create a separate front-end directory and perform an amplify pull as follows (following defaults for most options):

Then no amplifyconfiguration.json or awsconfiguration.json files are created as expected and the amplify environment isn't set-up; running amplify status simply displays:

You are not working inside a valid Amplify project.
Use 'amplify init' in the root of your app directory to initialize your project, or 'amplify pull' to pull down an existing project.

Expected behavior
Based on the documentation listed above, and also the "Share your Backend Between Multiple Projects" section in a corresponding AWS iOS tutorial I expected amplifyconfiguration.json and possibly awsconfiguration.json files to be written to the secondary project not managing the amplify directory, and running amplify status should work successfully.

Desktop (please complete the following information):

• OS: macOS Catalina
• Node Version: 14.9.0

[danrivett]

Some additional information:

• There seems to be an associated e2e test 🎉 , but it doesn't verify that the expected files are written, so I have to assume this is a regression as the test doesn't appear to be protecting against this.
• Digging around the code and experimenting, I can get those files above (amplifyconfiguration.json and awsconfiguration.json) to be written if I select ios as the app I'm building (which isn't what I want).
  
  
  
  • But even doing that it still tells me to run amplify pull afterwards - I've just run it, so not sure why I'd need to do it again? - and running amplify pull just repeats the same steps in an endless loop, and running amplify status still shows the error indicating "You are not working inside a valid Amplify project."
  
  

@attilah seems to have been working in this area from looking at the commits, so perhaps you can explain if I'm doing something wrong, or if there is indeed a bug here. Thanks.

[danrivett]

For a little bit of background here - not sure it's relevant, but there may be a question "why do you want multiple frontends if you've got a React Native application":

We don't have multiple front-end applications. Actually want to manage the amplify directory in a separate git repository outside of the repository that holds our React Native application because we have separate frontend (React Native) and backend (serverless) teams and both need to share a common Amplify environment definition, to interact with it from either end. In particular the generated DataStore types are particularly important in order for the two teams to have a single source of truth for the data model in order to interoperate reliably.

Therefore we currently have a separate repo and project with the amplify directory where we generate the GraphQL types (amplify codegen) and DataStore model types (amplify codegen models) which we also publish as an NPM package for backend services that only want the generated DataStore TypeScript types in order to make sure it's reading/writing the data correctly.

Not sure if there's a better approach to tackle this problem though? @undefobj ? (In particular I'm surprised we don't appear to be able to use the DataStore api on the backend (via lambdas) in order to query/mutate data in response to external events, but I believe we'll need to fallback to using regular GraphQL query/mutation operations, which is another reason we want to have consistent GraphQL bindings and so a shared repo containing the Amplify environment definition).

[akshbhu]

Hi @danrivett

Yes the message seems a bit confusing asking to run amplify pull again.

If you are running amplify pull command and select workflow option Do you plan on modifying this backend? as yes , then it fetches the full backend environment for the selected frontend and you will be able to run amplify status otherwise it will only fetches the metadata i.e. aws-exports.js or awsconfiguration.json(javascript for former and android/ios for latter)depending on what type of frontend you chose.

Let me know if this answers your question?

[danrivett]

@akshbhu thanks for replying on this, I appreciate it.

So it could just be my lack of understanding, and perhaps slightly ambiguous documentation then, which is good news.

Step 3 of the Multi-Frontend instructions reads as follows:

Reference the backend from your Android app using the amplify pull command. Choose ‘No’ when asked if you want to modify or add new categories to your backend. This will put the amplifyconfiguration to your src folder only. ...

So I was looking for a amplifyconfiguration file/directory, and I also assumed I could still run amplify commands, to get status but not do any modifications, but I guess status doesn't make much sense other than providing the secondary frontend a user-friendly way of seeing what's configured in the backend rather than reading the contents of aws-exports.js etc.

An update to the docs or a line output on the CLI to say that amplify status et al commands are not available in secondary front-ends would also be beneficial I think, especially to inexperienced users (though we've been using Amplify for around a year and tripped over 😬)

I'll give this another go later today to verify our React Native frontend works as a secondary frontend as I now expect it to, and will close this ticket off if so.

Thanks again.

PS - The Run 'amplify' pull to sync upstream changes message did definitely confuse me, it's worded in a way that sounds like that's an instruction for the next step. If it's there to guide the user on how to switch from the Amplify environment being managed outside this project, to being managed inside this project then perhaps it could be reworded to something like as follows:

If you would like to modify the Amplify backend environment configuration, and manage it in this project, re-run 'amplify pull' and select 'yes' to 'Do you plan on modifying this backend?'.

That's a bit verbose, but something like that would be clearer I think. Thanks.

[danrivett]

I have investigated this further and getting closer, but running into an error attempting to read from DataStore after migrating to pulling in the generated DataStore types into the front-end from the shared package which is where amplify is now managed.

Likely user error, but I'm out for a couple of days, so won't be able to look at it more until next week.

Currently I'm getting the following error when trying to do a DataStore.query, but will look into it more next week:

undefined is not an object (evaluating 'schema.version')

Thinking about it, I'm assuming this is because the exported index.js under the models directory (generated in the primary front-end and exported as a package for the secondary front end to import) uses Datastore.initSchema(schema) but this likely only works in a primary front-end environment and can't just be exported.

This begs the question how can I use DataStore in a secondary front-end using types generated in the primary front-end?

It may be as simple as having to import the models/schema.js instead of models/index.js and then manually do an initSchema inside the secondary front-end. It's a bit more manual doing it that way (since models/index.js is auto-generated), but likely workable.

I will try that next week.

[fkoner]

@danrivett @akshbhu

I agree that the message

Run 'amplify pull' to sync upstream changes.

it is very confusing for a not so experienced user. I also fell into the same confusion, but I can confirm that it was possible for me to connect two frontends (both implemented in react js) the first with the amplify backend and the second just with executing the following command, and entering the next information asked by the cli

amplify pull --appId xxxxxxxxxxxxxx --envName ninja

Also I deploy my app in the amplify console as described here https://github.com/aws-amplify/amplify-cli/issues/5228

What if it would be super is that the files of the queries, mutations and subscriptions could be downloaded in some way in this new front end, brought from the backend.

Something similar when the command is run

amplify codegen statements

Somethins similar to the following:

amplify codegen statements --appId xxxxxxxxxxxxxx --envName ninja.

I submmit a RFC:

https://github.com/aws-amplify/amplify-cli/issues/5251

Thanks in advance
_Paco_

[akshbhu]

Hi @fkoner , @danrivett

agree that the message

Run 'amplify pull' to sync upstream changes.
it is very confusing for a not so experienced user. I also fell into the same confusion, but I can confirm that it was possible

I am marking this a bug for the slightly ambiguous log after running amplify pull. If you face some other issue in the process , fell free to open a new issue.

[fkoner]

Hi @fkoner , @danrivett

agree that the message
Run 'amplify pull' to sync upstream changes.
it is very confusing for a not so experienced user. I also fell into the same confusion, but I can confirm that it was possible

I am marking this a bug for the slightly ambiguous log after running amplify pull. If you face some other issue in the process , fell free to open a new issue.

Thanks @akshbhu !!!