Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(aws-apigateway): add support for UsagePlan, ApiKey, UsagePlanKey… #1221

Closed
wants to merge 3 commits into from

Conversation

akkaash
Copy link

@akkaash akkaash commented Nov 20, 2018

Adds support for UsagePlans, ApiKey and UsagePlanKey

Allows for adding usage (quota and throttling) limits for the API Gateway API. ApiKey can be used to distribute to clients to authorize access to API resources and methods. UsagePlanKey can be used to associate a Usage Plan with an API Key to identify the customers the plan applies to.

(#723)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

Copy link
Contributor

@RomainMuller RomainMuller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @akkaash thanks for you contribution!

That's a pretty good start, however there's a couple of things I'm not super fond about with respects to ergonomics / developer experience here - see my comments.

Also, it would be nice if @eladb can give this a look as well.

packages/@aws-cdk/aws-apigateway/lib/api-key.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-apigateway/lib/api-key.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-apigateway/lib/api-key.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-apigateway/lib/api-key.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-apigateway/lib/api-key.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-apigateway/lib/api-key.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-apigateway/lib/usage-plan-key.ts Outdated Show resolved Hide resolved
*/
export interface ThrottleSettings {
/**
* Represents the steady-state rate for the API stage or method.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like numeric fields to carry some form of a unit hint. At the very least, the documentation should mention it. Similar to previously, this probably should be a copy from the documentation in the CloudFormation documentation for the AWS::ApiGateway::UsagePlan resource.

Copy link
Author

@akkaash akkaash Nov 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping that a reviewer would point this out tbh with you. I was of the opinion that there may (must) be a way we can enforce certain validation of the inputs as part of these number. For example, burstLimit is required to be an Integer value. If not, the App deployment would fail. Perhaps throwing an error during runtime before cfn is deployed, CDK emit an error with appropriate messaging. Think of it like cdk.ValidateNumber but for Integers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diligent code could validate types beyond what the TypeScript (really, JavaScript) types can represent (Javascript has no concept of an int type, but you can use Number.isInteger to check & do the right thing).

tools/cdk-integ-tools/bin/cdk-integ.ts Show resolved Hide resolved
@akkaash akkaash mentioned this pull request Dec 21, 2018
/**
* A name for the API key.
* @link http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-apikey.html#cfn-apigateway-apikey-name
* @default none
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean to say "automically generated name" instead of "no name", right?

constructor(parent: cdk.Construct, id: string, props: ApiKeyProps = {}) {
super(parent, id);

const customerId = props && props.customerId;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these don't need props && since props always has a value.

const stageKeys = this.renderStageKeys(props && props.resources);

const resource = new cloudformation.ApiKeyResource(this, 'Resource', {
customerId,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know why this couldn't just be

customerId: props.customerId,
description: props.description,
// etc

?

/**
* The API request steady-state rate limit (average requests per second over an extended period of time)
*/
rateLimit?: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

averageRequestsPerSecond?

avgRequestsPerSec?

constructor(parent: cdk.Construct, name: string, props?: UsagePlanProps) {
super(parent, name);
let resource: cloudformation.UsagePlanResource;
if (props !== undefined) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting way of modeling defaults. Should this path also be taken if the user passes {}?

To be honest, this makes me a little uncomfortable. I'd rather you default props to {} and do processing that makes sense in both cases.

this.usagePlanId = resource.ref;
}

public addApiKey(apiKey: ApiKey): void {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs docs

@eladb
Copy link
Contributor

eladb commented Feb 5, 2019

@akkaash feel free to reopen if/when you wish to continue working on this.

@eladb eladb closed this Feb 5, 2019
@orangewise
Copy link
Contributor

@akkaash Any plans on continuing this PR?

@orangewise
Copy link
Contributor

I did some work on this one and added a new PR: #2564.

Thanks,
Ronald

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants