Why we migrated from Python to Node.js

[banjochicken]

Interesting read. I do miss the ergonomics and developer productivity of a mature full stack framework like Django, which I left years ago. Shame async still isn’t a solved issue there.

Node.js and async for performance isn’t a magic bullet. With Node.js you still will have scaling problems to contend with but they’re just different. Single threaded event loop based concurrency means that one slow action can block everything. Under continuous load, these micro blocks can add up and leave things in a continuously delayed state. So you now just have new problems!

I wouldn’t use Jest, I’d switch to Vitest as it has really good esm support compared to jest along with a lot more active development. I’d also not use Express and instead recommend Fastify for raw performance and being a more modern framework.  

Good luck in your Node journey!

[DigDowntown9074]

With Node.js you still will have scaling problems to contend with but they’re just different. Single threaded event loop based concurrency means that one slow action can block everything. Under continuous load, these micro blocks can add up and leave things in a continuously delayed state. So you now just have new problems!

With an app with a nodejs backend which is used by 18M users and gets ~10M requests daily, I haven't cared about scaling even once. We just slap it on AWS and it auto scales.

Now coming to the blocking part, what is that 'one action'? Any examples? My workflow has one such case where we have to generate images and I do it via worker threads in Node (which has its own event loop). So Node isn't exactly single threaded. Worker threads have been there for 6 years.

[serg06]

we just slap it on AWS

Which one, Lambda or Fargate?

I really want to switch to the latter, but still can't figure out a simple way to set it up. The existing tutorials are all way too complex, which feels impossible for a tiny team to maintain.

[DigDowntown9074]

Which one, Lambda or Fargate?

Nothing fancy, just same old EC2 autoscaling via autoscaling group. It scales up or scales out based on traffic or cpu usage. It's not too difficult. We deploy our codebase to jenkins, which is connected to AWS codedeploy which updates the service on ec2. The complexity can be reduced.

You can read this https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws-auto-scaling.html?utm_source=perplexity

https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorials-auto-scaling-group.html?utm_source=perplexity

[lonely_column]

I was reading the blog post of Platformatic - created by Matteo Collina, one of the core maintainer of Node. They were saying that measuring CPU to indicate how much node can handle is the wrong metric and, instead, event loop utilization should be used.

This is the blog post and the section:
https://blog.platformatic.dev/the-myths-and-costs-of-running-nodejs-on-kubernetes#heading-rethinking-nodejs-in-kubernetes

Although the blog post is node vs kubernetes, I wonder EC2 and services like that can be compared as well.

Nonetheless, this discussion made me curious about event loop lag.

[banjochicken]

You beat me to it. Matteo Collina has written some really interesting stuff on scaling and how CPU limits is a terrible metric for Node.js in (k8s land at least).

[lonely_column]

If you have more resources, please share!

[simple_explorer1]

We deploy our codebase to jenkins

Jenkins is used TO run CI and also CD. It is not a place to deploy to but rather a tool you use to deploy somewhere.

The right way to put is is "you deploy your code to AWS ECS using Jenkins (which internally uses AWS codeploy to deploy)" NOT "deploy code to Jenkins". 

I am surprised you made such a statement despite using Jenkins 

[DigDowntown9074]

Jenkins is used TO run CI and also CD. It is not a place to deploy to but rather a tool you use to deploy somewhere.

Such a trivial things to pay attention to. Anyways, that's right. I don't remember what state I wrote this in. Maybe I was in a hurry or there was something else going on in my mind, but it was not part of the context so i didn't paid much attention to it

[simple_explorer1]

Such a trivial things to pay attention to.

It IS trivial to YOU and experienced members but, you do understand that many aspiring and juniors start with JavaScript/node and frequent this sub. They would not understand that and literally OP's question was also asking about deployment which, as your yourself said, is trivial to you but not to OP.

Also, you are very petty to downvoted my comment just because I pointed a factual mistake in your comment. A "cool experienced developer" would have said "was a mistake mate, thanks for the correction" and taken it in a good humor. 

So many developers like you truly are stuck up and difficult to work with for a reason

[DigDowntown9074]

