Programming

23042 readers

397 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

Brahma-Firelight An Ultra Fast Node.js HTTP Framework (programming.dev)

submitted 3 weeks ago by SowmyaAce786@programming.dev to c/programming@programming.dev

5 comments fedilink hide all child comments

It's been a long time since 2023, when Bun.js arrived and disrupted the JavaScript world. During that time, I was working on something unusual—something that encourages all JS developers to write API code that actually runs on top of Rust.

I gave it my best and eventually published this framework on npm. Many people asked for async support, and after countless sleepless nights, I finally achieved it. Meet Brahma-JS (brahma-firelight) one of my finest creations that replaces Node.js tcp / http module with Rust's Tokio and Hyper library inspired from Deno runtime. Also I tested against the fastest rust frame work may-mini-http.

May-MiniHTTP Benchmarks

Running 10s test @ http://127.0.0.1:8080/
  1 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.70ms  812.42us  20.17ms   97.94%
    Req/Sec   117.65k     7.52k  123.40k    88.00%
  1171118 requests in 10.08s, 115.04MB read
Requests/sec: 116181.73
Transfer/sec:     11.41MB

Brahma-JS Benchmarks

Running 10s test @ [http://127.0.0.1:2000/hi](http://127.0.0.1:2000/hi)
1 threads and 200 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
Latency     1.51ms  479.16us   7.89ms   78.17%
Req/Sec   131.57k     9.13k  146.78k    79.00%
1309338 requests in 10.00s, 186.05MB read
Requests/sec: 130899.58
Transfer/sec: 18.60MB

Oh sure, just another framework casually doing 130k+ requests/sec. No big deal. Totally normal. Definitely not powered by a Rust beast disguised as friendly JavaScript.

Now I have released v1.5 A stable release with support for Mac, Linux and Windows too. You can give a try by starting

npm i brahma-firelight

If you find this framework useful plz do share your thoughts and feedbacks.

Npm : https://www.npmjs.com/package/brahma-firelight

Github: https://github.com/Shyam20001/rsjs

top 5 comments

sorted by: hot top controversial new old

[–] fxdave@lemmy.ml 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

How much overhead does a simple request handler have with Brhama and with Express in ms?

It matters because most of my endpoints are IO heavy. I assume the framework cost is negligible compared to that, and if it is negligible for typical use-case, then what use-cases do you see where it matters most?

[–] SowmyaAce786@programming.dev 1 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

If you take any Node.js framework like Express, Fastify, or Hono, they run on a single core by default. That’s the biggest overhead unless you explicitly use clustering.

BrahmaJS, on the other hand, provides upgraded I/O and TCP modules built on top of Rust’s Tokio runtime, which is far more efficient than Node.js. By default, BrahmaJS runs in a multithreaded mode, utilizing all available CPU cores without needing Node.js clustering.

Another key advantage is that heavy tasks like body parsing are handled by Hyper. This means your Node.js handlers receive a cleaned request and you can simply return your response using async/await.

The only overhead comes from the N-API thread-safe function, which manages data transfer between the Node.js world and the Rust world—but this overhead is minimal.

Since all your endpoints are io heavy brahma Js can offer you quick body parsing and micro milliseconds perf compared to express undoubtebly.

[–] fxdave@lemmy.ml 2 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

By IO heavy I meant db operations or other external requests. When the request handler starts, it waits for the IO to be completed. While it waits, it can accept other requests and so on, so the bottleneck is the IO in my case, not the request parsing.

I imagine it like this (imaginary numbers):

DB operation: 20ms
Express request handler: 1ms
Brhama request handler: 0.5ms

Which case, it wouldn't matter which http framework to use. However, there are probably other use-cases.

[–] SowmyaAce786@programming.dev 3 points 3 weeks ago (1 children)

Yeah that's true dB async ops are unpredictable. But brahma guarantees you fast api. Non blocking yet u can run multi thread without cluster so you are utilizing all cores for sure. Let me share one thing parsing a large json payload in express literally tedious where as brahma does that within few micro seconds. So you no need to wait longer and continue your focus on async works.

[–] fxdave@lemmy.ml 3 points 3 weeks ago

So, for example, online editors that store state in huge jsons and has frequent backup can benefit from it. That's actually great, good luck with it!