Hacker News Reader

Comment by JoshGlazebrook | Hacker News Reader

I've been a Node.js developer for a couple years now and one thing I've noticed is I've never come across a company that actually uses it for their core api. There always seems to be a Java based (or another statically typed typically 'monolith' language) backend api server that smaller node.js microservices/apps communicate with.

View on HN

As someone who has been writing core APIs in Node.js for a few years now, one thing I really miss is a good ORM. The best one is probably Bookshelf.js but it's poorly maintained and lags behind more mature ORMs like Active Record in terms of features and stability.

You might want to check this https://github.com/Vincit/objection.js it is the only node ORM I don't hate yes even compared to sequelize I tried them all.

I used bookshelves a couple years ago and while it was very good on paper, I quickly ran into a lot of quirks and bugs for advanced usage.

There was an obvious lack of resources to develop it, and after contributing to it a bit I switched. Reliability is the #1 feature in an ORM in my opinion, and I didn't get that confidence from using bookshelves.

I later moved to sequelize, and it worked flawlessly from the get go, give it a try. You can compare the Github activity, you'll see it's thriving, and everything is much cleaner.

The performance is also way ahead, as last time I used it bookshelves relied on Backbone-esque models underneath, making it way slower for big nested queries.

Thanks. I actually started out with Sequelize before switching to Bookshelf.js but you convinced me to give it another go.

Noo, give it a go Bookshelf.js you will be more happy. Yes, maintenance lacks behind sometimes but the core is strong.

And if you do anything particularly hard you always can tap into knex and get all its powerful API and if that is not enough you run raw queries until the feature is officially supported.

Writing asynchronous SQL queries is tedious indeed. SQL is very powerful though, and has it's use cases. But for real time applications, like multi-player servers, it doesn't really fit, so for those use-cases, I've made an ORM (1) that use proxies so data can be treated just like any JavaScript object, with synchronous in memory read/write and asynchronous HDD persistence via an SQL server.

1) https://github.com/Z3TA/dbo

If you're using RethinkDB, https://thinky.io works well. I use it for all my current projects.

Not to go too off-topic, but Sequelize is worth a look if you haven't played with it already.

I recently started playing around with Node for a friend's side project. I helped him set up the database and Sequelize was absolutely horrible to get up and running. The documentation was really lacking and we spent hours trying to track down little details needed to get things running. It does the job once you have it set up, but I found getting to that point was way more difficult that it should have been.

I used Sequelize for a while before Bookshelf was released and haven't used it since so I'm not sure how it compares these days. One thing I like about Bookshelf is that the query builder (Knex.js) is fairly decoupled and it's not that scary to drop down to the SQL layer. I still feel it's not quite as good as it could be.

This might not be objective because I hate sequelize but sequelize sucks! I never understood its API. Is so clunky compared to Bookshelf.js.

Bookshelf is less opinionated on the way you integrate it with your web app with makes it good to work with if you have strong opinions on how it should integrate with your codebase.

That's how these transitions happen. They have a monolith which works and is "known good", and they slowly transition away from the monolith by wrapping it in microservices, till the microservices replace chunks of the monolith.

Eventually, hopefully, the monolith will be gone and there will only remain the microservices, but that could take some time.

We're a small company, about 150 folks, but our core api is node and we process 10-20bil external requests per month depending on season. Not exactly an enterprise and we have always been a NoSQL shop so YMMV.

People keep using this word "monolith"-- I don't think it means what you think it means(tm).

A crappy old system can be crappy because of the way it's written or the people writing it. If, as mentioned in one of the linked articles, it takes you six weeks to get a simple controller layer up and running in Java, something else is wrong, and it isn't the stack.

As an anecdotal account, that's not surprising. If it takes, let's say, ten years to get good at something, then people who are good at server-side app-building are going to have roots in other technologies and other ways of thinking about the problem than what Node offers. The Node community is a wide but shallow ocean at this point.

Uber: https://medium.com/@nodejs/how-uber-uses-node-js-to-scale-th...

PayPal is a good example of a company that moved from Java to Node.js where the server listens to the client then have it slowly replace code going forward on the back end. [0]

There is a discussion that the bigger issue was getting management to allow them to rebuild all the code and by using Node over Java provided a mechanism to do this. This is touched on in the article.

[0] https://www.paypal-engineering.com/2013/11/22/node-js-at-pay...

As an opposing data point, at my previous employer we built the API with Node.js.

We're considering switching parts of our Node codebase to TypeScript and I wonder if that will happen to a lot of these APIs you've seen.

Reply on news.ycombinator.com