uws-reverse-proxy

This project is an easy-to-use 0-dependency* reverse proxy based on uWebSockets.js. It enables use of uWebSockets.js and any http server (as express, NestJS, Fastify) on the same port.

Tested with:

• uWebSockets.js v20.10.0
• NodeJS v18.0.0

* This package doesn't even depend on uWebSockets.js not to force any version usage, see in examples below. That said, keep in mind that only the last version of uWebSockets.js has been tested.

How does it work?

It basically uses uWebSockets.js as a reverse proxy for all non-websocket traffic and forward it to any http server.

Then it will send the response back to the client without modification.

Why? For what use case?

Don't use this package if you don't really need it.

You pretty much always want your NodeJS app available on only one port (443) for it to be accessible in restrictive NATs.

This project is aimed to provide a solution in restricted server environments such as some cloud platforms like Heroku, where you can't set up a proxy like Nginx or Apache in front of your NodeJS application, and where you often have only one public port available.

If you're not in a similar use case, just set up an Nginx or Apache proxy that will filter the requests to redirect them on the good private port, they will be more efficient and flexible.

Conversely, if your server has to work in restricted server environment or if for whatever reason you want uWebSockets.js to handle all requests without standing behind a proxy, then this package is made for you :)

In the case of express you could use a package like http-proxy-middleware to do the opposite (using express as a reverse proxy to forward requests to uWebSockets.js), but this doesn't seem to work at the time I'm writing this, and it defeats the main advantage of uWebSockets.js: its astonishing performances.

Important note about SSL

If uWebSockets.js and your http servers are on the same machine, you should not create an HTTPS server, as TLS will add a useless overhead in a scenario like this:

1sequenceDiagram
2	participant C as Client
3	box Public
4	participant UWS as uWebSockets.js Reverse Proxy
5	end
6	box Private
7	participant N as Node:http
8	end
9	C->>UWS: HTTPS request
10	activate UWS
11	UWS->>N: HTTP request
12	activate N
13	N->>UWS: HTTP Response
14	deactivate N
15	UWS->>C: HTTPS Response
16	deactivate UWS

Installation

With npm:

1npm install uws-reverse-proxy

With yarn:

1yarn add uws-reverse-proxy

Usage

This section describes some usage scenario. You can even see them in action in the examples repository.

To see all available options, check the code API documentation.

Basic

Simplest use-case: let the reverse proxy create everything on its own, configure your servers afterward.

1const uWebSockets = require('uWebSockets.js');
2const http = require('http');
3
4const {
5	UWSProxy,
6	createUWSConfig
7} = require('uws-reverse-proxy');
8
9const port = process.env.PORT || 80;
10
11const proxy = new UWSProxy(
12	createUWSConfig(
13		uWebSockets,
14		{ port }
15	)
16);
17
18const httpServer = http.createServer((req, res) => {
19	console.log('Incoming request: ', req);
20
21	res.writeHead(200);
22	res.end('Hello world :)');
23});
24httpServer.listen(
25	proxy.http.port,
26	proxy.http.host,
27	() => console.log(`HTTP Server listening at ${proxy.http.protocol}://${proxy.http.host}:${proxy.http.port}`)
28);
29
30proxy.start();
31
32// Configuring the uWebSockets.js app created by the proxy
33
34// Setting up websockets
35proxy.uws.server.ws({
36	upgrade : () => {
37		//...
38	}
39	// ...
40});
41
42// Listening
43proxy.uws.server.listen('0.0.0.0', port, listening => {
44	if(listening){
45		console.log(`uWebSockets.js listening on port 0.0.0.0:${port}`);
46	}else{
47		console.error(`Unable to listen on port 0.0.0.0:${port}!`);
48	}
49});

Second use case: providing already created and listening uWebSocket.js server.

1const http = require('http');
2const { App } = require('uWebSockets.js');
3
4const port = process.env.PORT || 80;
5const httpPort = process.env.HTTP_PORT || 35794;
6const httpHost = process.env.HTTP_HOST || '127.0.0.1';
7
8// Let's imagine that all the setup happen there, including listening
9const httpServer =  http.createServer(/*...*/);
10httpServer.listen(httpPort, httpHost, () => console.log(`HTTP server listening at http://${httpHost}:${httpPort}`));
11
12const uwsServer = App();
13uwsServer.ws({/* ... */});
14uwsServer.listen('0.0.0.0', port, () => { /* ... */ });
15
16const {
17	UWSProxy,
18	createUWSConfig,
19	createHTTPConfig 
20} = require('uws-reverse-proxy');
21
22const proxy = new UWSProxy(
23	createUWSConfig(
24		uwsServer,
25		{ port } // Must be specified to avoid a warning
26	),
27	createHTTPConfig(
28		{
29			port: httpPort, 
30			host: httpHost
31		}
32	)
33);
34proxy.start();

The warning is there as a reminder especially if you use different ports than the default ones.

If you don't want (or can't) provide the port, you can silence the warning using the quiet option:

1const proxy = new UWSProxy(
2	createUWSConfig(
3		uwsServer,
4		{ quiet: true }
5	)
6);
7proxy.start();

With SSL

Given the above examples, just change the options passed to createUWSConfig.

Letting the proxy creating the uWebsockets.js SSLApp:

