Express.js alternative built on top of uWebSockets.js

[zaiste]

I'm working on a high(er)-level wrapper on top of this (fantastic) project. It is a response to a few recent requests/questions I stumbled upon here to incorporate features like middlewares, static file handling or request body parsing out-of-the-box, right in uWebSockets.js - in short functionalities that usually come with Express.js.

Some of them were marked as wontfix (which is totally understandable). I'd like to fill in this gap with some higher level abstractions and potentially help out uWebSockets.js to keep its focus.

Also, in one of the recent issues (#81) @alexhultman said:

This project does not compare with Express, it compares with Nodejs itself.
You are essentially moving a large part away from Nodejs by using this code.

@alexhultman please feel free to close this issue if you think it doesn't belong here. My goal was to help out with the issues I reference below.

My project is called Huncwot, it builds on top of uWebSockets.js and it provides:

1. plain JavaScript objects as abstraction for responses (inspired by Clojure's ring)

{ status: '200 OK', headers: {}, body: 'C++ rocks!' }

app.get('/', request => {
  return { status: '200 OK', headers: {}, body: 'C++ rocks!' }
})

2. simpler abstraction for routes, i.e. a function that takes a request and
   returns a response (in response to Error: Returning from a request handler without responding or attaching an abort handler is forbidden! #45)

app.get('/', request => {
   return ok({ a: 1, b: 2 })  // => returns 200 OK with application/json
})

3. function chaining for handlers (as discussed in app.use #31)

app.get('/path', fn1, fn2, ..., fnk, handler)  // => fn1(fn2(...fnk(handler)))

For example, you can validate the body of the incoming request using built-in params helper:

app.get('/path, params({ name: { type: String, required: true }}), request => {
  return <response>
})

For the completeness, it needs setYield to be implemented in uWebSockets.js
(cf. #31 (comment))

4. support for async functions out-of-the-box (cf Is it possible to use asynchronous functions in/as http handlers? #50)

5. built-in request body parser (in response to Congrats + body parser #64 and Need getHeaders() #70). It automatically extracts the method, headers, cookies and params (either request body, dynamic routes or query params)

app.post('/path/:name', ({ params, headers, cookies })=> {
  return <response>
});

Using HTTPie:

http :5544/path/uws?person=alex a=1 b:=2

This returns params as { name: 'uws', person: 'alex', a: '1', b: 2 }

6. built-in file upload (cf. Handling multipart/form-data body #106)

7. static file handling (cf. How do you serve static files properly. #110)

My goal is to keep it tightly integrated with uWebSockets.js and adapt according to
uWebSockets.js' vision.

Also, I share a bit of similar mindset as Alex. This is an alpha project. I do it for fun. It got me even motivated enough to refresh my C++ ...after 15 years. ;) I hope you will enjoy it, but please use it at your own risk - it's not production ready. I won't be able to support you.

[rodrigooler]

@zaiste your idea is very good. In my case I made an alternative based not only on express.js but also on the facilities of zeit/micro, koajs and fastify. Came up with the idea of creating @fearlessjs but is still in beta with some things not yet well defined for production. I believe we had similar ideas but in different contexts

[Annihil]

Exciting!
I wonder how does that compare to sifrr-server?

[zaiste]

@rodrigooler thanks for the kind words! Just to clarify, this project is not « based » on Express.js, it's just an alternative with a relatively different API. Your project looks similar, indeed. I've just glanced the project, but it seems you're focusing on the server-side only. De qualquer forma, otimo trabalho! :)

@Annihil it's very similar to sifrr. I prefer, however, a single package approach. Many separate, independent modules sounds good only in theory; in practice, it is difficult to manage such projects imho.

[Annihil]

Nice project! Too bad it's monolithic and comes with Vue, a back-end only package would have been awesome 😕

[zaiste]

@Annihil Here's just the core engine of Huncwot. I've extracted it to a separate package.

I also plan to remove Vue.js soon, and to replace it with something like Svelte, so it compiles the UI to a minimal set of JavaScript instruction and there is no need to include the run-time in the app bundles.

[slavaGanzin]

@zaiste You should be careful with your dependencies. You take uWS build from scratch with speed in mind and than use a lot of proven to be slow packages like bluebird... It will mitigate sole purpose of using non standard, but fast server

[zaiste]

@slavaGanzin that's a good point! Please consider it work-in-progress. I focused on making something that works in first place; hopefully the improvement will follow. Feel free to join the venture ;)

[ghost]

Hello Zaiste,

This is a big post. I'm trying to dissect it:

My goal was to help out with the issues I reference below.

For the completeness, it needs setYield to be implemented in uWebSockets.js
(cf. #31 (comment))

setYield can definitely be wrapped up, no problem there in fact it should have been.

support for async functions out-of-the-box (cf #50)

This is supported, see examples?

built-in request body parser (in response to #64 and #70). It automatically extracts the method, headers, cookies and params (either request body, dynamic routes or query params)

Some parts are still missing, like receiving chunked encoded data but other than that the user should take care of whatever data you get. Json or anything, multi-part or whatever is up to the user to implement.

built-in file upload (cf. #106)

static file handling (cf. #110)

These are, at best, suitable as examples. File upload / serving is an abstraction over this library that is up to the user.

[aadityataparia]

@Annihil it's very similar to sifrr. I prefer, however, a single package approach. Many separate, independent modules sounds good only in theory; in practice, it is difficult to manage such projects imho.

Just FYI, sifrr-server doesn't change uws's API in any way (no middleware), it just builds functionalities you mentioned on top of it without affecting any other parts/performance where it can. So there is not really any learning curve if you know how to use uWS.

built-in file upload (cf. #106)
static file handling (cf. #110)
body parser

Also mentioning that you prefer single package approach as opposed to sifrr is not really related to this discussion IMO, as this issue only discusses about sifrr-server, which is a single separate library/project/package.

Not related to this issue, but In my experience maintaining them in one monorepo has saved me a lot of time (because of my own structure though, if I had chose to build in a different way, maybe separate repo approach could have been better)

[zaiste]

This is a big post. I'm trying to dissect it:

I appreciate your response!

For the completeness, it needs setYield to be implemented in uWebSockets.js
(cf. #31 (comment))

setYield can definitely be wrapped up, no problem there in fact it should have been.

Great! I'm still in the process of revising my C++ knowledge. I hope to help out either with this or upcoming challenges.

support for async functions out-of-the-box (cf #50)

This is supported, see examples?

Yes, I've phrased that wrongly. My intention was to point out the easy of use from the consumer side, i.e. you can directly use either sync or async handler, without additional steps i.e. explicitly adding onAborted for async handlers. I'm still lacking the knowledge in this area, so maybe hiding that part isn't good idea.

built-in request body parser (in response to #64 and #70). It automatically extracts the method, headers, cookies and params (either request body, dynamic routes or query params)

Some parts are still missing, like receiving chunked encoded data but other than that the user should take care of whatever data you get. Json or anything, multi-part or whatever is up to the user to implement.

built-in file upload (cf. #106)
static file handling (cf. #110)

These are, at best, suitable as examples. File upload / serving is an abstraction over this library that is up to the user.

Yes, I'd also prefer to keep uWebSockets as simple as possible here. I've decided to wrap by default for additional convenience to the end-users.

By the way, is there a particular reason why onData (which provides the incoming data) is on the response, and not the request parameter ?

[Annihil]

By the way, is there a particular reason why onData (which provides the incoming data) is on the response, and not the request parameter ?

I was indeed wondering the same 😄

I do believe we need a decent wrapper to ease the use of uWS.js, for now it's mostly a replacement of the http module + a basic router without middleware (this is not reproach, just a fact, I find uWS awesome).

In the meantime, since GraphQL popularity is rising, I went ahead and created µGQL, a very basic replacement of express-graphql but using uWS.js.
It works great and is ridiculously fast!

[aadityataparia]

@Annihil https://github.com/sifrr/sifrr/tree/master/packages/server/sifrr-server#graphql-server 😂

[Annihil]

@aadityataparia yes I'm fully aware of that!
I'm planning to focus only on GraphQL, replicating express-graphql by adding support to graphiql, accepting query from GET query-string, other body formats (application/x-www-form-urlencoded,
application/graphq), etc 🙂

[aadityataparia]

@Annihil Sounds awesome, I will try to contribute some improvements too :) 🚀 Also since it works with uWS, it will also work with sifrr-server :P

[arputcu]

how would it be possible to implement gzip compression for the http/https response ?

[aadityataparia]

@arputcu you can use zlib to compress, see https://nodejs.org/api/zlib.html#zlib_zlib_gzip_buffer_options_callback

[dalisoft]

@Annihil I also few days ago made own GraphQL Server powered by uWebSockets.js with GraphiQL, Mutation, Variables support. But i trying to make subscription work, are you find solution or your solution offers only for Query/Mutation?

[Annihil]

@dalisoft I haven't looked at it yet, seems a bit challenging indeed.
Yes for now it's just a port of graphql-express.

[dalisoft]

@Annihil Oh, i built it for my own needs, not for challenging. Who needs, uses as yours.
Performance of uWebSockets.js is crazy, very crazy =)

[dalisoft]

I also built own Express.js alternative and made API very similar to Express.js. You can see my library here

[gitcatrat]

If you guys use GraphQL, you might as well use Socket.io too in terms of performance.

GraphQL has to:

• parse query
• build AST (abstract syntax tree)
• walk AST and map it to schema object
• recursively resolve all the resolvers (object and field level)
• do type/null checking for each field, object, etc

Anything else? I don't think Node is particularly good at any of these things.

And for what? So that you could now have huge technical debt (both client and server side), N+1 and caching problem to solve, quite complex throttling and query depth protection to implement, etc. Trust me, you don't have the same problems as Facebook does, you don't need GraphQL and this comes from someone who started his dev career with GraphQL and was like a cult member.

Don't take this too seriously, I'm just bitter that it took me several years to realise that I'm 10x better off without it.

[ghost]

I like you 😌

[Annihil]

I've had good experience with graphQL to be honest, the fact that you can control the shape of the response from the frontend is such a game changer. Implemented correctly, I'm sure gql can reduce bandwidth usage and server load, it's really up to you to make it worth it. But again, it's just a matter of implementation I believe.

[gitcatrat]

Let's do some math for fun to see if bandwidth is really that big of a deal as it's made out to be.

Let's take AWS generic data transfer OUT rate which is ~$0.09 per GB, that's $90 per TB.
Let's assume your monthly bandwidth is 1 TB and average payload is 5Kb which is a lot, especially if compressed.

1,000,000,000 (TB in Kb) / 5 = 200,000,000 requests per month. That's 76 requests per second, every second, day and night.

If GraphQL manages to reduce the payload by 20%, you'll save $18 per month. Note that your total AWS monthly bill would probably be over $1,000 at that request rate (bandwidth, database, compute, DNS, CDN, etc).

If bandwidth was 100 TB, you'd save $1800. That's 20,000,000,000 total requests or 7,605 per second. Congratulations, you're now getting more requests than Twitter gets tweets per second on average and you're saving less than 1 dev salary.

But remember, this is not pure profit:

• your devs now have a lot more to do and think about, mental overhead
• your servers have a lot more to do thanks to GraphQL and you probably need more of those
• your CDN cost is higher because you need to ship some wildly bloated GraphQL client (some are nice and small)

I cannot stress enough that these numbers are bloated because 5Kb compressed payload is a lot of data each request!

---

That being said, I really don't have anything against GraphQL and I don't really care what tech others use. It has its uses.

[Annihil]

That was just one benefits on the top of my head.
Say you have a mobile app, a desktop web app and many other type of apps consuming an API but with different needs, the REST api may require custimized endpoints per type of app, whereas with gql all type of apps should be fine to consume the API. You're saving backend devs, no matter the size of your corp.

[uasan]

That being said, I really don't have anything against GraphQL and I don't really care what tech others use. It has its uses.

GraphQL is good as a declarative language for description interfaces, we describe database models and structures for request/response .

At the start of the service, we compile GraphQL into optimized JS functions and simple JS objects.
In JS runtime, these optimized JS functions are performed, without AST and other complex logic.

GraphQL like TypeScript, for only compile time, not runtime.

[ghost]

I highly doubt there's any optimization at all. GraphQL is a frontend SQL. It means there are endless combinations the client can request. Endless being the permutations of all fields requestable.

[ghost]

That being said - if you're a big company reducing traffic is worth a lot of Benjamins.

[uasan]

I highly doubt there's any optimization at all. GraphQL is a frontend SQL. It means there are endless combinations the client can request. Endless being the permutations of all fields requestable.

No, we use REST API (cached method GET, for mutation PATCH method)
For compact meta programing we use GraphQL, then this compile to client-side JS functions (for web browser client) and server-side JS functions for Node.js (for build SQL query), all limits and validate are hard-coded in the code of these functions.

[game5413]

@zaiste Wow didn't know someone already implement this idea, i'm creating this feature without read another discussion except #483 and implemented as utilities for sifrr-server on private project at my company. I think my version was little bit simple than yours, just add some feature that i think useful for separating logic

app.use(fn1, fn2, fnN); // for adding global middleware
app.use('/profile', fn1, fn2, fnN); // for adding scope middleware

I like that express have ability for stacking handler / middleware, so create same ability for the sake of convenience, also add interceptor into create request method for applied those ability, well i think same that you mentioned above

app.get('/profile', fn1, fn2, fnN);

and with result that global and scope middleware executed first, and last the stack of handler on http request method

[e3dio]

You must be referring to that link which is doing app.any('/*', runMiddlewares), ya I don't do that I define each route, I don't see @game5413 doing that yet, but he seems like the type to blindly follow someone else

[ghost]

Problem is when you attach a critically important middleware to some complex regex rule, messing it up so that some URLs do not match the middleware routing but do match the request handler. This is like, a classic security issue.

Maybe because i'd taste express style middleware, my mind deflected that i should create same ability with same writing style middleware and forgot about simple one.

Exactly. There are many, many reasons why Express is the worst possible role model you can possibly have. Express and Socket.IO were written very early in the Node.js saga and totally exploded in popularity when Node.js did so. Then it just snowballed to insanity where feedback loops of hype create more hype and ultimately land in fanaticism and delusion.

[game5413]

if a middleware has already responded then it should just not call the next middleware, so all it does is remove flexibility to combine middleware stacks and probably impacts performance by running extra code

I'm referring to this code, if already send a respond using end or tryEnd on some middleware, set an variable finished equal true, to determine calling next middleware or not

const enhanceRes = (res) => {
     const originalEnd = res.end.bind(res);
     const originalTryEnd = res.tryEnd.bind(res);
     
     res.finished = false;
     
     res.end = (...args) => {
         originalEnd(...args);
         res.finished = true;
         return res;
     }
     
     res.tryEnd = (...args) => {
          const [ok, done] = originalTryEnd(...args);
          res.finished = done;
          return [ok, done]
     }
}

and cathed on handler.js, in my case variable finished renamed to isSended

const hasRespondEnded = !!res.isSended;
const shouldQueue = !hasRespondEnded && fx;
if (shouldQueue) {
  await fx(res, req);
  next();
}

You must be referring to that link which is doing app.any('/*', runMiddlewares), ya I don't do that I define each route, I don't see @game5413 doing that yet, but he seems like the type to blindly follow someone else

No, i'm not doing app.any for run middleware, handle.js was wrapper for me to not write stacked looked like middleware(anotherMiddleware(anotherMiddleware2)) instead writed like handler(middleware, anotherMiddleware, anotherMiddleware), well that just my opinion to have style looked like that.

Problem is when you attach a critically important middleware to some complex regex rule, messing it up so that some URLs do not match the middleware routing but do match the request handler. This is like, a classic security issue.

You mean ability on Express ? that assign middleware to some route ?

app.use('/user/:id', fn1, fn2, fn3)

[e3dio]

handle.js was wrapper for me to not write stacked looked like middleware(anotherMiddleware(anotherMiddleware2)) instead writed like handler(middleware, anotherMiddleware, anotherMiddleware), well that just my opinion to have style looked like that.

If you don't like the style you can use this reduce function:

app.get('/',m1(m2(route)))

// same thing

app.get('/',stack(m1,m2,route))

const stack=(...middleware)=>middleware.reduceRight((a,b)=>b(a))

For me I prefer the first style because it is clear to me and I don't like an extra 'stack' function, but if you prefer the 2nd style that is an option @game5413 what do you think. Then at least everyone is using the same middleware functions so everyone is on the same page, you just use your preferred style

I'm referring to this code, if already send a respond using end or tryEnd on some middleware, set an variable finished equal true, to determine calling next middleware or not

This is the 3rd time I have explained this to you, if you have a middleware that sends a response and you don't want the next middleware to run, then don't call next() in the middleware, you don't need some external handler.js function to do this for you

[game5413]

app.get('/',m1(m2(route)))

// same thing

app.get('/',stack(m1,m2,route))

const stack=(...middleware)=>middleware.reduceRight((a,b)=>b(a))

For me I prefer the first style because it is clear to me and I don't like an extra 'stack' function, but if you prefer the 2nd style that is an option @game5413 what do you think. Then at least everyone is using the same middleware functions so everyone is on the same page, you just use your preferred style

Yeah, i'm prefer the second one, thanks for alternate option.

This is the 3rd time I have explained this to you, if you have a middleware that sends a response and you don't want the next middleware to run, then don't call next() in the middleware, you don't need some external handler.js function to do this for you

I'm understand your point, but that next() not called next middleware because all condition not equal to true if already send an response will make it stop the queue stack of middleware, but yes it execute some extra code. And, yes that external handler was exaggerate for something like that, in the future i'll use your option at above.