Mocking API with @searchable in schema fails

[PeteDuncanson]

Describe the bug

My GraphQL schema uses the @searchable directive. This can't currently be mocked locally (by running amplify mock api) and the CLI tells me this, however it also reports that it will set a NONE data source as a work around for that but it still fails to run.

This prevents any mocking while @searchable is in the schema.

To around around this I've been commenting out @searchable from my schema and then runnning amplify mock api. I'm happy with not being able to test the elasticsearch part of my schema functionality local but it is stopping me testing any of it easily currently.

Amplify CLI Version
You can use amplify -v to check the amplify cli version on your system

v4.32.0

To Reproduce

Create a schema:

type Todo @model @searchable { id: ID! name: String! }

in the CLI run amplify mock api and watch it complain with something similar to the following:

Expected behavior

Couple of options I think:

• Have the existing fix actually work, provide a dummy data source or whatever its doing and run that.
• Just ignore the @searchable directive when run locally, warn us that it won't work and then skip over it, effectively "commenting it out" when you run by just ignoring it when parsing it locally in a mock.

Desktop (please complete the following information):

• OS: Windows
• Node Version. v12.18.4

[kaustavghosh06]

@PeteDuncanson Yes, unfortunately @searchable is not currently supported with mock. But as you recommended, we can potentially ignore @searchable and do the same mocking with local DDB as we do without @searchable - but then the queries (with searching and sorting from the client) won't potentially work causing a discrepancy between what you see locally and what you see in the cloud. Marking this as an enhancement.

[mgarabedian]

Is it possible to just get a fix that ignores @searchable when you run mock? It makes no sense that I would need to remove it from the schema.graphql to run 'amplify mock', and then accidentally deploy ( which I did, and deleted the elasticsearch domain ). These types of things have killed so much time developing with Amplify.

[PeteDuncanson]

I'm getting to the point of writing a script that automatically comments/uncomments the @searchable fields from my schema at this point. Any update on if this might get looked at 6 months on?

[flogy]

Would be interested in such a script too @PeteDuncanson . Better would be an official solution from Amplify of course.

[flogy]

Another solution could be to allow creating separate GraphQL schemas per environment. Like that one could not only remove the @searchable directive in the dev schema to allow mocking, but also save those $30/month for ElasticSearch in the pushed dev environment.

[PeteDuncanson]

@flogy can't you do that anyway? The schema is commited into source control, if you branch for live/dev then you would get that benefit?

[mgarabedian]

@PeteDuncanson That is what I tried to do. I have a custom npm/yarn function that first comments out @searchable, then runs amplify mock, and then puts back searchable when the process exits. But then the GQL API becomes out of whack, and breaks typescript in my app. So not really a good workaround.

[AlessandroVol23]

Aren't these two duplicates? aws-amplify/amplify-category-api#309

[cjihrig]

@AlessandroVol23 yes, I'm going to close this as a duplicate of aws-amplify/amplify-category-api#309.

Also, we recently posted an RFC for @searchable improvements at #7546. Local mocking is one of the enhancements we are targeting.

[github-actions]

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.