Allow more than one GraphQL API in a project

[esteban-uo]

Reopening as it was closed without an answer https://github.com/aws-amplify/amplify-cli/issues/335

Is your feature request related to a problem? Please describe. Currently it is not possible to add more than one GraphQL endpoint in a project. There are use cases where multiple GraphQL endpoints are required, for security isolation, for code maintenance, or for multiple backend microservices.

Describe the solution you'd like To allow multiple GraphQL endpoints in an Amplify project. To share Amplify CLI created resources (e.g. DynamoDB, User Pool) between these endpoints in a project.

[jcbdev]

So I have been thinking about this for a while and the approach I was considering trying but haven't gotten round to it. My idea is essentially having an "amplify" per graphql endpoint

<project>/
  -- amplify-service-1/
     + amplify
  -- amplify-service-2/
     + amplify

'amplify-service-1' would be considered the 'main' one and host all the other packages such as Auth, Analytics, Storage and so on. Then there is a command amplify auth import which you could potentially use in amplify-service-2 to import and use the same cognito created by amplify-service-1. If this works then amplify-service-2 will be able to share the auth layer but host it's own graphql api.

I have no idea how practical this is, and I don't know if the client js libraries can support more than endpoint in the config so you would probably require some magic as well. I believe if you use the apollo-client library you can connect to different endpoints using the appsync auth link and just use the main amplify-service-1 as the config for the main Amplify.configure()

This is all just speculation but it is something I have been thinking about myself. If you give it a try let me know if it works!! I could do with splitting my projects!

[attilah]

@esteban-uo this requires a major change at a platform level in the CLI to support this scenario. I mark it as an feature request just like aws-amplify/amplify-cli#335.

[PatrykMilewski]

I believe sometimes splitting API into multiple endpoints is a valid case.

In our project the schema for API grows quickly and we already had some troubles with AppSync console being not able to handle that big schema, which is annoying in case of developing custom resolvers. Due to this we had to get rid of some autogenerated CRUD endpoints, that were not used.

However the same can be achieved by setting up another Amplify microservice and exposing a new API. Maybe not the most comfortable way from CI/CD etc. perspective, but having everything as single service might end up as huge "Amplify monolith".

[esteban-uo]

@attilah thanks. I really hope this can be prioritised soon. A related issue was also created over here https://github.com/aws-amplify/amplify-js/issues/5186

I believe Amplify has a lot of potential and I'm very happy what you guy have developed, however if Amplify was meant to be a Framework for "simple and small" web applications, I guess that should be stated in Amplify Vision and AWS FAQ.

Personally, after using Amplify for a while I stumble as @PatrykMilewski mentioned; with one monolith very hard to decouple in small services. Ideally I would like to brake down my amplify application vertically. For now, the only way of dealing with it is as also @PatrykMilewski stated, is using custom resolvers, which in long term is a big pain to maintain. https://aws.amazon.com/blogs/mobile/appsync-microservices/

In my opinion, this missing feature and anything missing which helps to avoid monoliths (there are others), I believe goes against AWS best practices:

You guys internally between the service teams, talk each other through multiple and different APIs and this was and is one of the key points that brings you to what you guys are.

One idea that comes to my mind, following the AppSync Microservices Blog, could be solved elegantly with graphql; instead of relying on the resolvers with plain HTTP, appsync could hook to the actual graphql endpoint and introspect the endpoint and its schema. I'm not sure if this has been already discussed but I would be happy to brainstorm about it.

Kind regards and thanks

[ShariqAteeq]

+1

[sergiorodriguez82]

in our case, we have 50 model entities, and separating the api would help in our maintence, we take about 25min for each push and we must pray no cloudformation limits are reached.

[okiroth]

+1 so is this happening?

[macsinte]

+1 on this, any news? It's been almost a year since the last reply, is there no way to get this working ? It is a major limitation of Amplify, if we want to use it for more complex projects.

[menkari]

+1 for this...adding in a new appSync api for, let say...reporting which sits outside the context of the existing platform/user is a major use case in more than a handful of applications...especially if you start leveraging AppSync's ability to tied in multiple data sources.

[costleya]

"Hidden" being an option in AppSync Merged API to allow having internal-only visibility in the source API. With AppSync only supporting one endpoint, it makes this feature pointless. Unless the intention is if you are building a semi-advanced project, Amplify is not for you.

[rbtkess]

+1. Is this happening? If not, why not? If so, what’s the ETA? Thx.

[menkari]

"Hidden" being an option in AppSync Merged API to allow having internal-only visibility in the source API. With AppSync only supporting one endpoint, it makes this feature pointless. Unless the intention is if you are building a semi-advanced project, Amplify is not for you.

+1 Surely utilising Cognito Groups (or User Pools for that matter) makes sense here?