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

  • fxdave@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    21 hours ago

    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.devOP
      link
      fedilink
      arrow-up
      2
      ·
      17 hours ago

      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
        link
        fedilink
        arrow-up
        2
        ·
        13 hours 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!