I am trying to deploy frontend and backends together via serverless framework.
I'm using a mono repository via lerna where the frontend and backend packages are separated into different directories.
So I use multiple serverless.yml s.
How can I deploy both via the same cloud formation name?
It has the following directories:
package.json
.. [packages]
.... [backend]
...... package.json
.... [frontend]
...... package.json
Where should I put serverless.yml? And how to write serverless.yml?
They will be under the same cloudformation stack because they will have the same service-name in the serverless yml.
It really depends on the type of application. for example if it is a static frontend, the frontend can be packaged into a bundle and then deployed to a public s3 bucket.
If the backend is mainly lambda (Just assuming because this is a common backend approach for the serverless framework). You can just define each lambda handler and then deploy them to AWS. This will create the lambda resources backed by an API gateway for your service. The frontend would just need to know the service URL to query the data from the api.
Related
I am deploying a hello-world serverless app in AWS Serverless Application Repository. I want to publish the app publicly in the AWS repository. While I am referring AWS documentation, I am asked to provide LicenseUrl: in the metadata section of packaged yaml.
I am a bit confused about where do I get my LicenseUrl in order to publish the app publicly.
( refer aws doc: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template-publishing-applications.html
After publishing the serverless API project to the AWS Lambda, the serverless Url not working. Running the project in local is still working, but the serverless Url just wont work. What can possibly be the reason?
Looks like your API is not deployed.
To deploy your API go to the AWS console and try to deploy your API resource:
Use the following options:
Actions > Deploy API:
I want to deploy my full-stack application Nuxt.js with api endpoint integred (with express.js).
I can't separate my project which is a very big app...
I have trouble on how to deploy my app to AWS cloud, and I don't know how to choose between amplify or lambda while keeping the lowest price possible...
My use case is fairly simple: I want to deploy a frontend to production that uses an Amplify backend, without exposing sensitive config like the API key.
I have a frontend that uses Github Actions for CI and CD and deploys to Zeit Now (since it's a Next.js project and needs SSR support, which Amplify currently does not provide). At the moment it does not have a backend connected so it deploys to production without any issues.
In the same project I've set up AWS Amplify for the backend and connected it to the frontend. It all works sucessfully as expected from a local environment.
Now I want to deploy the frontend to production, however the AWS config for connecting it to the backend, it's saved in an autogenerated file named aws-exports.js which contains amongst other things the GraphQL end point and its API key. This file has been added to the .gitignore by the Amplify CLI.
If I remove the aws-exports.js files from the .gitignore and commit it to the repository, I think it would probably work once deployed to production, however I assume this is not a good idea since I would be exposing sensitive config data.
I don't want to use AWS to deploy my frontend, which is what's suggested as solution in the documentation I've read about this. Is there any recommended way to do this keeping the frontend and backend environments separated? (meaning the frontend still being deployed to Zeit Now which will use the backend deployed in AWS).
As far as I understand the AWS AppSync security concept designates the auth model API_KEY to usage in either public applications or development environments.
Unauthenticated APIs require more strict throttling than authenticated APIs. One way to control throttling for unauthenticated GraphQL endpoints is through the use of API keys.
An API key is a hard-coded value in your application that is generated by the AWS AppSync service when you create an unauthenticated GraphQL endpoint.
I do not think that there is any benefit in trying to hide an API key. If authentication is required, it must be provided by other means than a hard-coded secret which is always extractable from public apps (such as web frontends).
There are more auth models described in the docs. [1]
If you are planning to develop an app with private endpoints and a public frontend/client, you should definitely use another auth model - most likely OPENID_CONNECT or AMAZON_COGNITO_USER_POOLS.
I think you should first read the AWS blog post titled GraphQL API Security with AWS AppSync and Amplify [2] and afterwards stating your question more precisely if any lack of clarity should remain.
References
[1] https://docs.aws.amazon.com/appsync/latest/devguide/security.html#api-key-authorization
[2] https://aws.amazon.com/de/blogs/mobile/graphql-security-appsync-amplify/
To deploy a serverless project into a stage of a service, following command can be used
serverless deploy --stage dev
Extracted from the docs
https://serverless.com/framework/docs/providers/aws/guide/deploying/
However when above command is used to deploy a service, it creates a new service with name dev-aws-nodejs in API Gateway.
Is it possible to create a service with name aws-nodejs and have different stages like dev, stag, prod etc.. Therefore, when you run the following command
serverless deploy --stage stag
A new stage called stag will be created under service aws-nodejs.
By design the current version of serverless framework doesn't support this feature. But the version 0.5.6 had been designed to deploy multiple stages into api single api gateway project. Following open issues are related to this. Some have suggested few workarounds.
AWS API Gateway stages and names are separated
Issue below, mainly highlight different services into same api gateway. But it also has some comments related to your query as well.
Deploy many micro/nano services to one API Gateway
Update:
In the recent release of serverless (v1.19), they have mentioned that they have started working on a solution for this.
Serverless v1.19 Changelog