Allow multiple clients to different site (don't rely on global state)

[haggholm]

We have a SaaS platform where we are interested in collecting metrics for more than one Datadog account; for example, we may want to collect our own metrics for internal use, but also send some metrics about jobs to our customers' Datadog accounts.

The problem is that this package implements server configuration as a singleton, in global state. If our internal config and the customer config have different values for the {site} server variable, then setting the value for one will override it in the global state maintained by the API's servers, here.

It would be much more convenient if this state were encapsulated in the client object rather than maintained globally (maybe with global state as the default and for backwards compatibility?). From a crass commercial perspective, it would also help us send Datadog more billable metrics… ;-)

[therve]

Thanks for you request, clarified what I understood. You can have multiple clients, just not to different server sites indeed. It seems like an oversight, we'll have a look.

[haggholm]

After some digging, it looks like you can actually do this with the API as it is by passing in a baseServer parameter when creating a configuration:

    const configuration = v1.createConfiguration({
      authMethods: { apiKeyAuth: apiKey },
      baseServer: new v1.ServerConfiguration("https://{subdomain}.{site}", {
        site,
        subdomain: "api",
      }),
    });

The main problem here might be documentation: your documentation tells the user to set a global value and doesn't mention the fact that you can do it locally. Assuming that the above is correct, that is!

If I were to ask any further improvement of this as a feature, it would be nice not to have to pass in values like "https://{subdomain}.{site}", which is pretty cryptic, or having to specify the subdomain; if createConfiguration() could accept variableConfiguration parameters like {site} and use them to override defaults, it would be a lot easier to read (and perhaps more robust to library changes in the future).

[therve]

baseServer works for some usecases, but not for other (namely ip-ranges and logs intake).