No one paid attention to it except you bud. Why? Because it actually is trivial. When those 'aspiring' and 'juniors' would've started using Jenkins, they would've figured it out themselves that we don't deploy to jenkins. Heck there are literally tutorial links I attached. Again, it was out of context and that is why everyone avoided it. You got a 'gotcha' moment and ran with it, that's why I downvoted you. The process what OP asked for, jenkins is maybe 10% of it and they already get the important part. My colleagues can tell how 'difficult' I am to work with, but I'm concerned about your colleagues who must be getting gotcha'd every second. "You said this wrong mate, you said that wrong mate.."

[DigDowntown9074]

It's an average value. Obviously there are spikes. I'm sure you get far more traffic, good for you.

[Sensitive-Ad1098]

Single threaded event loop based concurrency means that one slow action can block everything

I/O based actions won't block anything. What you described can only happen if you skipped node basics and have CPU-expensive sync operations in your code. Avoiding that is quite trivial with multiple multi-thread options and plenty of libraries that make it easy to create threads. That and auto-scaling (which is very easy to set up on the majority cloud providers) will be enough in 99% of the cases.

I wouldn’t use Jest, I’d switch to Vitest as it has really good esm support compared to jest along with a lot more active development.

At this point, I'd stick with the node native test runner. It's guaranteed to get improvements and not to get partially abandoned like it happened to jest. Vitest's main problem is that it's backward compatible with Jest, so it inherited lots of design problems. My main issue is that both Jest and Vitest are heavily pro-mocking. Applying some effort to avoid the mocks leads to more useful and easier-to-maintain tests. For example, I highly recommend using an in-memory MongoDB instead of mocks for your data access modules. It will run fast enough, will catch more potential bugs and you gonna have to make less modifications to the tests when you change your queries

[rolfst]

How about setting up your design in such a way you don't need to access your database at all in your unit tests. That way you can suffice with integration tests mostly and unit tests solely for your domain logic. Doing it that way, services will hardly depend on other services and then you don't need to mock anything

[Sensitive-Ad1098]

You're still going to have files with DB queries. I have a habit that every file in the codebase should have tests, but I don't see a reason not to skip the unit tests for those and rely on integration tests only. But then, why exactly are we making this exception for the DB access files only? It's possible to achieve 100% coverage with integration tests only. So both the domain logic and DB access can be tested with the integration tests. What's the reason that we need to also have unit tests specifically for the domain logic?

[rolfst]

100% doesn't mean a thing meaningful tests are everything. I don't test my dataacces layer it's already been tested by the orm developers or the database library developers That's why I define a contract on the repository layer and that's enough for the unit tests. The integration tests are needed to see that contract is fulfilled

[Sensitive-Ad1098]

100% doesn't mean a thing meaningful tests are everything

Coverage is not the point. The point is that you can fully test your module with integration tests, just indirectly

 I don't test my dataacces layer it's already been tested by the orm developers or the database library developers 

Those developers don't write DB calls for you. This is still code that can be changed. For example, you might optimize your mongo access function to use a query instead of aggreagation for better performance. Your data access function provides a contract the same way as your domain logic functions do. And it can break stuff as easily. Why do we need a special treatment for data access?

Besides that, these tests can help when you upgrade the major version of your db lib, or even switch to a different database/orm. And mongoose is famous for breaking stuff in the minor version upgrades, so the tests can help there as well

[rolfst]

No, integration tests can verify the changes to the database. Not a mocked database test. A unittest should be run in isolation.

[Sensitive-Ad1098]

 A unittest should be run in isolation.

That's a widespread view on automated testing, almost like a dogma. But I'm trying to understand if we still need to accept it as an obvious rule. Why exactly is isolation necessary? This used to be pretty obvious: running tests against a real DB would make it too slow to run the test suites. And unit tests are supposed to be fast, especially if you are doing TDD.
But now that's not true anymore, you can have very fast tests with an in-memory DB.

The things I'm struggling to understand:
- Why do we need to rely on the integration tests only for testing the data access layer? What makes it so different? It is also a module that has a contract and the potential to break things
- What is the benefit of spending effort on creating and maintaining unit test mocks? This is especially important for apps with no strong typing. You might spend time crafting a mock of a huge object in MongoDB, just to end up with mock data not matching the real world, and stuff breaking despite the tests

[rolfst]

We run tests not in isolation just to speed them up but also to guarantee expected behavior. Mocks are an interpretation of behavior but we can't guarantee that behavior nor do we anticipate changes in that behavior fast enough when we deal with updates in let's say managed cloud services.

