nanoexpress VS gitlab

Great experience with it. The examples in the repo, the issues and discussions sections, and the documentations are all very helpful. Alex and the other users are also quite hands-on in replying on each and every issue and discussion there.

We have some thin wrapper for uWebSockets.js that lets us do the following:

- parse request json

- parse request multipart data

- serve response json

- serve response buffers

- serve response streams

- serve response static files

- support async handler

- support multiple async handlers (middlewares)

links are here

- https://github.com/joshxyzhimself/modules/blob/main/uwu.mjs

- https://github.com/joshxyzhimself/modules/blob/main/uwu.d.ts

- https://github.com/joshxyzhimself/modules/blob/main/uwu.test...

internally we just serve http, then it goes through caddy or haproxy depending on the project's needs such as tls, caching, etc.

there are other similar projects too that tries to deliver express-like api:

- https://github.com/kartikk221/hyper-express

- https://github.com/nanoexpress/nanoexpress (defunct)

use better performant node framework. (fastify or https://nanoexpress.js.org/ (if it is small app can handle (150k req/s))

Check also https://github.com/nanoexpress/nanoexpress

To demonstrate what I mean, example is-http-code:

Since the relevant code appears to be in the "ee" directory <https://gitlab.com/gitlab-org/gitlab/-/blob/v16.11.0-ee/ee/l...> and is not present in the foss repo, I'm guessing the answer is no, at least for now. They do have a history of "releasing" features from EE back to CE but my suspicion is not for LLM stuff

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that https://hub.docker.com/layers/multiarch/qemu-user-static/7.2... actually mutates the binfmt_misc in buildx's context in order to exec the static copy of qemu in it https://github.com/multiarch/qemu-user-static/blob/v7.2.0-1/...

and, that the buildx plugin itself has some qemu magick in it, which got addressed in a minor version bump but I couldn't track down the relevant GitHub issue this second (I've flushed it from my mind, only recalling that there were a lot of actors in that tire fire)

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...