1const uWebSocket = require('uWebSockets.js');
2const { createUWSConfig } = require('uws-reverse-proxy');
3
4createUWSConfig(
5	uWebSocket,
6	{
7		config: {
8			key_file_name: 'misc/key.pem',
9			cert_file_name: 'misc/cert.pem'
10		}
11	}
12)

Providing a uWebsockets.js SSLApp:

1const { SSLApp } = require('uWebSockets.js');
2const { createUWSConfig } = require('uws-reverse-proxy');
3
4const uwsServer = SSLApp({
5	key_file_name: 'misc/key.pem',
6	cert_file_name: 'misc/cert.pem'
7});
8
9createUWSConfig(
10	uwsServer,
11	{ quiet: true }
12)

Integration examples with Express, Koa, Fastify, Nestjs, Node:http

Please visit the examples repository.

It even contains a standalone mode to help you test uws-reverse-proxy with your own app without changing a line of code for most projects.

Keep in mind that it's... an HTTP reverse proxy. It can forward request to any HTTP server.

A word about performances

Putting a proxy in front of your application always induces a performance penalty. This performance penalty heavily depends on the way you integrate the proxy to your application.

Just keep in mind that contrary to using a proxy like Apache or Nginx, uws-reverse-proxy will only impact the HTTP part of your application. Since it is uWebSockets.js that handle all the trafic, your websockets are directly exposed to the Internet.

This proxy is especially useful for websockets heavy applications in the uses cases you can find in the Why? For what use cases? section.

Performance penalty in function of the integration mode

They are two main ways to integrate the proxy to your application:

• Standalone mode: the most efficient. The proxy and your application are running in two different processes.
• Integrated mode: the least efficient. The proxy and your application are running in the same process.

While you can expect almost no performance penalty in standalone mode, in integrated mode, the performance penalty is about 30% to 45%.

In standalone mode, the performance penalty is comprised between 3% to 10% as long as your HTTP server maximum capacity do not exceed this proxy maximum capacity.

As a matter of fact, in my test environment, the proxy is able to handle up to 45 000 req/s while an Express server is only able to handle 9 500 req/s. So, in this case, the proxy is able to handle more requests than the Express server: you'll see almost no performance penalty.

But if you test the proxy with an uWebSockets.js backend server (which is stupid, but it's to illustrate the point), while the proxy is able to handle up to 45 000 req/s, the uWebSockets.js server is able to handle more or less 250 000 req/s. In this case, you end up with a 500% performance penalty.

I advise you to test the proxy to be sure that it fits your needs and that it's not a bottleneck in your specific case.

That being said, you'll find below a table with the performance penalty I measured in my test environment for the different frameworks I tested. You'll see an average in both standalone and integrated mode as well as no proxy at all.

Performance comparison

Environment:

Component	Specifications
OS	Ubuntu 22.04.2 LTS 64 bits
Node	v18.15.0
RAM	16 Gio
Processor	11th Gen Intel® Core™ i7-11800H @ 2.30GHz × 16

No DNS resolution, all servers will listen on the loopback address.

All results are the average of 5 runs of 10 seconds each by using autocannon with the following command:

1autocannon localhost:7777
2# Or, when testing without proxy
3autocannon localhost:35794

Benchmarks are made with the uws-reverse-proxy-examples repository

• In standalone mode, the proxy is started with PORT=7777 yarn standalone:reverse-proxy, then the target HTTP server is started with yarn standalone:[framework].
• In integrated mode, we start the server with the command PORT=7777 yarn [framework].

Results

Framework	No proxy	Standalone mode	Integrated mode
None (native http module)	18024 req/s	17000 req/s	9803 req/s
Koa	13079 req/s	12400 req/s	8492 req/s
Fastify	12372 req/s	11284 req/s	7817 req/s
Nestjs	9786 req/s	8813 req/s	6153 req/s
Express	9362 req/s	9102 req/s	6375 req/s

For readability, I've rounded the results to the nearest integer. A better view of the performance penalty can be found in the table below based on the results above.

Framework	Standalone mode	Integrated mode
None (native http module)	5.68%	45.61%
Koa	5.20%	35.10%
Fastify	8.80%	36.81%
Nestjs	9.94%	37.12%
Express	2.78%	31.91%

TODO

• PoC (> v1.0.0)
• Refactoring + Clean & stable implementation (>= v2.0.2)
  • Flexible configuration
  • Config validation
  • Config warnings
  • Configurable backpressure threshold
  • Code comments & JSDOC
• Generic reverse proxy for any HTTP/HTTPS server
• Documentation
  • Code API
  • README
  • A demo repository.
• Publish on NPM
• Better error management
  • Allow answering stream errors that are happening before the client response is written with proper HTTP formatted response instead of shutting down the connection like a savage.
  • Allow for errors customization
• When a content-length header is present in the response, using uWebSockets.js tryEnd instead of writeto avoid adding Transfer-Encoding: chunked to every request.
• Edge cases handling regarding proxying (HTTP 100 continue, headers cleanup)
• Testing a node:http client to undici client migration to see performances impact.
• Custom HTTP client implementation to avoid using node:http client.
• More flexibility in requests routing through proxy (add more control options, like a pre-handler to allow or not forwarding based on custom logic.)
• Test uWebSockets.js version agnosticity for all uWebSockets.js versions.
  • Support backward compatibility
• Automated tests included in CI/CD
  • HTTP/1.1 parser tests
• Debugging mode with console logging