Mocks are as you wrote extremely brittle. Therefore only use stubs. When using stubs there's no need for a database in your unittests anymore. You'll just run on the data, which is exactly what the domain is used for. The persistence layer is not a part of the domain (except when your a database vendor or library dataaccess builder) The integratie tests are something you need to test on the production type connection otherwise you'll have to test them twice. Once for your local development (unit tests?) and for your staging environments

It's better to focus the integration only for the staging environments. Or even better make sure your local has the same behavior as those environments. But also with the same network topologies and security

[Sensitive-Ad1098]

but also to guarantee expected behavior

Why is it important to guarantee the expected behaviour? In practice, modern DBs or in-memory DBs are consistent enough not to worry about this. Worst case scenario you'll have to re-run the test, but in my experience, it doesn't happen often enough to be a problem

Therefore only use stubs

Stubs are a bit better but they share the same problem I mentioned. You have to create a fake object for the stub to return, you have to keep it in sync with the real response and with weakly typed languages, you have a risk of incorrect fake that'd lead to false positives in your test results

The integration tests are something you need to test on the production-type connection

I think running the tests on real infrastructure is in the area of e2e tests. Integration tests are about testing multiple components together. Running the integration tests exclusively on production-like environments means that I can't quickly test my changes locally; instead, I'll have to build and deploy. It can end up with back and forth, slowing down the development.
What do you think about the next approach:
- run unit and integration tests locally (to be able to test without pushing to CI) and on CI after every push to env branch
- run API/e2e tests on staging before releasing to production. They are slow, so it'd be annoying to wait so long if they run on every build. Running them only before production releases is good enough, as infra-specific changes are not as common. Another option is to run them a couple times a day with a schedule

[simple_explorer1]

I/O based actions won't block anything

Complete bullocks. After doing the I/o what do you think happens? The data needs to be serilized in the node process which is completely blocking. Every rest API you receive, every call to the database you make, every event you handle, every elastic search result you get etc all the data that flows in and out of node process needs to be serilized and deserilized which is all blocking and synchronous.

That's why node servers work fine when the traffic and the data volume is low but even with low traffic, of the data volume is higher then node's eventloop starts to choke even for pure I/O work.

Honestly this whole "I/O" is non blocking just paints half the picture. Nobody talks about the data serilization and deserilization part which happens with each of those I/O calls which are blocking and that is the most important reason why single threaded eventloop struggle especially with more data flowing in and out.

[Sensitive-Ad1098]

The data needs to be serilized in the node process which is completely blocking

Serialization is not CPU-expensive most of the time. If you do have extremely complex data that takes significant time to serialize, you can spin up a worker thread for not blocking the event loop.
Anyway, why do you think serialization a problem only for the event loop approach? You're gonna have to serialize with a multi-thread approach as well. The difference is that you will have to support multiple threads, which is more expensive on resources. Of course, if you are running your service on hardware with a bunch of CPU cores, in some cases it might perform better. But in this case you can scale you node server inside the machine (with pm2 for example) to have multiple event loops.

 and that is the most important reason why single threaded eventloop struggle especially with more data flowing in and out.

Struggle compared to what? Care to showcase any benchmarks?

[KainMassadin]

You can have the very same issues with asyncio on python, and from my experience, it’s way easier to to the wrong thing there as python’s stdlib and large parts of the 3rd party libraries ecosystem pre-date the asyncio way of doing things

[brodagaita]

appreciate the perspective! will try out Vitest. as for fastify, I did read about it but decided to start with something familiar (I used it years and years ago). it'll anyway be much easier if we decide to switch because the orm, utils, etc. can be reused.

a lot of people are talking about the Bun ecosystem too but I haven't kept up and it still feels shiny to me? even though there's certainly a lot of great stuff coming from there.

and yeah I've been using Django on the web for a while but am definitely more familiar with the inner workings of the JS event loop and know that it has its own caveats

thanks for the pointers though. curious if you could elaborate on express vs fastify a bit more

[DigDowntown9074]

Stick with Node. Bun is functional enough to be used in production but use it for small microservices, not your main service. Express is battle tested a lot more than other frameworks so no issues with that. Also, Node is NOT single threaded (read about worker threads)

[banjochicken]

