5 ms·
There is no good JS ORM, so it's for the best.
by dyeje 5y ago
There is no good JS ORM, so it's for the best.
- bitwize 5y agoBest practice, in the case of JS, is to use MongoDB, which has a native JS query API, and then use microservice patterns to provide joins, two-phase commit, and (eventual) consistency.
- yowlingcat 5y agoWhy would your database choice have anything to do with your language choice?
- bitwize 5y agoBecause your programmers don't know SQL and don't want to. In an ideal world of perfectly spherical programmers, choosing JavaScript would be completely orthogonal to database choice, but in reality one common symptom of JavaScriptitis is considering SQL an old relic that's too much of a pain in the ass to learn. Thankfully, MongoDB's query language is JavaScript and its result sets are JSON objects. To be fair, this sort of feeling toward SQL is not found uniquely among JavaScript programmers; one major reason why we have ORM hell is because a previous generation of programmers did not want to leave the warm cocoon of treating data as objects in Java.
- yowlingcat 5y agoAssuming you're not being facetious (which I'm not sure of)... You have described why people make such decisions, but you have not yet made an argument for whether it's wise or not. Can you imagine why it would be an unwise decision? Even if you have engineers who stubbornly refuse to learn SQL (a problem with your engineering management if there ever was one), there's always options like Hasura [1]. [1] https://hasura.io/ https://hasura.io/
- thinkingkong 5y agoI know youre joking but why do I feel so hurt?
- henvic 5y agoThere's no good ORM.
- smackeyacky 5y agoEntity Framework (in .NET) is good. Looks like this package takes a lot of the feel of Entity Framework transferred over to node.js
- ckmar 5y agoOh interesting! I'll have to check it out!
- da_chicken 5y agoEF is slow, IMX. But I think it mainly has to do with the fact that it's an ORM, and since the application un-marshals to objects and marshals back to the data store more or less one object at a time, you lose set-based operations. If you're interacting with a lot of discrete, unrelated objects, that gets really inefficient. You can easily end up with the dreaded "row by agonizing row" pattern: UPDATE Student SET Grade = '04' WHERE StudentId = '12345' UPDATE Student SET Grade = '04' WHERE StudentId = '12346' UPDATE Student SET Grade = '04' WHERE StudentId = '12347' UPDATE Student SET Grade = '04' WHERE StudentId = '12348' . . . . UPDATE Student SET Grade = '04' WHERE StudentId = '12349' Instead of: UPDATE Student SET Grade = '04' WHERE StudentId IN ('12345','12346','12347','12348', ...., '12349')
- smackeyacky 5y agoOh it can be slow, not all of the entity framework adaptors support bulk operations. I ended up extending it a bit on my object model to include bulk operations which do pretty much what you have there (I stuck to delete and insert though). However, I have used a pile of ORM products since the early C++ / smalltalk days back in the 1990s and it's easily the best ORM I've ever used.
- rubyskills 5y agoActiveRrcord is pretty good. So is Sequel.
- zackify 5y agoprisma is amazing, takes 5 minutes to setup, and lets you make just about any query with minimal typing, unlike making raw sql.