This PR adds a new entrypoint to the distro, that will allow using it in a way that ensure init is completed before the module is require-ed.
This is important especially when the distro is injected by the operator, and we want to avoid the user having to change their code and run something like:
import * as lumigo from '@lumigo/opentelemetry';
lumigo.init
.then(()=>{
// From this point on you are guaranteed that the SDK is initialized.
})
.catch(err => {});
How does it work?
By using a Node (> 12) feature called exports, that allow require-ing the distro in two different ways:
require("@lumigo/opentelemetry) - the existing, default method where an init promise must be awaited. This is unchanged, to avoid breaking existing users.
2.require("@lumigo/opentelemetry/sync)- the new, synchronous entrypoint that transforms init into a sync function, calls it and waits for it to complete. This incurs a penalty (yet almost unnoticeable) on the app startup, as it blocks the main thread until the init logic completes, but makes sure there no logs / traces are sent before the distro is fully initialized.
How would users use it?
By running node -r @lumigo/opentelemetry/sync.
Using the K8s operator - by issuing a new release that either uses @lumigo/opentelemetry/sync by default, or allows choosing between the modes via Helm installation values / CRD config.
This PR adds a new entrypoint to the distro, that will allow using it in a way that ensure
init
is completed before the module isrequire
-ed. This is important especially when the distro is injected by the operator, and we want to avoid the user having to change their code and run something like:How does it work?
By using a Node (> 12) feature called exports, that allow
require
-ing the distro in two different ways:require("@lumigo/opentelemetry)
- the existing, default method where aninit
promise must be awaited. This is unchanged, to avoid breaking existing users. 2.require("@lumigo/opentelemetry/sync)
- the new, synchronous entrypoint that transformsinit
into a sync function, calls it and waits for it to complete. This incurs a penalty (yet almost unnoticeable) on the app startup, as it blocks the main thread until theinit
logic completes, but makes sure there no logs / traces are sent before the distro is fully initialized.How would users use it?
node -r @lumigo/opentelemetry/sync
.@lumigo/opentelemetry/sync
by default, or allows choosing between the modes via Helm installation values / CRD config.