Live data from Hacker News

Show HN: Node.js ORM to query SQL database through an array-like API

github.com

71–80 of 108 posts

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#71
My 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 start reason in terms of SQL and try to force the ORM produce SQL you need.

- performance

- deceptive simplicity, when it's super-easy to start on simple examples, but it's getting increasingly hard as you go. But at the point you realize it doesn't work (well) - you already produced tons of code which business will disallow you to simply rewrite

(knowledge based on my own hard experiences)

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#72
post #71

My 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…

Have you use BI tools, such as Looker, Tableau, and the like?

LookerML is their abstracted version - but they always have an expander panel for seeing the sql.

---

What I would like is to use this in reverse - such that I can feed it a JSON output from my GPT bots Tribute - and use this to craft a sql schema dynamically into a more structured way where my table might be a mark-down version of the {Q} query - and it does SQL to create table if not exist, insert [these objects from this json for these things into this DB, now these json objects from this output into this other DB. Now I am pulling data into the DB that I can then RAG off as I fill it with Cauldrons of Knowledge I am scvraping for my rabbit-hole project thingamijiggers.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#74
post #71

My 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’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.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#75
post #10

An intriguing idea! I like this approach for being an innovative interface to SQL. I wonder if it would reduce cognitive load when interfacing with the DB. I'm a game dev and often need to avoid situations where I'm using '.map' to iterate an entire array, for performance reasons. It would feel odd to use the concept, knowing it wasn't really iterating and/or was using an index. Is that how it works?

It’s exactly what Entity Framework does in dotnet. It allows you to query the database like it’s an enumerable. In fact, in EF, an IQueryable (which is the interface you use to query a SQL dataset) implements IEnumerable. So you can 100% manipulate your dataset like a normal array/list. Sure it comes with its own shenanigans but 90% of the time it’s easy to read and to manipulate.

[dead]

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#76
post #71

My 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’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 tech debt. For successful companies, it is a constant balance. You’re lucky to ever be in a position to have to clean up your short sightedness from previous work. By the time Facebook needed to mature beyond their PHP codebase, they were already wildly successful by every metric and had the resources to tackle such a problem. Early stage CRUD APIs should absolutely be generated and use the shitty ORM generated queries. By the time you run into serious performance issues with the ORM generated queries, you should be successful enough and have enough runway to plan a better future.

The vast majority of companies like this don’t fail because their UI is too slow. It’s because they don’t have “essential” features that other platforms do. If you have good monitoring and metrics, you should be able to find the bottleneck in your ORM and resolve it before any users even notice. And that means you’re hand rolling a few queries instead of the entire data storage layer.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#77
post #10

Earlier quoted context omitted.

It’s exactly what Entity Framework does in dotnet. It allows you to query the database like it’s an enumerable. In fact, in EF, an IQueryable (which is the interface you use to query a SQL dataset) implements IEnumerable. So you can 100% manipulate your dataset like a normal array/list. Sure it comes with its own shenanigans but 90% of the time it’s easy to read and to manipulate.

Performing a query with EF is able to do stuff that can't be done with `IEnumerable`. So that a filter()/.Where() can actually generate a WHERE clause instead of looping over every record.

Yes of course it generates the corresponding SQL and don’t iterate over the table.

But in the framework’s code, IQueryable implements IEnumerable, it’s just a totally different implementation but for the developer it’s 100% the same API and so any IQueryable can be used where a IEnumerable is expected.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#78
post #58

Now 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…

[dead]

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#79
post #58

Now 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.

Re: Show HN: Node.js ORM to query SQL database through an array-like API

#80
post #71

My 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.
Post reply on HN