feat(appsync): add EnhancedMetricsConfigProperty for GraphQL api

[aki-kii]

Issue # (if applicable)

Closes #29933 .

Reason for this change

A property in L1 construct was not in L2 construct.

Description of changes

Add enhancedMetricsConfig property to GraphqlApiProps and set in the CfnGraphQLApi constructor.

• The enhanced Metrics Config now includes the operationLevelMetricsEnabled property, which has changed from an enum of "ENABLED" and "DISABLED" to a boolean.
• The properties of EnhancedMetricsConfig are not flattened because they interact with each other.
  For example, if operationLevelMetricsConfig is enabled, dataSourceLevelMetricsBehavior will default to PER_DATA_SOURCE_METRICS.

Describe any new or updated permissions being added

Description of how you validated changes

Added both unit and integration tests.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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

[mazyu36]

Thank you for the contribution.
Before reviewing the details, let me confirm.
Don’t we need to add the metricConfig property to Resolver and DataSource?
If the API’s config is set to per-resolver metrics, I think the resolver’s config is also needed.

https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-appsync-datasource.html#cfn-appsync-datasource-metricsconfig

https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-appsync-resolver.html#cfn-appsync-resolver-metricsconfig

[mazyu36]

There’s an existing issue, please associate it.

#29933

[badmintoncryer]

Thank you for you contribution! I've added some minor comments.

[badmintoncryer]

Why is it necessary to use Lazy here?　

[aki-kii]

@badmintoncryer
Thanks.
Thinking it over again, I found I didn't need to use Lazy.

[badmintoncryer]

Do other constructs also have arguments where we can pass {} like this?
Personally, I feel that having settings activated as a result of passing {} is not very intuitive.

[aki-kii]

I found that the appsync.GraphqlApi.logConfig property was passing {}, but I think also passing {} is not very intuitive.

Suggest requiring the dataSourceLevelMetricsBehavior and resolverLevelMetricsBehavior property, because after setting those property the behavior changes.

ex)

EnhancedMetricsConfig {
  readonly dataSourceLevelMetricsBehavior: DataSourceLevelMetricsBehavior;
  readonly operationLevelMetricsEnabled?: boolean;
  readonly resolverLevelMetricsBehavior: ResolverLevelMetricsBehavior;
}

[badmintoncryer]

Some of the existing arguments can also accept empty objects! In that case, I don’t think it’s a big issue, so please feel free to implement it in whichever way you prefer!

[aki-kii]

@badmintoncryer
Implemented dataSourceLevelMetricsBehavior and resolverLevelMetricsBehavior as required properties.

[aki-kii]

Thank you for the contribution. Before reviewing the details, let me confirm. Don’t we need to add the metricConfig property to Resolver and DataSource? If the API’s config is set to per-resolver metrics, I think the resolver’s config is also needed.

https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-appsync-datasource.html#cfn-appsync-datasource-metricsconfig

https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-appsync-resolver.html#cfn-appsync-resolver-metricsconfig

@mazyu36
Thinking it over again, I believe metricConfig property of DataSource and Resolver are necessary.
I’ll go implement those properties.

[aki-kii]

There’s an existing issue, please associate it.

#29933

@mazyu36
Sorry. I've associated the issue.

[badmintoncryer]

Thanks! I've added some minor comments.

[aki-kii]

Thanks! I've added some minor comments.

Thanks!
I understand and accept your suggestion.

[badmintoncryer]

Thanks!