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

91–100 of 124 posts

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

#91

Post by lemontruth »

cryptica wrote: post #87

History keeps repeating itself. People never seem to learn anything. At first there were no ORMs, then ORMs became extremely popular and everyone was using them, then everyone learned that ORMs were a very bad idea and we stopped using them, vowing never to make the mistake again... And here we are again in 2020, ORMs are back. They will be in for a while, then out again, then in again.... Same with statically typed…

That is because many people believe in extremes. After a while people should learn that there is no absolute truth, everything has it's place.

ORM is good sometimes, pure queries are better on others. So what is needed is more like relaxed ORMS.

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

#92

Post by axlee »

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…

I'm extremely happy with Django's ORM. It never felt bloated or overcomplicated to me, especially when compared with the innate verbosity and complexity of SQL.

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

#93

Post by lemontruth »

twodave wrote: post #9
waheoo wrote: post #5

Earlier quoted context omitted.

Still not very convinced your ORM is solving a problem it didn't create but I certainly like the approach more than more traditional ORMs. I feel like Im not really the type that wants an ORM to take care of SQL or relational functionality, all I really want is an object mapper at the edges, going in, I want to pass an object and have it map into the right fields, coming out, I want it mapped to the right place. Doin…

I sort of agree here. I tend to stay away from ORMs in general, but I'd probably use one if it actually justified itself. Most ORMs I've used basically just abstract the data layer so you don't have to write own SQL, but that in itself comes at a cost (and almost all of them are bound to eventually write some really crappy SQL for you and cause performance bottlenecks). If there's not an appreciable benefit besides j…

In one way or other you cannot avoid the SQL builder, this ORM is building it in the user's code base.

I believe in ballance,

you need the query builder for simple queries (that makes most of your queries)

but the complex queries should be also supported (even if they are not portable)

We have written exactly this kind of ORM https://github.com/holdfenytolvaj/pogi

It saves you a lot of code writing, but is not taking away the power of postgresql (however it is anchored to postgresql)

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

#94

Post by Thomaschaaf »

racedude wrote: post #4
capnorange wrote: post #3

still yet to find an ActiveRecord equivalent for javascript.

What about this? https://github.com/typeorm/typeorm/blob/master/docs/active-r... (Forgive me if this isn't what you are looking for, not super familiar with ActiveRecord myself, just recalled seeing that yesterday!

https://mikro-orm.io/ is a much better typeorm alternative as it is actively being maintained. TypeORMs development has come to a halt. And many issues are not being fixed.

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

#95

Post by RandoHolmes »

waheoo wrote: post #5
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…

Still not very convinced your ORM is solving a problem it didn't create but I certainly like the approach more than more traditional ORMs. I feel like Im not really the type that wants an ORM to take care of SQL or relational functionality, all I really want is an object mapper at the edges, going in, I want to pass an object and have it map into the right fields, coming out, I want it mapped to the right place. Doin…

Personally, all I want is something that can dynamically build SQL and can hydrate into specific objects.

I have no interest in automatically building relationships, I'm completely fine doing that manually, or not at all. Which is why dapper is probably my favorite DB solution out there.

    return conn.query("select * from my_klass_table where status = :status", new { status=myStatus }).ToList();
The only thing that can be bothersome sometimes is inserts and updates. It would be really nice to have something that could auto-generate the SQL for you.

    var sql = SQLGenerator.insert(MyObject);
or

    var sql = SQLGenerator.insert(MyObject, MyKlass.InsertableProperties);
It would take care of one of the downsides of raw SQL, which is schema updates needing to be dealt with in multiple places, and would remain super simple.

I mean hell, if you wanted to get fancy you could create a generator that would figure out the columns necessary by reaching out to the DB the first time and caching it afterwards, and using a naming convention to map to the actual properties. But personally, I'm 100% fine not having that.

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

#96

Post by intellix »

gmac wrote: post #75
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…

My own TypeScript non-ORM, Zapatos, shares much of the same design philosophy (and indeed a sql`...` tagged template function): https://jawj.github.io/zapatos/ Previous discussion: https://news.ycombinator.com/item?id=23273543

thought this looked awesome when I saw it. Was waiting for a little more traction, my project to calm down and perhaps some GQL helpers to appear before jumping on board (not requesting them but just naturally picked up by the community)

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

#98

Post by vosper »

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…

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

Do you know what Hasura is doing differently? I assumed it worked the same way as Prisma does, with an intermediate server.

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

#99

Post by nesarkvechnep »

cryptica wrote: post #87

History keeps repeating itself. People never seem to learn anything. At first there were no ORMs, then ORMs became extremely popular and everyone was using them, then everyone learned that ORMs were a very bad idea and we stopped using them, vowing never to make the mistake again... And here we are again in 2020, ORMs are back. They will be in for a while, then out again, then in again.... Same with statically typed…

What I've learned from my career so far is that developers hate history. They just don't want to learn from experience. They see the new shiny thing and jump on the hype train. Then they come to conclusions like "mongo was not the right choice since we never needed to scale and our data is relational".

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

#100

Post by skrebbel »

gmac wrote: post #75
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…

My own TypeScript non-ORM, Zapatos, shares much of the same design philosophy (and indeed a sql`...` tagged template function): https://jawj.github.io/zapatos/ Previous discussion: https://news.ycombinator.com/item?id=23273543

Zapatos is amazing. I'd definitely use it if I were writing Node backends, I think its design is wonderful.

Also, I'm impressed by how beautiful and interactive your docs are. How did you do that? The show imports button, the embedded monaco modal.. Did you just code that up yourself just for these docs, or is this "just" some nice documentation template that I'm not aware of? Either way, very nice!

Post reply on HN