Express app requires increase in payload limit, modifying server.js and index.js files

Hello All,

Recently, I started building a function (with the help of AI) in one of the NodeJS projects to allow users to send an email to a unique+dedicated email address with attachments. These emails are forwarded by the receiving email service provider to a dedicated webhook (API endpoint in Wappler app). Once the data is received, the attachments are saved on the app server.

To achieve this, AI suggested setting up an Express App that contained the complete logic of this function (limits on allowed file extensions, upto 3 files, verifying sender information with the saved DB records, saving attachments, writing the final information to a database etc.).

The data is received from the external provider in a JSON format. The maximum payload that is allowed for JSON data per API call in Wappler is 100KB, which is insufficient to cover file sizes upto 5-6MB. So, to get it working, I had to add a limit: '90MB' parameter in the server.js file. A high limit value allows any JSON bloat (between 3-5 times the original file size) when converting a PDF or Image to JSON.

I also needed to change the index.js file to register the express app and make it available on the PORT 3000.

I have come across some discussion around increasing the payload size in the server.js. However, the server.js as well as index.js files gets overwritten during each update. Are there any alternative solutions

  1. to increase the payload limits without modifying the server.js file
  2. to register the express app without altering the index.js file

I have been thinking about a likely solution that can work even with all Wappler updates. But I don't know whether these are workable solutions within Wappler's ecosystem.

1. server.js - add a section to allow optional values. See my comments next to the param limit: '90mb'

app.use(express.urlencoded({ extended: true }));
app.use(express.json({
    verify: (req, res, buf) => {
        req.rawBody = buf.toString()
    },
    limit: '90mb' - permanently add the param `limit` and allow value from {{env.JSON_LIMIT}}}
}));
  • it can be a permanent part of the server.js file and will only allow reading of ENV vars from the config.js file
  • add a new section App Limits or a more appropriate header under Server Connect Settings - add options here such as json payload limit, urlencoded payload limit, any other param options that may need to be modified in the server.js
  • if ENV values are available, then these limits apply, other standard limits apply
  1. index.js - I don't think there is any alternative other than to ignore this file during any wappler update after the initial creation of this file. This is the modified file to register webhook logic in the express app.
// Require the Wappler server logic (Express app)
const server = require('./lib/server');

// Require and register the webhook route logic
const emailWebhook = require('./webhook-server/email-webhook-server');

// Register the webhook endpoint on the main Express app
emailWebhook.register(server.app); // Assumes server exports { app, start }

// Start the main app on port 3000
server.start(3000);

I would love to hear from other users how they have overcome the issues outlined in my post.

I undertand that this requirement may apply only for a limited number of users at this stage. However, as the use of AI becomes more prevalent, users may need to make necessary adjustments in these two files to add advanced functionalities.

Having spent the last month working on IMAP email routines using AI heavily, i am suprised at the AI recommendations.
If the webhook saves the attachments to the server its a pretty simple job to attach them to an email and send.
In fact, the send routine of my new extensions could do that.
Just ask if you want more details.

What is the format if the webhook payload?

Hi Brian,

Thanks for the response.

I'm receiving and saving email attachments on the local app server. The flow of this process is like this:

  1. Users send an email with attachments to a unique email address assigned to them
  1. Emails are received by an external service that parses the email content along with the attachments and POSTs the data to a webhook (API endpoint) in JSON format
  2. The webhook in wappler has the logic verifies the user and converts the JSON data back to original files (PDF, PNG etc.)

So, when the data is POSTed to the wappler webhook, unless the JSON payload limit to receive the data is more than the incoming data, the app is unable to process the POSTed request and fails. That's the reason I had to increase the JSON payload limit in the server.js file.

I tried to increase the payload limit in the webhook, but it didn't apply due to the registration of standard payload limits in the server.js before the webhook payload limits can be registered.

The process I have outlined above is working. But I am happy to look at any alternative approach to achieve this.

If the ability to retrieve the data is available at your external service, I would use the webhook only as a notification, not to actually receive the data.

When your API receives the notification, it then retrieves the data from the external service rather than that large amount of data being in the webhook.

Ideally, you would log the webhook event, return status 200 in order to quickly end the webhook, and then have another process that processes the webhook events -- like a system that polls the db for events to be processed, or even better, the webhook notification creates a bull queue job that runs in the background.

So the full attachment data is returned as a .json response rather than just links to the data?

Yes, the attachments are returned as JSON response.

I have tried increasing the size limits in a route, user_config, inside the express webhook app, and none of these work. The only working solution is to modify the server.js file.

I believe if Wappler team can provide either an option to add limits via config.json or read ENV variables, then both / either of these solutions will be ideal.

Ouch, strange design. I assume you have no control over that, there is no alternative to be passed url links?

The emails are not stored by the external provider. The emails are parsed and forwarded to the API endpoint.