Description
Summary
In #3945 we added new zero-dependency functional utilities to read and parse environment variables. These new functions supersede the old class based environment service approach. We should should refactor any use of the class based system to the new function based approach.
Why is this needed?
The rationale for the introduction of these utilities as per #3945 is as follows:
[M]ost of the advantage to customers will come in the form of smaller utilities over time, since we'll be able to use these helpers across other Powertools for AWS utilities and replace the existing EnvironmentVariablesService class-based model which is extremely verbose and requires props drilling if you want to access env variables deep into an inheritance stack.
This change will help us to eventually remove the EnvironmentVariablesService
entirely from the code base.
Which area does this relate to?
No response
Solution
Currently the only place where the service is used in the Event Handler package is the AppSync events Router class:
import { EnvironmentVariablesService } from '@aws-lambda-powertools/commons';
// ...
public constructor(options?: RouterOptions) {
this.envService = new EnvironmentVariablesService();
const alcLogLevel = this.envService.get('AWS_LAMBDA_LOG_LEVEL');
// ...
this.isDev = this.envService.isDevMode();
}
This could be refactored like so:
import { getStringFromEnv, isDevMode } from '@aws-lambda-powertools/commons/utils/env';
public constructor(options?: RouterOptions) {
const alcLogLevel = getStringFromEnv({
key: 'AWS_LAMBDA_LOG_LEVEL',
defaultValue: '',
});
// ...
this.isDev = isDevMode();
}
Acknowledgment
- This request meets Powertools for AWS Lambda (TypeScript) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status