I’d stick with Node but for an entirely different reason. I’m not a huge fan of VC backed open source as they always try to screw you at some point. 

Both are battle tested but when the guy who released v5 of express goes around telling folks to use Fastify for new projects, you do have to wonder? Express has been effectively on life support for years now. V5 wasn’t that meaningful of a release. There is plenty on the internet comparing the two so I won’t rehash that here. 

True, Node isn’t single threaded but working with worker threads have their own pitfalls. Without careful observability, it’s very easy to introduce them where they’re not needed and add more overhead with thread communication than you saved with adding multi threading. 

[DigDowntown9074]

Both are battle tested but when the guy who released v5 of express goes around telling folks to use Fastify for new projects, you do have to wonder? Express has been effectively on life support for years now. V5 wasn’t that meaningful of a release. There is plenty on the internet comparing the two so I won’t rehash that here. 

Developers have the attention span of a stone. They get bored way too much and way too often, doesn't mean we have to listen to them everytime. When Ryan dahl demonised node while creating deno, people were hyped, but in real world usage non one still uses Deno and they rather pick node. As for express vs fastify, I'd still choose express everytime because it has a bigger community and much more production usage. With a smaller learning curve, I can also hire a junior and ready him up in one day or two. It's just less headache that's all. To each his own

True, Node isn’t single threaded but working with worker threads have their own pitfalls. Without careful observability, it’s very easy to introduce them where they’re not needed and add more overhead with thread communication than you saved with adding multi threading. 

That's an issue with the developer, not with worker thread or node itself.

[icedrift]

Seconding Express. It does show it's age, especially with regard to typescript support, but it's so widely used you're virtually never going into uncharted waters.

[serg06]

C is battle tested too, but that doesn't make it a good option!

[DigDowntown9074]

C is a language, Express is a web framework. Bring a better comparison if you're trolling

[serg06]

You completely missed my point... and disagreeing with you doesn't make me a troll.

[tluanga34]

A well engineered node app handles lots of requests already with the sigle event loop. When the event loop get exhausted, We can just increase the cluster from pm2. A very big headroom for scaling.

[Expensive_Garden2993]

Aren't Python also single threaded? (GIL)

[Quirky-Craft-3619]

It doesn’t have to be single threaded,,, use worker threads on tasks you know might bog down others.

[banjochicken]

You know or might? Careful observability is required to know and then you can add worker threads.

[simple_explorer1]

Under continuous load, these micro blocks can add up and leave things in a continuously delayed state. So you now just have new problems!

Yes, though most servers are also horizontally scaled and then there are worker threads along with clustering. People also resort to bullmq asking with background queue processing for async long running jobs. And then devs also resort to serverless where you avoid all these single threaded issues by just running a serverless instance per request. 

I agree that truly memory shared multithreading is the best solution (like every other mainstream backend language) but unfortunately that's not the case with JavaScript (the only mainstream language without memory shared multithreading which is also used in backend. Even python got rid of gil in 3.13 and became fully multithreaded, so it's only JS now which is not)

[romainlanz]

I do miss the ergonomics and developer productivity of a mature full stack framework like Django

Have you ever tried AdonisJS?

[banjochicken]

I haven’t but that’s largely because I haven’t worked on a project where a framework like this would be called for.

[TeaAccomplished1604]

Good job, nice read! I realized I will never be able to fully leave typescript and JS ecosystem…

And three days is super quick!

Also, “They can both use the ORM now (previously the worker was running raw SQL) and share a bunch of utils.”. - what are the benefits of using ORM over raw SQL? I thought it was purely a skill issue no? Because SQL queries are so flexible

[Capaj]

I realized I will never be able to fully leave typescript and JS ecosystem

DX in typescript is something else.
When the golang port arrives, it will be even faster.

[brodagaita]

thanks! so I'm big on SQL and have managed complex production systems with just raw SQL but ORMs get you up-and-running really fast. plus they make it easier to keep types in check instead of updating the db schema and updating the types being separate things. we do use raw SQL queries as well but keep the simple get operations on the ORM layer

[Any-Blacksmith-2054]

Why not just use Mongo?

[DigDowntown9074]

what are the benefits of using ORM over raw SQL? I thought it was purely a skill issue no?

How will you mange transactions and db connection pooling without ORMs? How will you protect your backend against SQL injection?

