Trying to figure out the differences. Can AWS Lambda act as an API or vice versa? Would I still need to setup an API if I wanted to use Lambda functions or can I use Lambda functions right from the get go?
AWS Lambda can be used to serve an API. You could use API Gateway for setting up the API, and the serving can be done via a Lambda. It is a nice pattern.
Ref: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-lambda-integration.html
And to your main question, I don't think you can directly configure an API in AWS Lambda service.
Alternatively, you can do it by setting a Function URL to your lambda.
It will require changes in how you receive input and send the output for the lambda and also has some limitations related to authentication. Still, it would be a more self-contained approach than the API Gateway integration if you need to expose your API publicly.
Lambda functions can now be accessed directly with a Function Url. They have minimal functionality when compared to Amazon API Gateway.
However, since the integration event is effective the same. It is very easy to go from Function Urls to API Gateway or ALB in the future if you require greater functionality.
Related
I have a AWS API Gateway, deployed using SAM template. The API request comes to the Proxy Lambda Function. From there I need to call a AWS Step Function which invokes multiple Lambda Functions. I have multiple Solutions. Following Microservices pattern. Need to call one microservice from another. Each Microservice is in a seperate solution and the startup project is a ClassLibrary(.NET Core 2.1). Using SAM template and deploying it via AWS Toolkit for Visual Studio. Not using Fargate Containers and WebApi projects. Need to coordinate between API Gateways.
In your question you say: "The API request comes to the Proxy Lambda Function. From there I need to call a AWS Step Function". It is simple, here an example of api gateway that use a lambda like authorizer and in the method execution I call a step function. In your step function later you manage your flow and your and the lambdas that you need execute
I want to use Odata as a query builder in my api's hosted on aws lamda and exposed using AWS api gateway. On reading several aws documentation, I found that people have faced several issues with this earlier. Can someone please tell me about whether it's supported and if not what can be an alternative for the same?
Thanks in advance!
OData at its core is just REST relying on web standards and as such will be supported by web-standard compliant tech stack, so will work with AWS API Gateway and Lambdas.
However you have to ensure that you can pass custom headers and query parameters to your function, which used to be a bit tricky.
It used to be the case that you had to pass headers inside a request body as lambdas had only visibility to the request body: see this AWS technical documentation.
However since Sept 2017 you can setup lambda with proxy integration which will proxy request and response headers to and from your lambda verbatim.
HTH.
I have AWS Lambda function and I invoke it calling AWS API Gateway via REST API. For Lambda function I configured two aliases with versioning - QA and Prod.
API Gateway is configured with Lambda Proxy Integration Request. I know about AWS API Gateway stages feature and I create two stages (QA and Prod respectively), but I don't see any settings for Lambda aliases in stage configuration.
How can I specify QA Lambda alias for QA stage and Prod Lambda alias for Prod API stage?
On the integration request in API Gateway you can add the alias name to the end of the ARN to make sure your endpoint points to the correct alias. Something like this
arn:aws:lambda:region:account-id:function:function-name:alias-name
You can't tell an API Gateway stage to always use a specific Lambda alias and have multiple Gateway stages that all point towards different aliases.
Every time you need to deploy to a Gateway stage, you'll have to make sure your undeployed API Gateway endpoints are configured to point to the correct Lambda alias before deploying to the stage that matches that environment.
This get tricky to maintain, so I would recommend treating your two different stages as completely different resources using the serverless framework or another framework.
Useful resources:
https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-lambda
https://serverless.com/framework/docs/providers/aws/guide/intro/
On your integration request, you will see the Lambda Function - click on it to edit and add :QA or :Prod after it and hit the checkmark, I think that will do it.
example: myLambda:Prod
How to use same domain name for front end and for lambda function endpoints
for Serverless framework ?
I am using reactjs for frontend design and for frontend hosting I am using s3 and Aws Dynamodb for lambda functions.
We do the same in our systems, AWS solved it long time back.
It is the cloud service called CloudFront, which lets you connect multiple origins including external origins that are outside of AWS cloud.
Created a simple architecture diagram to help you view the same.
Hope it helps.
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)