So basically like entity framework & LINQ in the C# world
but for nodejs
Show HN: Node.js ORM to query SQL database through an array-like API
81–90 of 108 posts
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#82I love your syntax for joins and unions! A bit puzzled by why the connector slots into the query, instead of the query slotting into the connector, given that it’s the connector that’s actually doing the work. I.e. ‘connector.fetch(query)‘ … rather than… ‘query.fetch(connector)‘
It was more of an ergonomics choice. To me it seems like it's more readable to write `await users.filter(user => user.id.eq(42).fetch(connector)` instead of `await connector.fetch(users.filter(user => user.id.eq(42))`. But I might be wrong, your idea makes more sense from logical perspective.
I’m not sure I can say which is _objectively_ better, but I was also surprised, connector.fetch would be more consistent with common JS practices
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#83Earlier quoted context omitted.
I’ve taken more and more to thinking of them as a zero sum tool. Super fast and easier to use force multiplier in the beginning, but eventually you break free of the siren song and run into some negative that eats away at your time until you reach that “if you had just sucked it up and written the damn sql you’d be done yesterday” stage.
This just seems like a normal part of the growth curve. You cannot simultaneously build an infinitely scalable solution and complete something in a reasonable timeframe with the features that users will pay for. If you get to the point where you have enough users to justify working on efficiency or scaling out your infrastructure that’s a sign that you are winning. Unsuccessful companies never have to clean up their…
+1
"...premature optimization is the root of all evil."
Sometimes you just wanna get stuff out there, other times you're winning and you wanna give users the best experience. Many people have had to do both. You start with an ORM, eventually your queries are slow and all, you gradually reap them out. Almost every Engineer I know has had to do that at some POINT. Nonetheless, I am not about writing SQL for a simple barbing saloon booking app that I am not sure anybody will eventually use.
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#84Now that we have about 15 years of ORMs, do they really make things easier? SQL is not a difficult language to learn, and views and stored procedures provide a stable interface that decouples the underlying table schema, allowing for migrations and refactoring of the database structure without having to rewrite a lot of code. ORMs seem to me to be mostly about syntactic sugar nowadays; I’m worried that the abstractio…
What I find valuable is that many ORMs provide type support and manage migrations, not so much the day-to-day interaction with the database.
> manage migrations
I feel like it is one of their major drawbacks. But I'm mostly working maintenance so what I usually see are databases outliving many applications and my view will differ from greenfield project people.
Your ORM is tied to your app. Tying your database to your app through your ORM is IMO an error. Managing schema change in your application is even worse.
Database and their schema should be independent from your app. So you can release new versions of your database without depending on app releases. As mentioned by other people the best would be to have views per app for reading and procedure for writing so you can totally decouple your app access from your data schema.
Databases are not dumb key value stores. Stop using them like they are and start enjoying the functionalities they offer.
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#85I never use orms and don’t find them appealing, but one thing I do with my sqls may interest you.
I always wrap .query(…) or simply pass its result to a set of quantifiers: .all(), .one(), .opt(), run(), count(). These assert there’s 0+, 1, 0-1, 0, 0 rows.
This is useful to control singletons (and nonetons), otherwise you end up check-throwing every other sql line. One/opt de-array results automatically from T[] to T and T | undefined. Count returns a number.
Sometimes I add many() which means 1+, but that’s rare in practice, cause sqls that return 1+ are semantically non-singleton related but business logic related, so explicit check is better.
I also thought about .{run,count}([max,[min]]) sometimes to limit destructiveness of unbounded updates and deletes, but never implemented that in real projects.
Maybe there’s a better way but I’m fine with this one.
Edit: messed up paragraphs on my phone, now it’s ok
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#86My take on this is that it's not always the best idea to abstract-out SQL. You see, the SQL itself is too valuable abstraction, and also a very "wide" one. Any attempt to hide it behind another abstraction layer will face these problems: - need to learn secondary API which still doesn't cover the whole scope of SQL - abstraction which is guaranteed to leak, because any time you'll need to optimize - you'll need to st…
Yes, yes and yes. ORM are marvelous when you do not know well SQL. With experience, you always end up needing to learn more about SQL. In the end, ORM is as much a hindrance as a help. So instead of spending energy learning the ORM of the day, it's better to invest in longer lasting technologies like SQL.
I know SQL and I like ORMs. For most simple CRUD, an ORM is fine. I don’t understand how they are “as much a hindrance as a help”; using an ORM only adds functionality, it cannot prevent you from using SQL against the data source in the same manner you would if you weren’t using an ORM.
It’s really just syntactic sugar for the subset of very basic queries that are easily expressed in the ORM. If other parts of your codebase are expecting ORM objects, it’s maybe two lines of code to re-wrap your SQL-fetched PK values back into ORM ducks.
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#87My take on this is that it's not always the best idea to abstract-out SQL. You see, the SQL itself is too valuable abstraction, and also a very "wide" one. Any attempt to hide it behind another abstraction layer will face these problems: - need to learn secondary API which still doesn't cover the whole scope of SQL - abstraction which is guaranteed to leak, because any time you'll need to optimize - you'll need to st…
I love ORMs for setting up entities and relationships, but I mostly use sql/query builder for all queries that are not trivial.
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#88A while back I wanted to do a project in NodeJS to refresh my JS skills a bit, wanted to find a nice ORM similar to EF because I use it so frequently but unfortunately didn't come across anything.
Ended up using drizzle and just hated every moment of it. This is definitely going in the "Use this eventually" folder!
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#89I never use orms and don’t find them appealing, but one thing I do with my sqls may interest you. I always wrap .query(…) or simply pass its result to a set of quantifiers: .all(), .one(), .opt(), run(), count(). These assert there’s 0+, 1, 0-1, 0, 0 rows. This is useful to control singletons (and nonetons), otherwise you end up check-throwing every other sql line. One/opt de-array results automatically from T[] to T…
Interesting, it throws an error if result rows don't match expected quantity?
Re: Show HN: Node.js ORM to query SQL database through an array-like API
#90Earlier quoted context omitted.
What I find valuable is that many ORMs provide type support and manage migrations, not so much the day-to-day interaction with the database.
> manage migrations I feel like it is one of their major drawbacks. But I'm mostly working maintenance so what I usually see are databases outliving many applications and my view will differ from greenfield project people. Your ORM is tied to your app. Tying your database to your app through your ORM is IMO an error. Managing schema change in your application is even worse. Database and their schema should be indepen…
How do you manage database migrations then? Are they in Git repository? Genuinely curious.