feat(iot): add the TopicRule L2 construct

[yamatatsu]

I tried to implement aws-iot L2 Constructs.

I did following:

1. add L2 construct
2. add unit tests
3. add integration test
4. test with deploying to my AWS account and sending MQTT.
5. update package.json

resolves: #16602

I should do following for undrafting:

• write comments
• implement other actions
  Following is not implemented yet, but I will implements other PR.
  • Elasticsearch
  • Kinesis Firehose
  • Kinesis Stream
  • http
  • IoT Analytics
  • IoT Events
  • IoT SiteWise
  • kafka
  • Step Functions
• write README

---

Design

TopicRule and IAction

Implements of IAction

---

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

[gitpod-io]

[yamatatsu]

@skinny85
Could you have time for this review?
Or should I ask someone else to review it?

[skinny85]

This looks like a great contribution @yamatatsu! It needs some work, but it's a great start.

Can I have one suggestion? Right now, the PR is gigantic. The chance of quickly merging a PR with 51 files changed and 5,000 lines of code added are very, very slim.

What do you think about splitting it up? Perhaps something like:

1. Just TopicRule, and minimal properties to get it deployed (with unit and integration tests).
2. Remaining properties of the TopicRule.
3. New @aws-cdk/aws-iot-actions package (see my comments), with like 1 or 2 IAction implementations?
4. (and higher) Separate PRs for new @aws-cdk/aws-iot-actions implementations - depending on the size, maybe one to a few in each PR?

Let me know what you think!

Thanks,
Adam

Pull request has been modified.

[yamatatsu]

@skinny85
Thank you for your review!

I think too that it is better to split PRs and packages. But I could not image steps to complete these implementations.

Your steps is sounds good and I will do it!

1. Just TopicRule, and minimal properties to get it deployed (with unit and integration tests).
2. Remaining properties of the TopicRule.
3. New @aws-cdk/aws-iot-actions package (see my comments), with like 1 or 2 IAction implementations?
4. (and higher) Separate PRs for new @aws-cdk/aws-iot-actions implementations - depending on the size, maybe one to a few in each PR?

[yamatatsu]

@skinny85
I've done to make the PR small!

[skinny85]

Thanks so much for shrinking the PR @yamatatsu! Now it's very easy to review 🙂.

The general direction is great. I have some comments on the details, but I think we're off to a great start here - awesome work!

[skinny85]

Let's model this a little bit differently.

I have a feeling we might want to add a nice API around constructing the SQL string too. Let's "future proof" this a little bit.

I know you had an enum here before that allowed you to choose the version used. Let's combine the version with this concept to make it what CDK calls a union-like class.

So, we'll have:

export interface TopicRuleProps {
  // ...

  readonly sql: IotSql;
}

export abstract class IotSql {
  public static ver_2015_10_08_fromString(sql: string): IotSql { ... }

  // ...

  public abstract bind(scope: Construct): IotSqlConfig;
}

Take a look at how these are implemented in the AppMesh library, which uses this pattern often; here's a good example.

[yamatatsu]

OK. I will implement as lambda.Code and appmesh.HttpRoutePathMatch.

But I'd like to understand more clearly.
I wonder why this implementation is "future proof"?
Is it because the user's code will explicit the SQL version?

[skinny85]

I meant "future proof" because you removed the the SQL version enum in this iteration of the PR (which was the correct thing to do, BTW), and I'm kind of bringing it back with this vision for the IotSql class.

Pull request has been modified.