Error Tracking and Performance Monitoring Across JavaScript Environments

Sentry's JavaScript SDK is split into environment-specific packages to handle the unique challenges of client-side, server-side, and framework-specific development. While @sentry/browser, @sentry/node, and @sentry/react share a common core, they expose different tools optimized for their runtime. Let's compare how they handle initialization, error capturing, performance tracing, and context enrichment.

🚀 Initialization: Environment-Specific Defaults

All three packages use the Sentry.init method, but they automatically configure different integrations based on the environment. This means you get relevant data out of the box without manual setup.

@sentry/browser configures integrations for the DOM and browser APIs.

• It captures unhandled promise rejections and global script errors.
• It records breadcrumbs from console logs and network requests.

// @sentry/browser: Client-side init
import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  // Automatically adds BrowserTracing and Breadcrumbs integrations
  integrations: [Sentry.browserTracingIntegration()],
  tracesSampleRate: 1.0,
});

@sentry/node configures integrations for the Node.js runtime.

• It captures uncaught exceptions and unhandled promise rejections at the process level.
• It instruments HTTP servers to trace incoming requests automatically.

// @sentry/node: Server-side init
import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  // Automatically adds Http and Express integrations if detected
  integrations: [Sentry.httpIntegration()],
  tracesSampleRate: 1.0,
});

@sentry/react builds on top of the browser SDK with React-specific defaults.

• It includes the same browser integrations but adds React Profiler support.
• It is optimized to work within the React component lifecycle.

// @sentry/react: React-specific init
import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  // Includes React-specific error handling capabilities
  integrations: [Sentry.browserTracingIntegration(), Sentry.reactRouterV6BrowserTracingIntegration()],
  tracesSampleRate: 1.0,
});

🛡️ Error Capturing: Global vs Component Level

How errors are caught differs significantly depending on whether you are in a global runtime, a server process, or a component tree.

@sentry/browser relies on global window handlers.

• It listens to window.onerror and window.onunhandledrejection.
• It captures errors that bubble up to the global scope but might miss isolated component failures.

// @sentry/browser: Global capture
import * as Sentry from "@sentry/browser";

// Manually capture an exception
try {
  riskyOperation();
} catch (err) {
  Sentry.captureException(err);
}

@sentry/node relies on process-level handlers.

• It listens to process.on('uncaughtException').
• It is critical for ensuring the server reports crashes before restarting or exiting.

// @sentry/node: Process-level capture
import * as Sentry from "@sentry/node";

// Manually capture an exception in an API route
app.get("/user/:id", async (req, res) => {
  try {
    const user = await getUser(req.params.id);
    res.json(user);
  } catch (err) {
    Sentry.captureException(err);
    res.status(500).send("Error");
  }
});

@sentry/react provides an ErrorBoundary component.

• It catches errors during rendering, lifecycle methods, and constructors of child components.
• This is vital because React errors often do not bubble to the global window handler.

// @sentry/react: Component-level capture
import * as Sentry from "@sentry/react";

function App() {
  return (
    <Sentry.ErrorBoundary fallback={<p>An error has occurred</p>}>
      <Profile />
    </Sentry.ErrorBoundary>
  );
}

// Or manually capture within a hook
function Component() {
  const handleError = (error, eventId) => {
    console.log("Error captured:", eventId);
  };

  return <Sentry.ErrorBoundary onError={handleError}>...</Sentry.ErrorBoundary>;
}

⚡ Performance Tracing: Requests vs Spans

Performance monitoring is central to all three packages, but the focus shifts from user-centric metrics to server-centric latency.

@sentry/browser focuses on Web Vitals.

• It tracks Largest Contentful Paint (LCP) and First Input Delay (FID).
• It traces long tasks and network requests made by the browser.

// @sentry/browser: User-centric tracing
import * as Sentry from "@sentry/browser";

Sentry.startSpan({ name: "myFunction" }, () => {
  // Code to measure
  doSomething();
});

@sentry/node focuses on Request Latency.

• It creates a transaction for every incoming HTTP request.
• It traces database queries and file system operations within that request.

// @sentry/node: Request-centric tracing
import * as Sentry from "@sentry/node";

