Amplify API Only for back-end or microservices development in large projects

[koiker]

The idea is to enable Amplify to create API only solutions but using all the features that Amplify provide today.

This is because for large projects where you are developing the teams dealing with each component or microservice won't need to see the others code, just the microservice that they are working on it. A simple solution would be each two-pizza team create a new Amplify project right? But every new project will be a full stack project that we need to define the code framework (AngularJS/React/Vue/etc.) and if we are talking about a project with dozens or hundreds of microservices we don't need all the boilerplate of a front-end to build the API. This will modularize Amplify to support Front-end + Back-end (a.k.a full stack) but will support a back-end only too.

Many customers that want to split their project into multiple microservices will be able to use Amplify

Note: If your feature-request is regarding the AWS Amplify Console service, please log it in the official AWS Amplify Console forum

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[SwaySway]

Will review this feature request with the team.

[kmbro]

Any update here?

[Alk3m1st]

Also wondering if there are any updates?

[the1adi]

Please advise on when this would be available

[undefobj]

Can you give more specific scenarios and functionality that would be expected from such a feature? It's hard to know the implementation from the description in this request. More specifics will help us evaluate in the future or allow a community contribution.

[rscharer]

Speaking personally: I would expect something like this to push Amplify much closer to a Serverless Framework equivalent. For back-end-only microservices, Amplify would push Lambda/Step Function/Database Schema definitions up to AWS and provide very simple onramps to X-Ray, CloudTrail/ElasticSearch, Cognito auth, and other AWS value adds that are relevant to serverless backends. Right now, as far as I know, Amplify assumes a front-end.

[undefobj]

Speaking personally: I would expect something like this to push Amplify much closer to a Serverless Framework equivalent. For back-end-only microservices, Amplify would push Lambda/Step Function/Database Schema definitions up to AWS and provide very simple onramps to X-Ray, CloudTrail/ElasticSearch, Cognito auth, and other AWS value adds that are relevant to serverless backends. Right now, as far as I know, Amplify assumes a front-end.

@rscharer Amplify is a Framework for building mobile and web applications. So yes it is targeted at developers building frontend applications. This will include backend components (APIs, Databases, etc) in service of supporting the frontend application. Just building a backend microservice that is completely divorced of the frontend architecture is not a goal of the project today.

To rephrase from above - What are the specific use cases that you're trying to accomplish in this feature request? If they're not related to building mobile or web applications, then Amplify may not be a good fit for you at this time. If they are can you give us details so that we can account for them in the future?

[kmbro]

For me personally, I love the ease of spinning up a new lambda, connected to and APIGW, with a dynamo db and Cognito. I have found myself wishing for this ease of adding these resources by hand using either life CFT of the new wonderful CDK.

Specifucally, a few months ago I was starting a new project and needed the stack I described above. But I also was going to need to add in some other resources like a CMK from KMS, and a few other things. So I ended up creating an amplify project, translating the generated CFT templates to CDK, and then adding my other resources.

I digress a little. Back to the point at hand. I think the spirit of what i wanted from this grate request waa the ability to create a backend that was separate from a front end. But according to your answer above, that is not the purpose of Amplify. I would question that a little bit as it is possible in a micro service infrastructure to have services that serve the services that the user facing UI calls. So if a team is responsible for the "1 degree of separation" services they are not able to use the same tooling as the team directly interfacing with the UK.

Hopefully that clarifies a little of what I was hoping for from this feature. (side note, I love if Amplify generated CDK instead of CFT.. just saying 😊)

[koiker]

Speaking personally: I would expect something like this to push Amplify much closer to a Serverless Framework equivalent. For back-end-only microservices, Amplify would push Lambda/Step Function/Database Schema definitions up to AWS and provide very simple onramps to X-Ray, CloudTrail/ElasticSearch, Cognito auth, and other AWS value adds that are relevant to serverless backends. Right now, as far as I know, Amplify assumes a front-end.

@rscharer Amplify is a Framework for building mobile and web applications. So yes it is targeted at developers building frontend applications. This will include backend components (APIs, Databases, etc) in service of supporting the frontend application. Just building a backend microservice that is completely divorced of the frontend architecture is not a goal of the project today.

To rephrase from above - What are the specific use cases that you're trying to accomplish in this feature request? If they're not related to building mobile or web applications, then Amplify may not be a good fit for you at this time. If they are can you give us details so that we can account for them in the future?

Hi Richard,

I will give some use cases that maybe clarify my idea.

The API interface that Amplify provides is based on AppSync and the integration with data sources in the back-end. When you create a new Amplify project you specify the front-end framework (Javascript, React, Angular or Vue, for example), if you want authentication to include Cognito, Federation to integrate with identity providers among other components and then you have your boilerplate to work. This is amazing as you can build your React front-end, describe your schema with GraphQL, add mutations and a lot of automation in the API side.

I believe here is where I understand Amplify start to work in the "back-end" side of the full-stack as when we start defining the API schema, mutations and data logic, it's all back-end logic to respond to the front-end requests. (Maybe opinions diverge on where API gateways reside in the front-end/back-end world)