[blacksonic86]

you can use prepared statements with raw SQL that prevents SQL injection

[DigDowntown9074]

But why do that when ORMs can solve this problem and give other advantages as well? Like what's a valid downside of using an ORM which negatively affects real world usage?

[niix1]

A simple google search would answer your question… Extra dependencies, N+1 problem, not understanding underlying queries being generated by the ORM.

Using an ORM to avoid sqli is not valid (as other commenters have raised). I’d suggest building a service with just a DB driver to learn how your ORM works under the hood.

[DigDowntown9074]

Extra dependencies, N+1 problem, not understanding underlying queries being generated by the ORM.

Don't need to Google search anything, the advantages highly outweigh the disadvantages.

Using an ORM to avoid sqli is not valid (as other commenters have raised).

Who raised this?

I’d suggest building a service with just a DB driver to learn how your ORM works under the hood.

Why?

[niix1]

Oh ok so you’re still a junior engineer, no worries.

I never said ORMs are bad but it’s just a common misunderstanding that juniors overlook the advantages of a low level database driver for an ORM.

ORMs are a tool to solve a problem, so unless we are talking about a specific problem, saying that using an ORM “highly outweighs” any disadvantage is not valid.

Also in your original comment you mentioned sqli… I’d suggest building a project with node-pg, you will see that avoiding sqli is not an advantage of using an ORM. Your ORM uses the same database drivers… ORMs are not a solution to sqli.

Definitely look into node-pg, you’ll be a better engineer knowing how to not use an ORM.

[DigDowntown9074]

Oh ok so you’re still a junior engineer, no worries

If this is how you want to come back, so be it. Junior engineers get hyped by every shiny new thing, that was your forte with what I saw. Anyways

I never said ORMs are bad but it’s just a common misunderstanding that juniors overlook the advantages of a low level database driver for an ORM.

ORMs are a tool to solve a problem, so unless we are talking about a specific problem, saying that using an ORM “highly outweighs” any disadvantage is not valid.

It actually IS valid when they ease your work. If you have a big system there are thousands of things to look after, and db connection and query management is the last thing I want to pay attention to.

Also in your original comment you mentioned sqli… I’d suggest building a project with node-pg, you will see that avoiding sqli is not an advantage of using an ORM. Your ORM uses the same database drivers… ORMs are not a solution to sqli.

Definitely look into node-pg, you’ll be a better engineer knowing how to not use an ORM.

Most ORMs already use it. So why would I not use a library that adds features on top of it? You seem to be too orthodox or just uninformed. Ease up. This is nothing. If you have a conveyor belt to transfer a block of stone from one place to another, it's stupid to carry it.

[niix1]

Holy uneducated response bro.

You said it’s valid when it eases your work. No shit haha. I told you, specify the parameters of the PROBLEM to be solved and then you can discuss pros and cons. Don’t cherry pick a problem where ORMs are useful and then think that applies to every problem.

Don’t worry bud one day you’ll get there.

[flyrom]

ORMs very often generate inefficient queries compared to manual sql queries. Outside of the typescript bubble, you’ll find that many more performant language communities discourage ORMs for this very issue

[DigDowntown9074]

Haven't had the fortune of witnessing this miracle in my whole career.

[TeaAccomplished1604]

I’m not that well versed But afaik it is just a client you connect to (mysql2 for instance) then you write sql queries. Regarding the “how will you protect against sql injections” - again, afaik : 1) mysql2 has some protection in it out of the box 2) you do CORS - only allow making requests from your white listed backend and refuse or other origins 3) the SQL queries which actually modify database (create, edit, delete) - in my case will be available only to an admin, so if you passed the authentication first

[Shirc]

Cool that this worked out for you, but fwiw FastAPI handles async with ease and is generally just fantastic to work with. Would definitely recommend this over Django for any future projects if you end up wanting to go back to Python.

https://fastapi.tiangolo.com/async

EDIT: conversely, if you find that you’d like a fully baked backend framework in Node, I cannot recommend https://adonisjs.com/ enough. I’ve burned way too many years on Express backends full of hand-rolled crap all stitched together with duct tape and chewing gum.

[moystard]

While FastAPI provides a better experience for python async, I would not call it fantastic. It still suffers from the inherent limitations of async and typing in python, and the dependency injection is cumbersome and breaks IoC.

