cloudfoundry-community / cloudfoundry-community/node-cfenv
Best practice for leveraging cfEnv?
Nobody has claimed this yet.
- Dominant language
- CoffeeScript
- Stars
- 74
- Forks
- 25
- PR merge metrics
- No merged PRs in 30d
Description
Say I am writing an SDK (just suppose…)
Is the following reasonable, and if so, should it be documented as a best practice?
OLD:
var appEnv = require('cfenv').getAppEnv();
var someClient = require('Some Random Thing').setup({ credentials: appEnv.getServiceCreds(/Something.*/) });
IMPROVED?
var appEnv = require('cfenv').getAppEnv();
var someClient = require('Some Random Thing').setup({ appEnv: appEnv });
implemented within the SDK by:
… function setup(opts) {
if(opts.appEnv && !opts.credentials) { // if appEnv is available, use it
opts.credentials = opts.appEnv.getServiceCreds( someRegex );
}
Any pitfalls? My idea is to reduce the amount of copy and paste user code. User can just pass in appEnv if they have one, otherwise credentials can be supplied.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file or test is named; start with the setup API and OLD/IMPROVED examples in the issue, then review how cfEnv credentials are currently supplied. Done means reaching a decision on the proposed appEnv option, its pitfalls and precedence, and whether the resulting best practice should be documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- coffeescript, node.js
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100