Sentry.startSpan({ name: "db-query" }, async () => {
  // Database operation
  await db.query("SELECT * FROM users");
});

@sentry/react focuses on Component Rendering.

• It integrates with the React Profiler to measure render times.
• It helps identify slow components that cause UI lag.

// @sentry/react: Render-centric tracing
import * as Sentry from "@sentry/react";

function SlowComponent() {
  return (
    <Sentry.Profiler name="SlowComponent">
      <div>Complex UI</div>
    </Sentry.Profiler>
  );
}

🏷️ Context Enrichment: User and Tags

Adding context to errors helps developers filter and debug issues faster. All three packages share the same API for setting context, ensuring consistency across the stack.

@sentry/browser sets context for the end user.

• Useful for identifying which customer encountered a bug.
• Data persists for the session in the browser.

// @sentry/browser: Set user context
import * as Sentry from "@sentry/browser";

Sentry.setUser({ id: "123", email: "user@example.com" });
Sentry.setTag("page_type", "checkout");

@sentry/node sets context for the request or server.

• Useful for identifying which API endpoint or tenant caused an error.
• Data is often scoped to the specific request lifecycle.

// @sentry/node: Set request context
import * as Sentry from "@sentry/node";

Sentry.setUser({ id: "123" });
Sentry.setTag("environment", "production");

@sentry/react sets context within the component tree.

• Useful for tracking state or props that led to an error.
• Can be combined with React Context for automatic tagging.

// @sentry/react: Set context in component
import * as Sentry from "@sentry/react";

function Dashboard() {
  Sentry.setTag("dashboard_view", "analytics");
  return <div>...</div>;
}

🌱 Similarities: Shared Core SDK

Despite their environment-specific features, all three packages rely on the same underlying JavaScript SDK. This ensures a consistent developer experience when switching between frontend and backend code.

1. 🔗 Consistent API Surface

• Methods like captureException, captureMessage, and setContext work identically.
• Reduces the learning curve for full-stack developers.

// Works in browser, node, and react
Sentry.captureMessage("Something happened");
Sentry.setContext("character", { name: "Mario", level: 5 });

2. 🔒 Security and Privacy

• All packages support data scrubbing to remove sensitive information.
• You can configure rules to strip PII (Personally Identifiable Information) before sending.

// Configured in init for all packages
Sentry.init({
  dsn: "...",
  beforeSend(event) {
    // Scrub sensitive data
    if (event.request) {
      delete event.request.cookies;
    }
    return event;
  },
});

3. 📦 Release Tracking

• All packages support associating errors with specific code releases.
• Enables features like suspect commits and resolving issues in version updates.

// Set release in init for all packages
Sentry.init({
  dsn: "...",
  release: "my-project@1.0.0",
});

4. 🛠️ Source Maps Support

• All packages de-minify stack traces using source maps.
• Requires uploading source maps to Sentry via CLI or integration.

# Command line usage is the same for all
sentry-cli sourcemaps upload ./dist

5. 🧩 Extensible Integrations

• All packages support custom integrations to extend functionality.
• You can write logic to run before an event is sent.

// Custom integration example
const myIntegration = {
  name: "MyIntegration",
  setupOnce() {
    // Custom setup logic
  },
};

Sentry.init({
  integrations: [myIntegration],
});

📊 Summary: Key Differences

💡 The Big Picture

@sentry/browser is the foundation for client-side tracking. Use it when you need a lightweight solution for standard web pages or when you are not using a framework with a dedicated SDK. It gives you direct access to browser internals without extra abstraction.

@sentry/node is the backbone for server-side observability. It is non-negotiable for Node.js backends, ensuring that errors occurring on the server are not invisible. It focuses on request lifecycles and infrastructure health.

@sentry/react is the specialized tool for modern frontend development. It bridges the gap between generic browser tracking and the specific needs of React applications, particularly regarding component errors and rendering performance.

Final Thought: In a full-stack application, you will often use @sentry/node on your API server and @sentry/react on your frontend. They work together to provide a complete trace from the user's click to the database query, allowing you to debug issues across the entire system with a single tool.