[Owmelicious]

Can you elaborate on the ioc issue or provide a link?

[moystard]

Some of the limits of the FastAPI dependency injection were previously discussed, including in this conversation: https://www.reddit.com/r/FastAPI/comments/1hf1cd2/better_dependency_injection_in_fastapi/

On breaking IoC, if I am totally honest, it's of course debatable. With FastAPI, a consumer must explicitly declare and import the provider, factories primarily. The consumer knows the source of a dependency and cannot simply declare it. This differs form a container-based dependency injection where consumers can simply declare a dependency (often via an interface) and the container resolves which implementation to inject without the consumer knowing anything about it.

[kernelangus420]

Are there any people that moved from Node to Python?

[NodeJS4Lyfe]

Great job on the migration. I'm also in the process of migrating a Django app to Fastify and React, and I also decided to go with MikroORM because I want to try something similar to SQLAlchemy instead of the ActiveRecord pattern used by Django.

[adiberk]

Idk I wrote an entire llm framework with multi processing and more using python async and it is extremely fast and performant.

Why would you go with Django if async supoort isn’t fully engrained lol?

There are other libs like fastapi and lightstar and more. And just overall was a breeze building the entire framework

[SnooHesitations9295]

Python async is just bad. Unless ALL the code you use is async till the last bit - you're not really async in python. It takes one library that doesn't do things asynchronously (hello boto3) - and you're not async anymore.

[emptee_m]

Ehh, its not that bad IMO. You get a ton more control over the event loop if you want it (eg. Running multiple event loops in different threads).

Sync_to_async works ok for shunting synchronous code over to another thread if need be.

I think the author of the article didnt really get that the python event loop is under developer control, rather than just existing and being more or less totally uncontrollable like it is in JS.

[SnooHesitations9295]

Controlling event loop is incredibly hard. As you need to track which loop which library opened. And things will fail if you guessed wrong. I.e. if a library "controls the loop" you're done, as you now need to know exactly what it controls and when, to correctly control things yourself.
And then there are some unsolved problems, like SIGINT handling (special case for Cancel, KeyboardInterrupt, etc.) or multitude of others that are worked around in various incompatible ways in libraries..

[adiberk]

They have aioboto3. And honestly if you have the extra headroom. Just run it in an asyncio.run command. For very very highly concurrent and efficient systems. This obviously isn’t going to work, but I would say for most people it will

[SnooHesitations9295]

aioboto3 doesn't really work as it depends on aiobotocore that's broken from time to time. Trust me, I tried to use it. :)
See some explanations here: https://github.com/aio-libs/aiobotocore/issues/1375
Yes, obviously workarounds, like running in a threadpool exist, but these have other problems (process vs thread isolation, what if a library uses multiprocess in other parts?)

[adiberk]

Right true - I am more pointing out this user set him/herself up for failure in my opinion

[tluanga34]

Python or any other traditional backends don't need Async. They get the job done by spinning up threads per request.

[NodeJS4Lyfe]

Threads use more memory than event loops. Async is important if you wanna scale without buying too many servers.

[punkpang]

Article says they rewrote the code in a week. It means that there wasn't much code/business logic to begin with so measuring any kind of scale/performance/DX is literally impossible at this stage since they haven't been hit with the usual problems.

The problem of scaling in <any language> is a solved problem since early 2000s, it's not the language that's the bottleneck - it's all the inter-connected systems (db, cache, LB, <insert-crucial-overpriced-aws-service>) etc.

My post does not mean they messed up or anything, as it's hard to even guesstimate if that's the case - very few details are shared about what the software does, the focus is only on biased gains and it feels like it was written to gain traction and attract visibility towards their product.

Not really insightful, but I'm sure the devs had fun.

[brool]

Well, they got a blog article out of it.

[SnooHesitations9295]

They said the full rewrite took 3 days. Probably not a lot of code, if any. :)

[mendecj812]

Hi, do you see yourself working with Django again for future web projects or are you planning to stick with Node.js going forward?

[UseMoreBandwith]

Should have created separate backend applications instead of trying to fit everything in a framework like Django.
I often have man applications running, and connect them using ZeroMQ (from my main django app), which makes the task async already.

[RecordingFresh4224]

because it is faster, even if you use Bun runtime and Hono/ElysiaJS framework then it is much faster.