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

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

#101

Post by nerdkid93 » Thu, Sep 03, 2020, 8:22 PM UTC

vosper wrote: post #98

nerdkid93 wrote: post #63

Earlier quoted context omitted.

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

I'm not sure about PostGraphile, but Hasura I know transforms a graphql request into a SQL request that can return the JSON response expected as part of the GraphQL spec. I believe that's the reason that Hasura only works with PostgreSQL, since it has the necessary SQL functions to generate arbitrary JSON objects.

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

#102

Post by aidos » Thu, Sep 03, 2020, 8:54 PM UTC

vosper wrote: post #98

nerdkid93 wrote: post #63

Earlier quoted context omitted.

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

Hasura is a gql server too. I can’t say how it’s different from prisma, but it works by running as a frontend process to your Postgres dB. You issue gql, it converts to sql and then back to gql on the way out.

Some of the things it does differently though. They declare access permissions in the dB (Hasura tables, managed through their api) and they work those into the queries. They do this by building a json object with any of your variables in and then reference those within the query. This allows for a neat trick where they can run the same query for different clients by starting with multiple rows (one per client) containing their respective variables. This is particularly great for subscriptions. They can poll the dB, to grab all data for all connected clients in a single hit, and then if anything has changed, they can notify the external clients about it.

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

#103

Post by electrum » Thu, Sep 03, 2020, 9:49 PM UTC

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…

Jdbi works the way you describe: https://jdbi.org/

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

#104

Post by gmac » Thu, Sep 03, 2020, 10:10 PM UTC

skrebbel wrote: post #100

gmac wrote: post #75

Earlier quoted context omitted.

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!

Thanks. I just coded it up myself[1]. :)

As an educator, I’d say the docs are probably the most important element of a library.

[1] https://github.com/jawj/zapatos-docs

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

#105

Post by EdwardDiego » Thu, Sep 03, 2020, 10:12 PM UTC

electrum wrote: post #103

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…

Jdbi works the way you describe: https://jdbi.org/

Yep, I've been enjoying JDBI for a new microservice. /me makes sign of cross and throws holy water on legacy Hibernate code it's replacing.

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

#106

Post by Juliennng » Thu, Sep 03, 2020, 10:13 PM UTC

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've been playing with tagged-template for a while now and have a similar solution at work. I wanted to build something like that for a while now, well done!

I wrote about tagged template literal on my website : https://cavaleiro.fr/posts/template-literals/

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

#107

Post by thunderbong » Thu, Sep 03, 2020, 11:01 PM UTC

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…

In Ruby, I have always been extremely fond of the Sequel ORM - http://sequel.jeremyevans.net/

The amount of expressiveness and capability it gives is simple outstanding. It lets me drop into pure SQL as well as write statements which are simpler and easire to grok when I'm using the ORM level abstractions.

Sequel for SQL users - http://sequel.jeremyevans.net/rdoc/files/doc/sql_rdoc.html

Cheat sheet - http://sequel.jeremyevans.net/rdoc/files/doc/cheat_sheet_rdo...

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

#108

Post by Seb-C » Thu, Sep 03, 2020, 11:32 PM UTC

mqus wrote: post #81

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…

What do you think about ORMs like Androids Room[1], where you do specify your own queries with sql (by annotating abstract methods) and can bring your own model and the ORM creates the database schema in the database and gives you access to easy insertion methods. I don't know how Room does it but darts floor library(which is similar)[2] then generates the code that is necessary, in addition to a very slim runtime la…

Thanks. I do not have experience with Room, but I usually prefer to control and know what is happening in my schema.

For example, if your schema is automatically handled, how do you both rename and change the type of a column without losing data? Would it perform a delete and a create?

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

#109

Post by Seb-C » Thu, Sep 03, 2020, 11:38 PM UTC

exevp wrote: post #55

midrus wrote: post #43

Earlier quoted context omitted.

>I find that most of the production features you mentioned are actually more difficult using a fat ORM. Prisma doesn't look like the traditional ORM to me. In fact, the library from the OP uses classes, which prisma and Knex do not use > How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with ? Would have been a 3 minute task if all i had to write was just SQL In…

> In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins. That's true, although the most frustrating percent of the cases :) I think what KISS will eventually need is some simple toolbelt for the basic CRUD queries, e.g. expanding lists of…

> expanding lists of column names

I am not sure about what do you mean here?

> dealing with casing (snake_case to camelCase)

This is one of the opinionated parts of kiss-orm I guess, because I specifically do not want to implement this.

I think having consistency in the naming of the properties/columns is more important. I would rather break the naming convention by having snake_case properties than automagically rename properties.

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

#110

Post by Dragory » Thu, Sep 03, 2020, 11:54 PM UTC

WkndTriathlete wrote: post #74

Dragory wrote: post #62

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…

Agreed on the N+1 query problem, but I'm a bit mystified why people still choose ORMs for any projects with even a moderate level of database complexity. When using a straight SQL layer (JDBC or the basic features of KISS-orm) the query is in SQL form and the performance characteristics of the query are obvious from the query or can be analyzed easily by taking the query and running it through the database's query an…

In my experience, 99% of the relationships I fetch fit the basic one-to-one, one-to-many, many-to-many definitions that pretty much all ORMs support. For these cases, the queries are generally more than efficient enough and there's little reason to reinvent the wheel and implement the code for fetching those relationships yourself.

For anything more complex, I agree. But for the common case of fetching simple and often (depending on your project) nested relations, I definitely enjoy the abstraction provided by ORMs.