You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our agent has an instrumentation facilitator concept we call "shims." These shims accept a DSL of varying types that describe how a thing should be instrumented. The shim will interpret the DSL and do the appropriate work to create the instrumentation for the thing being instrumented. We call these DSLs "specs."
The current state is that all of these specs are object literals scattered throughout the codebase. As an example, here is a spec in our OpenAI instrumentation:
The issue with this is that it requires hard won knowledge to know which spec shape is appropriate and what constitutes a valid object to meet the requirements. Further, none of our known spec types are documented. Thus, engineers new to the codebase, and even those familiar with it, have a difficult time learning what is being done when a spec is used, and an even more difficult time understanding the effect the chosen spec will have. Therefore, we should refactor the spec definitions into class style objects and document them as thoroughly as we can.
Acceptance Criteria
Refactor all known specs into class style objects.
Update known usages of the current traditional function style specs into the refactored class style. See
Add jsdoc blocks to all new objects and object fields so that engineers have some documentation to consult around specs.
Update at least one instrumentation to utilize the new spec objects as an example for new code going forward.
Design Consideration/Limitations
With the large surface of existing code, it is not feasible to discover and covert all object literal spec instances to the new object style in a single pull request. We will need to update instances as we encounter them in the future, and possible whittle the scope down through subsequent "down time" chores.
The text was updated successfully, but these errors were encountered:
Description
Our agent has an instrumentation facilitator concept we call "shims." These shims accept a DSL of varying types that describe how a thing should be instrumented. The shim will interpret the DSL and do the appropriate work to create the instrumentation for the thing being instrumented. We call these DSLs "specs."
The current state is that all of these specs are object literals scattered throughout the codebase. As an example, here is a spec in our OpenAI instrumentation:
node-newrelic/lib/instrumentation/openai.js
Lines 270 to 289 in 1fb85a6
The issue with this is that it requires hard won knowledge to know which spec shape is appropriate and what constitutes a valid object to meet the requirements. Further, none of our known spec types are documented. Thus, engineers new to the codebase, and even those familiar with it, have a difficult time learning what is being done when a spec is used, and an even more difficult time understanding the effect the chosen spec will have. Therefore, we should refactor the spec definitions into
class
style objects and document them as thoroughly as we can.Acceptance Criteria
class
style objects.function
style specs into the refactoredclass
style. Seenode-newrelic/lib/shim/specs/index.js
Lines 47 to 95 in 1fb85a6
Design Consideration/Limitations
With the large surface of existing code, it is not feasible to discover and covert all object literal spec instances to the new object style in a single pull request. We will need to update instances as we encounter them in the future, and possible whittle the scope down through subsequent "down time" chores.
The text was updated successfully, but these errors were encountered: