Closed wrumsby closed 3 years ago
It is correct that plugins from the legacy lib are not directly transferable to this SDK, but it is possible in this SDK to apply interceptors to the underlying axios client.
e.g. where client
is your CloudantV1
instance
client.requestWrapperInstance.axiosInstance.interceptors.request.use(
function(request) {
console.log(`*** Print request headers ${JSON.stringify(request.headers)}`);
return request;
});
I'll follow-up with the node-sdk-core team on the likely long-term stability of accessing the underlying axios instance directly in this way, but in general interceptors are a valuable feature to have. It just makes more sense for them to be provided via the HTTP client or core than a custom model per SDK.
We've now merged node core 2.13.0 that has been updated via https://github.com/IBM/node-sdk-core/pull/155 to add a getHttpClient()
function to access to the underlying axios instance.
So from the next release the way to do this will be:
client.getHttpClient().interceptors
The "official" way to get the axios instance:
client.getHttpClient()
is available from the 0.0.18 release.
Is your feature request related to a problem? Please describe.
Given the plan to not support plugins in this SDK we're going to lose the ability to rely on plugins we use if/when we transition from
@cloudant/cloudant
to this library.Describe the solution you'd like
Currently we have an internal plugin that sends information to New Relic (our monitoring solution) about the class of requests (e.g. global query, read, etc.) made so that we have some visibility into this, we can alert on this, we can understand how code changes impact this, etc.
We'd like to retain this visibility and we'd like to be able to use the new SDK (once it reaches 1.0.0).
Describe alternatives you've considered
Keep using the
@cloudant/cloudant
- we'd prefer not to.Reimplement New Relic dashboards - with a little bit of effort I think we could update how our dashboards and alerts are configured to be able to determine the request class from the HTTP method and request URI (if we do this I'll make an effort to blog about this or similar so that others can find the solution).
Additional context
As above I suspect we might be able to reimplement our dashboards to get this information, but I wanted to create visibility into this being a use case that we currently take advantage of when using
@cloudant/cloudant
in case others have similar needs and so that people working on this library have some more context.