Hacker News Reader

Comment by wslh | Hacker News Reader

The last time I criticized Node I was heavily downvoted here (downvotes already started here too! Please educate me, I am here to learn), so I will proceed with caution now:

We developed some applications in Node, it is a headache to maintain an application that uses an SQL database (e.g: MySQL) because the code for executing a transaction involving several queries is unreadable afterwards. We use the module async to have some kind of readability but there are many implicits where small errors are natural to occur.

On the positive side, I found some specific modules in the cryptocurrency space that are not available in other programming languages. This is why we are playing right now with Trireme and Edge.js to use Node modules from Java or .NET.

View on HN

JavaScript is evolving towards addressing this, with promises in ES6 and async/await in ES7. The latter is a game changer.

FYI, async/await didn't make it into ES2016 (aka ES7).

See here: http://www.2ality.com/2016/01/ecmascript-2016.html

Doesn't matter much, it will reach Stage 4 soon, which is equivalent to being standardized.

in my experience, node definitely starts to seem complicated (in comparison to other languages) when doing operations that require multiple callbacks. its sometimes hard to tell where errors are occurring.

async helps, but when doing a series of operations with dependencies and shared data between steps it can lead to headaches. It took me quite a bit of time before I could think about these operations in a way that was a better fit for an event driven model, and once my mind set changed, things felt simpler.

i've had success recently moving complicated multiple step operations into their own functions. If you follow the callback/error conventions this can be much easier to debug, and you can add your own error handling at each step.

I also find this annoying. The reason is because there are no locks in Nodejs. It never waits for a query to execute, so you have to use callbacks. This makes your app super performant. You can now run your service on one CPU core where you needed twenty physical servers to handle the same traffic before.

There are libraries that handle database transactions cleanly. See for instance: http://knexjs.org/#Transactions

Can you explain?

Due to Node's evented architecture, you should be executing all the transaction code in ONE sql query -- otherwise the transaction can be interleaved with other queries!

(downvotes started here too! please educate me instead of downvoting, I am here to learn)

Yes, that is an additional issue that I suppressed for my comment trying to narrow the criticism to executing several SQL queries in a readable and maintainable way.

I will not expand on how we solved that specific issue, just say that the transaction in question is fired by external events that can't be fired until a previous one finished.

But, following your suggestion about executing all the transactions in one SQL query, how do you do this without using a store procedure? Because we were thinking in using store procedures but we couldn't implement all the logic inside the transaction with a SP. This is where other languages solve the problem but I couldn't find a concrete solution in Node, so any suggestions will be very appreciated.

I was also worried I'd need stored procedures (which MySQL requires root privileges to create) until I realized (by trying) that felixge's mysql module (and probably others) simply accept queries with multiple statements :-D

So that solved it for me!

We did exactly that- create stored procedures- to get around certain transactional issues we were facing. We didn't have any problems being able to create them as we manage the schema outside of the application. In general this has been a fine trade off for us and hasn't caused any pain. I remember way back in the day when using stored procedures is what you were SUPPOSED to be doing...

No. When you start a transaction, you hold onto the particular connection you started it with, and that connection is busy in your connection pool and won't be assigned to unrelated queries. See for instance: https://github.com/brianc/node-postgres/wiki/Transactions

(If you're just saying "other unrelated queries could happen between opening the transaction and closing it," well, yes, but that's true of any web application, whether it uses threads or events.)

Usually a thread or an app holds a connection. But here the connection may be shared among many evented handlers!

Reply on news.ycombinator.com