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

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 by a very long shot in my opinion.

[1] https://www.prisma.io/docs/understand-prisma/why-prisma

Sorry got ahead of myself there:

https://www.graphiti.dev/js/

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 aggregations or stuff like window functions and the likes, you most certainly have to fallback to raw queries, usually rendering the whole mapping function of the ORM completely useless.

Also projects like Knex.js (or for example HQL in the Java world) look nice at first but are mostly useless IMHO because they just replace SQL with another syntax you have to learn. Why stay with the language everybody familiar with RDBMS can speak if you can invent some useless abstraction, right? And please don't tell me you want to support multiple RDBMS in the same codebase. How often is this really an important use-case?

I really loved the way MyBatis did this in Java: instead of mapping tables to objects, mapping result sets to objects and leaving the full power of SQL to the developer.

Always wanted (and actually started something almost the same as you did some weeks ago) to basically do MyBatis in Javascript and never had the time to.

Thanks for getting it started.

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.

I'm trying to build that:

https://github.com/stephenh/joist-ts/

Disclaimer docs aren't amazing yet, so looking through the examples/integration tests are the best way to see how it works.

Prisma has a few mentions in this thread; joist's differentiator is that it leans more "domain model" i.e. validation rules, derived values, and business-logic-y things being in the model.

Which is not for everyone (i.e. the ORM-less approach of the OP/kiss-orm is fine too), but if you're looking for that sort of thing...

Joist also has a novel approach for modeling the lazy-initialized collections/references of ORMs, which is historically tricky in Node/JS/TS. In Joist, all collections/references require `await` to access by default, but that gets tedious very quickly, so you can use populate hints to get a now-synchronously-accessible sub-view of the object graph.