Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

github.com

Post reply on HN
Print view View original

31–40 of 124 posts

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#31

Post by Seb-C »

exevp wrote: post #17
twodave wrote: post #10

Earlier quoted context omitted.

OP's project is a little more opinionated than Dapper in that it defines repositories and whatnot. Dapper's more like just a set of query extensions that support basic object mapping. I love it personally, but I wouldn't even call it a micro-ORM.

It might be a good idea to focus on the use of template strings for safe and handy SQL generation instead of introducing too many opinionated ORM concepts. If one had to, i'd separate these things in different libraries and let the developer opt in to what he needs.

That is something I seriously considered, but I just did not want to bother with multiple packages and repositories, especially for a repository class that is about 150 lines of code.

The repository class that I provide is a very basic and handy abstraction for the 4 basic CRUD operations, but ultimately the goal is to write your own queries and repositories.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#32

Post by xixixao »

midrus wrote: post #11

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives…

Looks nice, pretty close to what we use at FB, except we use the builder pattern, so you can compose the query more easily across function calls (instead of passing in a single bag of options to findMany).

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#33

Post by Seb-C »

marius_k wrote: post #18
Seb-C wrote: post #2

For a long time, I have been frustrated with the state-of-the-art about the existing ORMs. I like things to be simple, but somehow all ORMs seems to be bloated and overcomplicate a lot of things. When designing a new project, I have been trying to find a more satisfying design while avoiding the existing ORMs. I especially wanted to use proper SQL rather than reducing it's syntax to fit it in another language. This i…

thanks. I love it! It is not clear where the `article.id` comes from in many-to-many example. Anyway I don't think I would use those relationships patterns, instead I would just load and operate in plain (shallow) model objects.

Thanks! It was a copy/paste mistake. I just fixed the README file.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#34

Post by CoffeeDregs » 

   sql"SOME SQL";
This looks to be a "tagged template": https://basarat.gitbook.io/typescript/future-javascript/temp.... I'm a TS user but hadn't seen that feature before. AFAICT, the library is using a side-side-side-feature (tagged templates) of TS as the core abstraction [1]. Impressive. Might be a little brittle in the face of significant SQL or query composition?

Anyhow, I'm a heavier-ORM user but that's impressive.

--- [1] https://github.com/Seb-C/kiss-orm/blob/c4b6c9ad2f81337938a9c...

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#35

Post by foepys »

xixixao wrote: post #32
midrus wrote: post #11

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives…

Looks nice, pretty close to what we use at FB, except we use the builder pattern, so you can compose the query more easily across function calls (instead of passing in a single bag of options to findMany).

The builder pattern grew on me over the past few years and I think it's one of the best ways to do anything arbitrarily composable that is reasonably complex.

.NET's LINQ can also be used as a builder and I really, really love it - be it as part of an ORM or just .NET in general.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#36

Post by exevp »

areactnativedev wrote: post #29
exevp wrote: post #15

Earlier quoted context omitted.

tl;dr: thank god it finally has been done. Long version: i've been seriously frustrated with the state of ORM (in Javascript in particular) for years. Javascript ORM are nice and handy if all you're doing is simple CRUD stuff. If you're starting with more complex relational queries (we're using an RDBMS so why wouldn't we?) you quickly reach the limits of what the ORM can map. If you start doing more complex aggregat…

Very surprised by the no value you attach to Knex, I'm curious to get your view on the values I see in using it for a few years now. I feel at ease with SQL and like to get as close to it as possible in my Node service. But Knex still appears to be highly valuable to me to, for instance, not care about managing DB connections, at least until they become critical for my use-case. Not care about sanitising inputs and p…

> not care about managing DB connections, at least until they become critical for my use-case.

That's something the db driver usually does. E.g. when using Postgres, the pg library already comes with the connection pooling. Haven't looked into the implementation in Knex but i'd suspect they just use the Pool class of pg (https://node-postgres.com/features/pooling).

> Not care about sanitising inputs and protecting myself from SQL injections.

That's also not that much of a concern when just binding parameters.

> Have more readable and maintainable code in my repositories than SQL in plain strings as a default. Yes I have some raw queries but 98% of my queries are easy to follow knex chains.

Comes with the cognitive cost of maintaining another abstraction for SQL.

> Not care about creating and maintaining code for migrations.

That's actually the one feature which made me use Knex for years (just for the migration part of course :) ). I didn't use the schema builder functions mostly, just a bunch of `knex.raw` calls in the migration files. But for the benefits you mentioned (transactions, bookkeeping) it is really useful.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#37

Post by __ryan__ »

exevp wrote: post #17
twodave wrote: post #10

Earlier quoted context omitted.

OP's project is a little more opinionated than Dapper in that it defines repositories and whatnot. Dapper's more like just a set of query extensions that support basic object mapping. I love it personally, but I wouldn't even call it a micro-ORM.

It might be a good idea to focus on the use of template strings for safe and handy SQL generation instead of introducing too many opinionated ORM concepts. If one had to, i'd separate these things in different libraries and let the developer opt in to what he needs.

Thankfully [0], it [1] already [2] exists. [3]

[0] https://github.com/gajus/slonik-sql-tag-raw

[1] https://github.com/felixfbecker/node-sql-template-strings

[2] https://github.com/blakeembrey/sql-template-tag

[3] https://www.npmjs.com/search?q=sql%20template

Edit: When I first read your comment, I thought you were saying that you wanted a separate library just to have the SQL template functionality.

I agree with what you're saying though.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#38

Post by [deleted] »

midrus wrote: post #11

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives…

[deleted]

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#39

Post by midrus »

nicoburns wrote: post #23
midrus wrote: post #11

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives…

I actually much prefer writing migrations by hand. It's actually pretty simple, and it gives you complete control over the schema.

Agree, it's pretty simple writing them. The problem is deciding which ones to apply for a given version of your application, when, running them automatically on each of your developer's laptops, your testing environment, and automate and keep track of all the changes.

Or are we talking of just writing a "CREATE TABLE..." and hand it over the wall to the ops? I agree that's simpler. Not something I like to do these days.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#40

Post by Seb-C »

exevp wrote: post #15
Seb-C wrote: post #2

For a long time, I have been frustrated with the state-of-the-art about the existing ORMs. I like things to be simple, but somehow all ORMs seems to be bloated and overcomplicate a lot of things. When designing a new project, I have been trying to find a more satisfying design while avoiding the existing ORMs. I especially wanted to use proper SQL rather than reducing it's syntax to fit it in another language. This i…

tl;dr: thank god it finally has been done. Long version: i've been seriously frustrated with the state of ORM (in Javascript in particular) for years. Javascript ORM are nice and handy if all you're doing is simple CRUD stuff. If you're starting with more complex relational queries (we're using an RDBMS so why wouldn't we?) you quickly reach the limits of what the ORM can map. If you start doing more complex aggregat…

Thanks for your comment!

As you say, one of the main arguments for query-builders is allowing the support of different RDBMS. But in my experience it not only never happens, but the abstraction is never perfect and makes any unsupported edge case impossible to solve without hacking around.

There is so much that can be done with SQL that would result in a mess of inefficient spaghetti code...

Post reply on HN