Is Amazon Lambda required to make a fully functional Alexa voice application? If so, what can and cannot be done if Lambda is not desired?
No. You can create your own secure endpoint and configure that to your Alexa skill. You will be able to accomplish pretty much everything lambda can do for you.
You can have lambda or any hosted endpoint as your Alexa backend.
However, having lambda will help you easy integration with services within AWS like using dynamodb/redshift/s3 etc...
And moreover, the price of keeping your backend running in lambda is very much less/negligible as you can have tons of requests served in less than few dollars.
Related
I have a simple question: is there a way/program/method to create unit tests to test the API Url generated on AWS AppSync to verify the validity of created GraphQL schemas, queries, mutations, etc?
There is an open-source AppSync Serverless plugin which has offline emulator support. You may find it useful: https://github.com/sid88in/serverless-appsync-plugin#offline-support
Another good recommendation is to have two separate AppSync APIs. One API is hosting you production traffic. The other is to test changes before they go to production. This is significantly easier if you use Cloudformation (highly recommended) to manage your infrastructure.
If you want to validate your API is working periodically (every minute or so), you could create a canary like the following:
Create a Lambda function which runs on a schedule. This lambda function will make various GraphQL requests. It can emit success/failure metrics to CloudWatch.
Setup a CloudWatch alarm so you can be notified if your success/failure metric is out of the ordinary.
For the canary use-case see:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html
https://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-events.html
There is also amplify amplify-appsync-simulator package that is supposed to help with testing appsync, but there is no documentation on how you should use it. It is used by serverless-appsync-simulator Michael wrote and Amplify itself.
Im new to aws.
I am going to develop a REST full app which is going host on aws.
I decided to use
Amazon S3 for static contents
Amazon Cognito User Pool for Authentication
Amazon DynamoDB as db
I am confused on where my app is going to be hosted. I have 2 ideas for that.
AWS Lambda Function + api gateway
Can I implement entire app on it ?
Elastic Beanstalk
Can i integrate all the above aws services with it ?
(Backend on .net core web api 2.0)
Please guid me
As the experience of working with cloud, after 1y 6m I can give a proper answer for my own question.
Yes.
There is a possibility to use API Gateway + Lambda for the entire app as the back end. But you have to manage your most of the app logic from the front end. On there you have to get a risk because the source code can be viewed by the public.
Keeping your all business logic in the client code is not a good practice. And keeping all the logic in the Lambda also not easy or cost effective. The reason is when you making a real world app, you will need thousands of functions. To do one task, you will have to call many functions (Then its a function run time). So it will be very expensive.
Best solution is hosting the backend on Elastic Beanstalk and front end on S3. If you have any heavy task ? then you can make Lambda functions for that.
Lambda is best for CPU bounded functions. But not to have all the application logic on it.
Since you might not be interested in managing the underlying system, you should opt for AWS Lambda + API Gateway.
I have been studying microservices and serverless solutions and am playing with an angular frontend hosted on S3 and Lambda functions that talk to various DynamoDb tables via the API gateway on AWS.
Every example and video I read/watch uses a simple CRUD microservices as part of a simple 'todo' application or similar. My problem is where does the business logic sit? If I'm building a complex application I don't want all my business logic in my frontend Angular application. Or do I? I could build an Application API which in turn calls CRUD microservices but that feels like a monolithic approach.
I appreciate there may not be a definitive answer but can anybody advise a novice on best practice?
There are several best practices I follow in designing Serverless Microservices
Start with only few Microservices (Less the better up front, unless you know exactly how the service separation should be, delaying the decision to split)
Separate your business logic that goes to the API, and use the handler as a controller in MVC to invoke the business logic. (This will also helps to unit test logic without depending on Lambda).
Its not necessary to write only simple CRUD in your API. It depends on your domain and Business Logic required. (But don't build another monolith without separating the code in to different services. Several AWS Service limits will also give you some guide on how much endpoints should be there in a service & etc.)
Apply the design patterns available for Microservices (e.g If you want to sync data bases between each Microservice, use Pub-Sub pattern using SNS, DynamoDB Streams and Lambda)
Use the Angular App to put most of the presentation logic.
Use CloudFront as a proxy and a CDN to avoid CORs.
If you need more information you can refer the following articles I have written on this.
Deploying Angular/React Apps in AWS
Full Stack Serverless Web Apps with AWS
Note: You can use the CloudFormation in Deploying Angular/React Apps in AWS to automate the creation of S3 and CloudFront with best practices.
I am looking forward to work in a Amazon Lambda with Node.js
They call it server less, So is it a better way to host our code then traditional hosting servers ?
I am open for the suggestions, thanks in advance!!
It is called serverless as you dont manage and maintain the underlying server and the runtime.
Basically you write your code in one of the supported languages, say node.js, and then configure events that will trigger your code.
Example in case of AWS, the events can be a API GW call, a SQS message, a SNS notification etc.
So it can be better depending on what you are planning on doing.
Do note that there are certain limits that AWS imposes by default on accounts for AWS Lambda.
Also there can be slight startup penalty for a Lambda.
A plus point of Lambda vs Hosting your code in EC2 is that with Lambda you dont get charged if your code is not used/triggered.
However, do note that for functions that have heavy usage it might be better to
host your own EC2.
Most important a Lambda has to be stateless.
Considering all the above factors you can take a call on whether AWS Lambda and Serverless Architecture fits your needs.
I'm a noob using Hubot, so please bear with me.
I was going through Hubot's documentation ( https://hubot.github.com/docs/deploying/ ) and saw that we can deploy to Heroku, Unix systems and others.
May I know how can Hubot be deployed on AWS Lambda ?
Best Regards.
I was wondering the same thing. I think the answer is probably "yes, if your chat system can send you http when traffic happens". I think Lambda is probably a great choice, since each message in chat is an event to process according to the rules that your bot has. So, the Lambda function invocation model is a good fit - lots of tiny invokes. You might, though, want to filter the traffic that gets to the function, though, if your chat system is high-traffic.
For example Slack's Events API lets you subscribe to all of the things you might need the bot to see, I think. You'd then need to route those requests to your lambda function, which you could do via AWS API Gateway.
The existing hubot-slack adapter uses the Real-Time Messaging API, though, so you'd need to write your own adaptor for the Events API http that the API Gateway receives.
The same approach (and requirement) applies to other chat systems.