How to install Sentry on the Back-end (NodeJS)

How would you solve this issue if you don’t want to use the CDN?

Go to the JS file on CDN’s URL, and download the file. Then use it as a local file in your project.

Makes sense I suppose. Am I misinterpreting the docs of Sentry then? I thought they were saying we can use their npm package for the frontend

For that to work you need to use something like browserify, grunt, webpack, etc

We moved the sentry code into an external file to prevent Wappler to overwrite our custom code in server.js during an update of Wappler.


// JavaScript Document

const Sentry = require('@sentry/node');
const Tracing = require("@sentry/tracing");

exports.handler = function (app) {
        dsn: "CHANGE_ME",
        integrations: [
            // enable HTTP calls tracing
            new Sentry.Integrations.Http({tracing: true}),
            // enable Express.js middleware tracing
            new Tracing.Integrations.Express({app}),
        environment: process.env.MODE,

    // RequestHandler creates a separate execution context using domains, so that every
    // transaction/span/breadcrumb is attached to its own Hub instance
    // TracingHandler creates a trace for every incoming request

1 Like

Maybe we should add some out of tge box integration to Sentry in Server Connect @patrick


@Eldynn Thanks - I’m just wondering if the app.use(Sentry.Handlers.errorHandler()); shouldn’t be put in here? image

After I’ve moved that line to the extension - it doesn’t seem to capture a 500 error.

I think that line needs to be run at the last route, which might not be possible in this way(?)

How do you trigger your error?

If it doesn’t work then we need to revert and hook directly into server.js. Maybe the Wappler team will do the Sentry integration and it will fix this.

Sentry should be initialized as early as possible.

By loading a server connect that tries a DB update query that doesn’t work. It’s trying to update a record that doesn’t exist.

I’m quite sure it has to do by the fact that the code in /extensions is loaded too early for that error. Probably the same reason why the wappler devs load the error codes at the bottom of server.js

@JonL So in the server.js?


1 Like

I think the way @Eldynn has it with the external file is the best way. The custom routes are loaded before the api routes, it is important that Sentry comes before other routes. Also the external file will never be updated by an Wappler update, so it is more future proof.

@patrick It doesn’t catch all errors though this way. It did when it was set up like in this screenshot How to install Sentry on the Back-end (NodeJS)

(So I put the app.use(Sentry.Handlers.errorHandler()); where the arrow is pointing.)

So I think there needs to be a deeper integration

I see, checked the documentation and the error handler should indeed be applied after all the routes, but before our error handler. Will see if we can maybe provide more hooks for you, so that you not need to edit our code.


That would be amazing @patrick thanks!

With the upcoming update you can have in your custom route next to exports.handler an exports.before and exports.after where the before is like the handler and comes before the generated routes and the after comes after all the routes are generated.

So code would become like:

const Sentry = require('@sentry/node');

exports.before = function(app) {
  Sentry.init({ dsn: "CHANGE_ME" });

exports.after = function(app) {

Save this to extensions/server_connect/routes/sentry.js.


@patrick Thanks!!!

Implemented in Wappler 3.9.5