Wappler currently doesn’t provide hashing mechanisms for nodejs. Since I believe there’s no support for async formatters, you will have to run your argon/bcrypt and what have you synchronously.
Unless you got 10 users on different timezones, that’s simply unacceptable for any nodejs because it will block every other http request while the CPU is running the hashing in the event loop.
Not sure why the Wappler team changed my title from “Wappler cannot scale nodejs apps”. It’s a valid concern that should be addressed by the team that’s why I started the topic.
This is not strictly related to async formatters though it’s one example, but everything that Wappler is executing on the backend that could potentially block the event loop. Other examples include reading files, saving files, and all the server actions.
@Teodor care to explain your edit of the title? This affects how we structure our apps from the get go so I think it’s useful to kick off a discussion.
Your title saying Wappler cannot scale NodeJS apps was not really clear and it is not correct.
You are talking about bcrypt/argon and async formatters which are not available for NodeJS.
Please check the following discussion about async formatters and the replies posted by Patrick and George:
@Teodor Support for async formatters is just one example to kick start the discussion. I am talking about the whole Node.js server model so that includes all the server actions and DB actions that Wappler is running. Therefore, I think my title is fair.
@JonL nonsense. It’s sync. Just because you stick a async in front of your exports doesn’t make Wappler async. They are calling sync methods all over the place. A quick folder search will tell you all there is:
That's even before getting into the fact that your awaits also run in the event loop, and you need workers to make it scalable. I mean this is straight from the Node official website
Suppose your server must read files in order to handle some client requests. After consulting the Node.js File system APIs, you opted to use fs.readFile() for simplicity. However, fs.readFile() is (currently) not partitioned: it submits a single fs.read() Task spanning the entire file. If you read shorter files for some users and longer files for others, fs.readFile() may introduce significant variation in Task lengths, to the detriment of Worker Pool throughput.
You should make sure you never block the Event Loop. In other words, each of your JavaScript callbacks should complete quickly. This of course also applies to your await 's, your Promise.then 's, and so on.
Well it seems there is a clear intentionality to use sync versions from the first two(the last two are your own I guess). So better to ask @patrick why this decision.
@George formatters are indeed used for heavy duty if you are using them in Wappler tutorials to hash passwords with argon2. If crypto is not heavy duty for thousands of users pinging the wappler server I don’t know what is.
Also your answer doesn’t touch on my main point on the nodejs model in general which includes modules being synchronous.