Would be awesome if there was some documentation regarding setting up an API Gateway with Lambda-Proxy integration with one or more Lambda functions.
On a related note, I've written up an ApiGateway construct that simplifies API creation massively but I'm not quite sure how to add it to the repo or how to write proper tests. Would really appreciate some feedback on whether its worth doubling down on this approach.
What I've got currently allows setting up the following API Gateway resources:
AWS::ApiGateway::Account (for enabling CloudWatch Logs for the entire account, also creates an IAM role)AWS::ApiGateway::Deployment (for successive deployments of an API)AWS::ApiGateway::Method (created for each Lambda)AWS::ApiGateway::Resource (created for each Lambda, unless the path is /)AWS::ApiGateway::RestApi (base resource for an API Gateway)AWS::ApiGateway::Stage (only created if caching, logging or metrics is enabled)export type MethodType = 'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE';
export interface HttpConfig {
path: string;
method: MethodType;
cors?: boolean;
}
export interface LambdaConfig {
lambdaFn: Lambda.Function
http: HttpConfig
}
export type EndpointType = 'EDGE' | 'REGIONAL' | 'PRIVATE';
export interface ApiGatewayProps {
name: string;
endpoints: LambdaConfig[];
endpointTypes: EndpointType[];
cacheEncrypted?: boolean;
cacheSize?: '0.5' | '1.6' | '6.1' | '13.5' | '28.4' | '58.2' | '118' | '237';
cacheTtl?: number;
caching?: boolean;
logging?: boolean;
logLevel?: 'OFF' | 'ERROR' | 'INFO';
metrics?: boolean;
stageName: string;
}
new ApiGateway(this, 'MyAPI', {
name: 'MyAPI',
stageName: 'dev',
endpointTypes: [ 'EDGE' ],
logging: true,
endpoints: [
{
lambdaFn: lambdaFn,
http: {
path: '/',
method: 'GET'
}
}
],
});
@hassankhan, that is amazing! If you really want to contribute this to the CDK standard library, we would gladly accept it! In that case, I would have some style pointers on your code to bring it in line with the rest of our library, and I can tell you about what we expect from testing.
However, before you put in all the effort I believe that @mindstorms6 also had some API-gateway related code lying around, and it would be a waste if you both spent effort on it. So I'll let him chime in first to see where his code is at, and then we can discuss specifics further.
I'm all for this - my efforts have been focused on using the AWS::Serverless::API (for their 'new deployment each time' feature). I think there's a happy spot for both. We can probalby hide them behind the same interface.
Also, looping in @RomainMuller
Awesome, I'll try and get a PR once #474 is resolved 馃憤
Okay, some comments then:
GET | POST | PUT | ...) don't translate well to other programming languages, and we're targeting all common languages with the API. Use an enum instead.LambdaConfig and HttpConfig could be merged?cacheSize parameter makes me quite unhappy (numbers in a string) but I suppose that's just the way the API is. Can we find symbolic names for these?Is the aws-apigateway usable in production? It is really hard to understand how to create a stack that includes a apigateway. A small example would be nice as starting point.
@hpfs74 I'm sure the aws-apigateway construct is production-ready on its own (since it's only wrapping CloudFormation). That said, I'll try and find some time this week to make a PR with the constructs I created, sorry for the delay 馃憤
That would be awesome @hassankhan
@mindstorms6 your work has been creating the cfn template with the serverless:transform, and then you let cfn do the actual transform to create the template?
I am working on an API gateway construct library. Stay tuned!
Really sorry @eladb, couldn't find the time to make the PR. Is it still worth making one or is it better to leave it to you?
I am on it, would love your feedback when I submit a PR.
Most helpful comment
I am on it, would love your feedback when I submit a PR.