Thinking with this model, there are project where I could use Amplify just to start my API (AppSync and all the GraphQL schemas and transformations) and just the front-end will be lead by another team in another repo. If we could get Amplify to skip all the boiler plate to choose the front-end framework and skip directly to the API and all the other services behind him, we can use Amplify to manage separated components of the application. We still use Amplify for the full stack, but initializing Amplify for the FE in one repo and Amplify for BE in other repo and so on we can break the full app into small 2-pizza teams where each one will work in his own slice of the project but sharing a common framework (Amplify)

The idea is not to make Amplify a new Cloudformation, but instead just get the best part of Amplify that is orchestrating the AppSync and all the logic behind the GraphQL, VTL, mutations, lambda integrations and all the complex and moving parts behind this wonderful service called AppSync and be able to work on specific parts of the project per team (Isolated and separated projects)

I don't know if the description above make more clear and is the same idea as others here. But I'm trying to describe the desired state.

PS: Even if you can start an Amplify project and use the API part for what you are interested, the deploying will still deploy front-end parts that are not desired. We will end using the tool (Amplify) for half the resources they will provision. Maybe even removing unused or needed resources.

[the1adi]

I want to add that in addition to maintaining a micro service architecture with Amplify, it would benefit to restrict “amplify checkout” of certain back-end environments. For example - if a developer checkout the master ENV and run “Amplify push” directly, it will update the master ENV for the project and risk breaking. Unless there is a way to restrict via IAM roles (was not able to figure this out), certain ENV’s should only be updated via the CI/CD & source control.

On Mon, Jun 22, 2020 at 11:18 PM Rafael M. Koike notifications@github.com wrote:

Speaking personally: I would expect something like this to push Amplify much closer to a Serverless Framework equivalent. For back-end-only microservices, Amplify would push Lambda/Step Function/Database Schema definitions up to AWS and provide very simple onramps to X-Ray, CloudTrail/ElasticSearch, Cognito auth, and other AWS value adds that are relevant to serverless backends. Right now, as far as I know, Amplify assumes a front-end.

@rscharer https://github.com/rscharer Amplify is a Framework for building mobile and web applications. So yes it is targeted at developers building frontend applications. This will include backend components (APIs, Databases, etc) in service of supporting the frontend application. Just building a backend microservice that is completely divorced of the frontend architecture is not a goal of the project today.

To rephrase from above - What are the specific use cases that you're trying to accomplish in this feature request? If they're not related to building mobile or web applications, then Amplify may not be a good fit for you at this time. If they are can you give us details so that we can account for them in the future?

Hi Richard,

I will give some use cases that maybe clarify my idea.

The API interface that Amplify provides is based on AppSync and the integration with data sources in the back-end. When you create a new Amplify project you specify the front-end framework (Javascript, React, Angular or Vue, for example), if you want authentication to include Cognito, Federation to integrate with identity providers among other components and then you have your boilerplate to work. This is amazing as you can build your React front-end, describe your schema with GraphQL, add mutations and a lot of automation in the API side.

I believe here is where I understand Amplify start to work in the "back-end" side of the full-stack as when we start defining the API schema, mutations and data logic, it's all back-end logic to respond to the front-end requests. (Maybe opinions diverge on where API gateways reside in the front-end/back-end world)

Thinking with this model, there are project where I could use Amplify just to start my API (AppSync and all the GraphQL schemas and transformations) and just the front-end will be lead by another team in another repo. If we could get Amplify to skip all the boiler plate to choose the front-end framework and skip directly to the API and all the other services behind him, we can use Amplify to manage separated components of the application. We still use Amplify for the full stack, but initializing Amplify for the FE in one repo and Amplify for BE in other repo and so on we can break the full app into small 2-pizza teams where each one will work in his own slice of the project but sharing a common framework (Amplify)

The idea is not to make Amplify a new Cloudformation, but instead just get the best part of Amplify that is orchestrating the AppSync and all the logic behind the GraphQL, VTL, mutations, lambda integrations and all the complex and moving parts behind this wonderful service called AppSync and be able to work on specific parts of the project per team (Isolated and separated projects)

I don't know if the description above make more clear and is the same idea as others here. But I'm trying to describe the desired state.

PS: Even if you can start an Amplify project and use the API part for what you are interested, the deploying will still deploy front-end parts that are not desired. We will end using the tool (Amplify) for half the resources they will provision. Maybe even removing unused or needed resources.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <aws-amplify/amplify-category-api#407>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIGDIAJWMQSDH5RJVI622XLRYANITANCNFSM4H5HWDNA .

[shellscape]

Amplify is a Framework for building mobile and web applications. So yes it is targeted at developers building frontend applications. This will include backend components (APIs, Databases, etc) in service of supporting the frontend application. Just building a backend microservice that is completely divorced of the frontend architecture is not a goal of the project today.

@undefobj that's not entirely true, as @dabit3 has demonstrated in quite a few videos and writeups that the Amplify CLI can be used to do just that. If the CLI team has that working, it should be a small step to getting that working with the API and the Console.

[JackyRio]

any update on this ?

[kilianheinrich]

Also wondering if there are any updates?

[Kamilius]

Any updates on this one?

[anurag4100]

any update on this?

[alexjball]

I would like to be able to use Amplify to simplify management of backend infrastructure on AWS, as it does today. But I would like to host my Next.js frontend on Vercel. So the microservices are not divorced from the frontend, I just don't want to use Amplify for the frontend.

[prashant-joshi-25]

any updates on this??

[rickyadriell]

Any updates on this?