The demands of a tight production schedule can make it difficult to produce consistent, readable, and concise code in the lead-up to a manual code review. This often makes the process stressful — if not outright dreaded. Standard tests are a critical part of development that verify that our code produces the expected outputs. But great tests don’t always lead to good code.

In the modern web, the JavaScript you write is often down-compiled using a compiler like Babel to make sure your JavaScript is compatible with older browsers or environments. In addition, if you are using TypeScript (like the Sentry SDK’s do) or something similar, you’ll have to transpile your TypeScript to JavaScript.

Developers started to notice just how big our JavaScript package was and yeah, we knew. We weren’t ignoring the issues; after all, we don’t want the Sentry package to be the cause of a slowdown. But to reduce our JavaScript SDK package size effectively we had to account for shipping new capabilities, like being able to manage the health of a release and performance monitoring, while maintaining a manageable bundle size. After all, new features == bigger package - usually.

Minification is the technique of terminating all undue extra characters from the source code. This method reduces file sizes, allowing for faster load times and less bandwidth load. Less code appearing in front-end web pages also leads to a more compact, faster-loading website. Most importantly, minification speeds up web pages for users on limited data plans, allowing them to enjoy your content with less worry about exceeding their download quota.

Users nowadays demand the greatest possible experience, which implies top-notch performance. Smooth scrolling, prompt interaction responses, a fast page load time, and flawless animations are all things they anticipate. Local profiling to identify performance issues is convenient, but it only provides a limited amount of information. While things may run smoothly on our high-end developer machines, the user may be dealing with poor hardware and a bad experience.

In this tutorial, we will go through a working example of a NestJS application auto-instrumented with OpenTelemetry. In our example we will use a simple application that outputs “Hello World!” when we call it in the browser. We will instrument this application with OpenTelemetry’s Node.js client library to generate trace data and send it to an OpenTelemetry Collector. The Collector will then export the trace data to an external distributed tracing analytics tool of our choice.

OpenTelemetry (OTel) is an emerging industry standard that dev teams use to instrument, generate, collect, and export telemetry to better understand software performance and behavior. At Helios, we leverage OTel to provide developers with actionable insights into their code within distributed systems. We give them visibility into how data flows through their applications, enabling them to quickly identify, reproduce and debug issues in their flows.