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

61–70 of 124 posts

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

#61

Post by marton78 »

CoffeeDregs wrote: post #34

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

This is nothing special, it's commonly used e.g. with GraphQL (the `gql` tag).

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

#62

Post by Dragory »

It seems you cannot load relationships for a collection of entities easily without N+1 queries, unless I'm missing something. Based on the many-to-many section of the docs (https://github.com/Seb-C/kiss-orm#many-to-many), I would have to load relationships for each entity separately, and then if they have further nested relationships, run a query for each again. The subsequent section also mentions eager loading is not supported.

For me, being able to load relationships (and especially nested relationships) with little boilerplate and few queries is probably the most useful feature in an ORM (usually explicitly eager-loaded), so I'm sad to see it's not supported.

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

#63

Post by nerdkid93 »

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…

We investigated using Prisma v2 as a way of auto-creating a GraphQL API that directly interfaces with a PostgreSQL database, but we immediately pivoted to other solutions as soon as we discovered that the Prisma Client is really spinning up a behind-the-scenes GraphQL rust server itself to access the db. The performance of fetching a mildly complicated query (3 joins) ended up being more than three times slower than Hasura or PostGraphile.

For the life of me, I couldn't figure out why it's desirable to have an intermediary GraphQL server issuing database requests. Is that something you have also discovered while using Prisma?

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

#64

Post by peburrows »

dgellow wrote: post #54
midrus wrote: post #39

Earlier quoted context omitted.

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

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactl…

So... do pretty much exactly what ORMs with migration support already do for you?

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

#65

Post by holgerw »

holgerw wrote: post #58

Thank you for creating Kiss ORM. I have even created a HackerNews account to be able to comment on it. I have been searching for this type of ORM in Typescript for a while. I agree to write raw SQL for queries. So easy and expressive and one less layer of abstraction. I also agree on the value of the respository pattern and methods for CRUD operations to not write this SQL by hand. Making the loading of associations…

Just forgot to mention Ecto's "Multi API", that is worth knowing. Allows to construct a chain of operations as a data structure and to execute it later transactionally. You may even include operations that are part of transactional business logic but that do not hit the DB (like sending an email). (https://hexdocs.pm/ecto/Ecto.Multi.html#module-run)

As I understand KISS ORM's sequence function would also allow to express business logic transactionally and operations beyond the DB. Obviously the rollback would only effect the DB, but other failing operations can at least trigger the rollback, right? I think this is usefull as integration with external services (like email providers, payment APIs..) are really the source of runtime surprise that might fail a business operation and demand a DB rollback.

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

#67

Post by nicoburns »

peburrows wrote: post #64
dgellow wrote: post #54

Earlier quoted context omitted.

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactl…

So... do pretty much exactly what ORMs with migration support already do for you?

Yes, but write the DDL by hand rather than having it auto-generated.

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

#68

Post by williamdclt »

midrus wrote: post #39
nicoburns wrote: post #23

Earlier quoted context omitted.

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

Writing migrations by hand doesn't mean you don't have an automatic migration system. TypeORM for example can generate migrations automatically for you, but you can also generate an empty one and write the SQL yourself, and get the safety of automatic migrations

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

#69

Post by varrock »

nerdkid93 wrote: post #63
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…

We investigated using Prisma v2 as a way of auto-creating a GraphQL API that directly interfaces with a PostgreSQL database, but we immediately pivoted to other solutions as soon as we discovered that the Prisma Client is really spinning up a behind-the-scenes GraphQL rust server itself to access the db. The performance of fetching a mildly complicated query (3 joins) ended up being more than three times slower than…

> The performance of fetching a mildly complicated query (3 joins) ended up being more than three times slower than Hasura or PostGraphile.

Please forgive my ignorance, but these type of conversations always intrigue me and make me want to learn more. As a software engineer, at what point are you running these performance benchmarks, and how are you doing them exactly? How have you had time to make these decisions and pivot to other technologies?

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

#70

Post by midrus »

dgellow wrote: post #54
midrus wrote: post #39

Earlier quoted context omitted.

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

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactl…

And I assume you mean all of this is easier to do, safer, takes less effort, has more documentation, is more tested and proven and will be easier to understand by a new joiner after the one that wrote it left than using an existing, popular solution?

Sorry, I disagree.

Post reply on HN