aws-cdk-lib/aws-location: L2 constructs

[dreamorosi]

Describe the feature

At the moment CDK supports only L1 constructs for Amazon Location Service. While this works OK for creating the resources, granting permissions to other resources/roles still requires a lot of boilerplate code. Same for retrieving resource attributes.

It would be great if CDK supported L2 constructs for this service.

Use Case

Work with Amazon Location Service and provision resources via CDK. The Cfn* L1 constructs work, but require a lot of repetitive boilerplate code.

Proposed Solution

At the moment the Cfn resources supported by the service are not many.

The L2 constructs should have a:

• Map construct, this allows to create an Amazon Location Service Map resource (currently CfnMap)
• PlaceIndex construct, this allows to create a Location Service Place Index resource (currently CfnPlaceIndex)
• RouteCalculator construct, this allows to create a Route Calculator resource (currently CfnRouteCalculator)
• Tracker construct, this allows to create a Tracker resource (currently CfnTracker)
• GeofenceCollection construct, this allows to create a Geofence Collection resource (currently CfnGeofenceCollection)

Each one of these constructs has some unique props and basic attributes like name, description, pricingPlan. These all map to existing structs like CfnMapProps.

Of those L2 constructs, the only non-standard prop/method would be what currently is CfnTrackerConsumer, which essentially allows to set a GeofenceCollection consumer to a Tracker. Ideally in the L2 construct this association would be abstracted away and require only passing a prop to Tracker or calling a method like Tracker.addConsumer(GeofenceCollection).

Finally, each one of these L2 constructs should have methods related to permission like .grant, grantFullAccess, grantReadData, grantReadWrite (with some variations/different combinations depending on the resource).

Other Information

No response

Acknowledgements

• [X] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

CDK version used

all

Environment details (OS name and version, etc.)

all

[peterwoodworth]

Thanks for the request, all new L2 constructs will need an approved RFC before implementation. If you'd like to see this come to fruition, I would recommend opening an issue in the RFC repo as a first step