[exevp]

I find that most of the production features you mentioned are actually more difficult using a fat ORM.

How many hours have i wasted figuring out how i can write and map some complex joins or aggregation query with <insert ORM name here>? Would have been a 3 minute task if all i had to write was just SQL ...

Plus i have a hard time seeing the benefit of Prisma. You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise so it feels like a complete waste of time to come up with the DSL in the first place. I can only imagine the hard time you have once you first have to break out of the frameworks cage because you hit a case which isn't easily solved by the framework itself ...

[midrus]

>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 <insert ORM name here>? Would have been a 3 minute task if all i had to write was just SQL

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.

[exevp]

> 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 column names, dealing with casing (snake_case to camelCase). So making the stuff you write 90% of the times easy without inventing a custom SQL abstraction.

MyBatis (which i mentioned in another comment) approached this for example with sql snippets one could re-use in queries.

KISS enables the same thing by allowing nesting of tagged sql strings. I guess time will show which additional helpers are needed to make the devs life easy/reduce the boilerplate for the simple queries.

[Seb-C]

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

[exevp]

> I am not sure about what do you mean here?

Given i have defined the columns of interest in my data objects anyways...

  class User { name = null; email = null; }

... i wouldn't necessarily have to repeat them when writing my SQL:

   sql`SELECT ${Object.getOwnPropertyNames(new User).map(camelCase).join(', ')} FROM users`

Of course using a better helper function.

There's a few repetitive tasks when writing SQL where don't necessarily need a powerful query builder but still end up writing a few handler functions. Shipping some common helpers with the framework might be handy.

[Seb-C]

I see what you mean. Indeed, more helpers would be ... helpful I guess, but for now I only implement what I really need and feel like is necessary.

For your specific example, what is wrong with `SELECT *`?

[christophilus]

> How many hours...?

Plenty. Just this week, I spent the better part of a day trying to figure out why customers were losing data. Turns out it was a bad ActiveRecord polymorphic definition that was written over 4 years ago, but which only started surfacing recently due to overlapping ids in the relevant tables. When I looked at the generated SQL, the bug was obvious. But looking only at the ActiveRecord definitions, the bug was nonobvious. Give me plain SQL all day everyday. I’m tired of ORMs.

[2color]

Thanks for sharing your thoughts about Prisma.

> Plus i have a hard time seeing the benefit of Prisma

Prisma is supposed to improve your productivity and confidence when working with a database. It does so with a strong focus on type safety.

Most ORMs and query builders in the Node.js/TypeScript ecosystem do not provide the level of type safety that Prisma does.

For example in a blog with users and posts (1:n) querying a user and related posts looks as follows:

  const user = await prisma.user.findOne({
      where: {
        id: 1
      },
      include: {
        posts: true
      }
    })

  console.log(user.posts)

The user object will have the correct TypeScript type, including the posts object. If you remove the include object from the findOne call and avoid fetching related posts, the user's type will change. This approach to type safety helps in catching many problems at build time.

It's possible because of the Prisma schema, which is the single source of truth for both the database schema and the generated TypeScript client.

You don't have the burden of mapping between the database schema and the types in their application. Besides that, it's a declarative and concise description for the database schema and is database agnostic.

The type safety features come at "zero-cost" because you don't have to write all the TypeScript types and mappings to the database. Prisma generates the TypeScript client from your Prisma schema.

> You are learning an entirely new DSL just to define your schema - which actually isn't that far off standard JS or TS syntax-wise

The Prisma schema is actually fundamentally different to JS or TS because it's declarative rather than imperative.

[exevp]

I understand where Prisma is coming from with the custom DSL: they want to guarantee type safety and therefore need to know exactly the structure of the types the result set is supposed to be mapped to.

In most other languages you'd shout "reflection" but unfortunately, there is no such thing in TS. Hence the custom DSL so you know, while parsing, what the structure of the type is.

I'm just asking myself: why invent the custom DSL for that? You could just use babel to parse TS types. Sure babel is quite the dependency but in a node environment, that wouldn't be a bigger concern to me then inventing a custom DSL instead.

You could even use TS decorators to add more metadata like sequences and (foreign) keys to the TS types.

[2color]

> I'm just asking myself: why invent the custom DSL for that?

Fair question. Besides all the type safety features I mentioned above, having the DSL (Prisma schema) allows generating database clients in more than one language, e.g. Go without the database declaration being tied to a specific programming language.

It's also the reason it's declarative in contrast with most ORMs that rely on an imperative language to define these mappings.

The second reason is that the Prisma schema is used for declarative database migrations with Prisma Migrate.

The third reason is that Prisma supports introspection of an existing database. So if you were to introduce Prisma to an existing project, you'd introspect the database which would populate the Prisma schema based on the database schema. This would then allow you to use Prisma for migrations.

Could all that be achieved without a custom DSL? Perhaps. But it'd probably tie Prisma to a specific language ecosystem and would diminish the developer experience of the features it offers.

I can understand the reluctance around a new DSL, but in reality, I haven't seen many complaints about the need to use it.

[joshmanders]

I have this same stuff in TypeORM but don't have the DSL issues that exevp mentioned..

[2color]

I think this article does a good job of comparing the two if you're familiar with TypeORM: https://medium.com/better-programming/prisma-vs-typeorm-60d0... which compares the two.

Most of exevp's comment about the Prisma schema are a non-issue given an understanding of the value it provides. But I can understand the reluctance to learn yet another DSL. But in my experience, if you've worked with relational databases, it's a breath of fresh air to be able to define your database schema with it.