Consider DEPR for New Relic in frontends

[robrap]

This ticket is a stand-in for a Draft DEPR. Either way, this can be used to collect notes/comments without committing to implementing the DEPR.

Background:

• Initially, we were implementing Deprecate and archive edx/new-relic-source-map-webpack-plugin #956.
  • We archived the repo edx/new-relic-source-map-webpack-plugin, but that leaves it unmaintained.
  • This repo is still used by openedx repos.
  • We started clean-up PRs (notes in Deprecate and archive edx/new-relic-source-map-webpack-plugin #956 (comment)), but Adam S. pointed out that there isn't yet a DEPR, and if anyone is using New Relic, removal of this repo makes it nearly unusable.
  • Some additional conversation took place in Slack that I will move to this ticket as comments.

[robrap]

Copied from internal Slack conversation:

@adamstankiewicz wrote:

related question: has the DEPR/removal for New Relic generally been planned/announced already within the Open edX community (beyond the PR code reviews)? If not, is there a plan to work through the official DEPR process before these contributions are merged?

@dianakhuang wrote:

we had this one:

• [DEPR]: newrelic as baseline dependency in Django IDAs openedx/public-engineering#360

@adamstankiewicz wrote:

Does there need to be an equivalent New Relic DEPR for the frontend? This one seems specific to Django IDAs. The concern might be that there could be Open edX site operators that depend on the current New Relic integration in frontend-build who wasn't aware of that Django IDA-focused DEPR? The audiences for DEPRs about Django IDAs vs. frontends may be different?
For example, this DEPR offers a replacement path for the Django IDAs but as far as I can tell there's currently no documented replacement steps for the removal of New Relic from frontend-build for operators to follow.
It also seems that DEPR for Django IDAs isn't so much about removing support for New Relic (i.e., NewRelicBackend still exists) but rather making the New Relic stuff optional (to support other monitoring services), whereas the frontend-build PR seems to be more about removing New Relic entirely. E.g., I'd love to hear more input from the community Frontend Working Group around whether we'd want frontend-build (and soon, frontend-base) to offer optional support for common monitoring tools like edx-django-utils seems to do now vs. removing New Relic entirely.

@robrap wrote:

Thanks @adamstankiewicz.

• Agreed that there is not yet a DEPR for New Relic and the frontends.
  • We've plugged in Datadog to our frontends. Is this a pattern that could be followed as a replacement for operators that still want New Relic?
  • We could create this DEPR, but I'm not sure I want to commit to its entire implementation. Especially if work were required to make frontend observability any more pluggable than it already is (that we used for Datadog).
• The ticket for removal of edx/new-relic-source-map-webpack-plugin was originally smaller scoped.
  • I could also create a DEPR for this smaller scoped work.
  • An alternative would be for someone from the community to fork this repo to the openedx org and take up ownership. The openedx repo should not refer to this edx repo in all cases.
  • @adamstankiewicz: Can you explain more about the added risk of removing this plugin without removing all of New Relic? Are you just referring to source map functionality breaking, and the risk that this would affect New Relic users? Or do you see other risks?

@adamstankiewicz wrote:

The ticket for removal of edx/new-relic-source-map-webpack-plugin was originally smaller scoped.
Can you explain more about the added risk of removing this plugin without removing all of New Relic?

For site operators who might rely on today's default logging service NewRelicLoggingService, removing the source map plugin will make it difficult/impossible for those site operators to debug JS errors in their New Relic instances. The source map uploads make it possible to show un-minified code in the stack traces to make these errors actually useful/actionable.
As long as frontend-build still has first-class support for NewRelicLoggingService, I feel the source map plugin needs to remain as we otherwise break New Relic functionality for site operators who might rely on the remaining NewRelicLoggingService. I don't feel it'd be a good experience for these site operators to have to modify Webpack config files to add back support for uploading source maps on their own when frontend-platform continues to officially support NewRelicLoggingService. Support for the New Relic source map upload is intended to be coupled with the overall support for NewRelicLoggingService.
I agree trying to transfer ownership of edx/new-relic-source-map-webpack-plugin to a openedx repository makes sense in the short term to avoid breakages for site operators while community FWG itself can decide what to do about New Relic on its own.

We've plugged in Datadog to our frontends. Is this a pattern that could be followed as a replacement for operators that still want New Relic?

It could be, yes. But this would likely need to be better documented as the replacement path. If we remove New Relic entirely (not just the source map plugin), there would no longer be a default logging service defined within frontend-platform; frontend-platform would likely need to expose a default, basic logging service that implements the logging service functions, but would otherwise be a no-op.

We could create this DEPR, but I'm not sure I want to commit to its entire implementation. Especially if work were required to make frontend observability any more pluggable than it already is (that we used for Datadog).

Yeah, I agree I wouldn't necessarily propose or recommend frontend-build/base implement optional logging service classes for common telemetry services itself like edx-django-utils, and rather continue to rely on the existing logging service override approach as the replacement path (like we did with DatadogLoggingService).
If New Relic support were removed entirely, I'd largely hope the frontend-focused DEPR is just to try provide site operators who might rely on frontend-build's NewRelicLoggingService today a heads up before it simply gets removed without a more clearly documented replacement path to implement a custom logging service class via env.config.

@robrap wrote:

@adamstankiewicz: Thank you for your answers.

• I (or you or we) could create a Draft DEPR that serves as documentation for these thoughts. I will not push it to RFC status, because I don't want to commit to this work, but at least it would be documented for now.
• If the DEPR were to be created:
  • I'd use "n/a - no RFC commitment" for all of the dates in the DEPR template.
  • Regarding the "Replacement" section, I think we'd want people to be able to plug in observability. This is where your expertise would help.
    • Would we leave an optional implementation for New Relic, like we do in edx-django-utils?
    • Would we remove New Relic from webpack, and how would operators plug in the equivalent?
    • Would we remove the source map plugin, and how would operators plug in the equivalent?
      • Again. could dealing with this single bullet be a smaller scoped deprecation and conversion to something pluggable, as a path toward the larger effort?

[robrap]

[question for 2U] What parts of https://2u-internal.atlassian.net/wiki/spaces/ENG/pages/1008500757/How+to+configure+edX+services+for+Datadog#Context might be relevant for the community for a more general doc about how one might override frontend-logging to inject a different observability tool?

[robrap]

[inform] This was shared in a Slack thread in #openedx-wg-frontend (or #wg-frontend in Open edX Slack).