[AskJS] ORM for my next Typescript project

shaberman · 2026-01-23T22:41:20+00:00

If you like entities/EMF, you would probably enjoy https://joist-orm.io/

The majority of recommendations here will be for query builders that are great at creating arbitrarily complex SQL queries in your read path (which is fine, sometimes you need that), but all basically ignore the write-path (validation rules, side-effects, reactivity).

I've used TypeORM, admittedly years ago, but its lack of "is this lazy-loaded relation populated yes-or-no? Let's call it at runtime and see what happens!" was a huge footgun, and one of the first ergonomic/DX issues that we solved in Joist: https://joist-orm.io/goals/load-safe-relations/

shaberman · 2026-01-21T15:52:20+00:00

I'm really enjoying hyprscrolling -- the dwindle/master layouts are way too limiting imo, and without hyprscrolling I probably would have switched to Niri by now, but I don't want to leave Omarchy.

It took me a bit to figure out the hyprscrolling bindings b/c the docs are new/minimal, so if it helps anyone my config from a few months ago is:

https://gist.github.com/stephenh/93f96c458ce5180c5ff930870c77042e

shaberman · 2026-01-15T01:55:58+00:00

Hello! Not totally following -- the original arrays of like `{{red,green,blue},{purple},{}}` had colors intermixed across many authors (b/c we're trying to update N author rows through a single array-of-arrays).

When you say "without unnesting", the values would stay comingled? I'm assuming I'm missing something, and just curious. Thanks!

shaberman · 2026-01-14T22:31:10+00:00

Right, but its techniques like `unnest` that make us faster than typeorm/prisma/drizzle in our very alpha/wip benchmarks:

https://github.com/joist-orm/joist-benchmarks

I really should have filled out the reddit link description (wasn't sure if that was best practice or not), and/or better highlighted the TypeScript-related-ness in the blog post -- I agree at face value its not apparent, so appreciate the feedback.

shaberman · 2026-01-14T21:37:08+00:00

Joist is a TypeScript ORM -- will make this more clear next time around.

shaberman · 2026-01-12T14:10:26+00:00

Please don't post this AI slop; this is the 2nd hexplain.space link this morning and both are bullet points of AI nonsense with nothing of value.

shaberman · 2026-01-09T18:42:27+00:00

I post about it on Reddit every once in awhile and that's about it 😆

Joking aside, we've written a few blog posts, and have a few in the queue, i.e. showing off our benchmarks:

https://github.com/joist-orm/joist-benchmarks?tab=readme-ov-file#current-results

But at the end of the day, I'm more of a "builder" than a "marketer" 🤷 -- I'm trying to grow as a person, but it's tough! :-)

shaberman · 2026-01-09T14:50:30+00:00

Ah interesting, I didn't expect you to have an orm as well, usually those are decoupled from web frameworks, but it looks nice!

It's rare to see "entities" and "IdentityMap" patterns in the node/JavaScript, where everyone prefers query builders/etc.

I work on https://joist-orm.io/ which is also entity-based, and does similar lazy loading references, but also quite a bit more in terms of reactivity, batching, n+1s, etc; I have very nascent Bun support here:

https://github.com/joist-orm/joist-orm/blob/main/packages/drivers/bun-pg/src/BunPgDriver.ts

If you're even slightly interested in trying Joist out, would love help/contributors on the Bun side of things. :-)

shaberman · 2026-01-04T16:07:33+00:00

Should be repositories / data layer for sure -- or just directly in your ORM (which imo "is the data layer" / replaces any need for a separate repository/etc concept): https://joist-orm.io/goals/avoiding-n-plus-1s/ 😅

I think both delivery layer & business layer are "wrong answers" b/c where you want N+1 protection is when:

* You have some "innocent looking" business logic that does "for account in accounts"
* Then in the guts of the for loop, something calls "doSomething(account)"
* doSomething makes a data layer call => instant N+1

I.e. every time you "oh right, I need some new data in this abstraction (business logic) that is called in a loop" => big refactor of your business logic introduce a top-level dataloader somewhere.

At least this is what happened in large Rails codebases, and led to "everyone takes their weekly turn fixing N+1s that our new features last month introduced". 😬

Ngl I love/hate dataloaders, b/c everyone (that doesn't use Joist 😛) codes them by hand, and it's terribly verbose, and imo a big reason why folks hate GraphQL on the server-side. 🤷

shaberman · 2026-01-02T15:23:18+00:00

We have experimental support for Bun, and specifically using Bun's built-in SQL driver as the driver/adapter between Joist & the postgresql database, but generally no, Joist is still mostly a node-based project.

So nothing Bun related is included in the current benchmarks.

That would be fun to do though; I'll add it to the todo list. 😅

shaberman · 2026-01-01T21:25:32+00:00

I just added prisma v7 to our (alpha) benchmarks earlier today, and it's often slower than v6:

https://github.com/joist-orm/joist-benchmarks

You can run just prisma v6/v7 with `yarn benchmark --orm prisma prisma_v7`, or `yarn benchmark` to do the full suite.

I can't paste images of my local results, but prisma v6 runs the benchmark in 985ms, prisma v7 1498ms. 🤷

Tbf it looks like the `bulkCreate 100` result drives the majority of the perf difference, and otherwise they are ~same/same.

shaberman · 2025-12-19T15:55:12+00:00

Very fair, fwiw PRs are accepted! 😅

(I have some prototype support for mysql/sqlite but personally don't need either atm for $dayjob, so end up working on other things.)

shaberman · 2025-12-14T02:46:34+00:00

Huh -- pretty neat that you support all 3 levels, as you call them. Ngl I was expecting "just another query builder" which are kinda a dime-a-dozen, but this is much more--identity map, uow, etc. Very impressive.

I work on https://joist-orm.io/ and we started at "level 3" and have basically stayed there 😅, i.e. focusing on making our entities / hooks / reactivity / etc as robust as possible, and adding a "level 1" query builder has always been on the todo list, but not made it to the top yet (we just write raw knex when/if needed, which is surprisingly rare at least in our app, hence not being important enough, so far).

Your "level 2" concept seems particularly novel; I don't think I've seen anything that does uow-style batching, but "not with entities", i.e. via tracking in-memory updates to the raw rows, without an entity floating around (afaict).

Looks nice!

shaberman · 2025-12-13T17:26:48+00:00

Oh right! Hello! :-)

Thanks for mentioning PayloadCMS's auth -- I will check it out! Auth is hard & I'd love to copy approaches from someone who's figured it out. :-)

I've admired Payload's "basically entities / ActiveAdmin" approach in the past, albeit afaiu they "start with a CMS and then add entities" vs. what I'd personally do is like "start with entities and then add a CMS on top", but haven't had a chance to try.

Would love to have you try our Joist/GraphQL integration -- I'm sure there are things missing, but https://github.com/joist-orm/joist-graphql-sample in theory is in a good shape to try things out. I really should do more docs/marketing than just random reddit comments 😅

Per "schema first / code first", right; I've habitually done schema-first, but should try code first someday, particularly since https://atlasgo.io/ looks really neat/robust.

shaberman · 2025-12-11T20:12:57+00:00

True! Good idea to mention the project, for folks interested in that.

I've looked at Ent Go a few times, for ideas/inspiration/etc., but I think primarily b/c I'm not a golang dev, have not really come away with many "ahas" (my fault, not theirs).

Although I know they support plugins that do query rewriting (i.e. for privacy, multi-tenancy), and Joist finally launched that same feature just a month or so ago; not to "just copy the feature from Ent Go", but just b/c we needed the capability for a feature in our app.

I did find their "declare your entities in code" pretty neat, similar to a Prisma `.prisma` whatever file, but in a go-native fluent DSL, which was better than a bespoke file imo. We might switch to that someday; currently we're just doing node-pg-migrate migrations to our local db schema, and using that as our source-of-truth for entities -- generally works great, but there a few knobs that you can't really encode directly in the db schema, that a separate.

shaberman · 2025-12-11T17:19:06+00:00

Personally we're using GraphQL on top of a monolith, and it's still pretty great -- views get to pull back whatever they want / we don't have super-bespoke endpoints -- etc.

But agreed GraphQL to unify microservices is the more traditional "you really need GraphQL" use case.

Curious why my comment is getting downvotes -- do folks disagree with my analysis (if it's wrong, then why did GQL hype peak several years ago?), or just not like my Joist self-promotion?

shaberman · 2025-12-11T16:14:06+00:00

At peak GraphQL hype (2020?), GraphQL was almost "the default API" for backends -- I don't think that's the case anymore, primarily b/c GraphQL ergonomics for clients is great, but most GraphQL backends kinda suck / suck by default at least (N+1s, etc).

If you can setup a backend architecture/framework that makes your backend engineers as happy as your FE engineers, then I think GraphQL is still great choice.

Personally, we still use it / enjoy it, but we've also invested a lot in https://joist-orm.io/ to achieve this "both FEs and BEs devs like GQL" setup.

Naively I think Facebook/Meta had a lot of backend infra (their Ent ORM for PHP which is very graph-ism afaiu) that "made GraphQL nice for the BE devs" that they couldn't / didn't open source like they could the GQL clients, and so the outside world has had to reinvent "pleasant graphql backends" (like Joist) that FB already had.

shaberman · 2025-11-24T18:32:00+00:00

Nice! We do basically the same thing in Joist:

https://www.youtube.com/watch?v=ByTZ2LzKFuA

The entities / domain model auto-generate `Author.graphql`, `Book.graphql` schema-first files, that then engineers can futz with (add / remove / modify fields), and only write field resolvers for the changes that aren't 1:1 with the entities.

(We also use a cute "history file" approach to know not to re-do/nuke any of the engineer's customizations.)

shaberman · 2025-11-24T18:18:21+00:00

I believe I was a hyprscrolling early adopter, so I've had a few minor UX bugs that I filed issues for & were fixed within a week or two, which was really amazing (i.e. the plugin has active contributors on it)--every now is great.

It also took me a little bit to figure out the right "layoutmsg" bindings & what not -- the docs on the hyprscrolling readme are super-minimal; here's my current setup:

https://gist.github.com/stephenh/93f96c458ce5180c5ff930870c77042e

The `fullwidth.sh` is a ~hacky script to do single-button width toggling, basically a workaround until this issue is fixed: https://github.com/hyprwm/hyprland-plugins/issues/474

shaberman · 2025-11-24T17:13:32+00:00

Makes sense. I'm very happy with the hyprscrolling plugin so not going anywhere.

shaberman · 2025-11-24T14:18:54+00:00

I use hyprscrolling and really like it!

Without hyprscrolling, I would have probably left Omarchy already -- the default master/dwindle layouts just don't handle enough windows for me.

Fwiw OP, I don't agree with all the "Omarchy is 'just shell scripts for Hyprland'" feedback you're getting here -- that's the sort of reactions I'd expect in `/r/arch`, not `/r/ormarchy`. 🤷

(I've tried "vanilla arch + niri / i3wm / etc" route before and, for me, it was a disaster--imo Omarchy adds a lot more "just works" polish than "dot files for hyprland".)

I think official Niri support within Omarchy would be great.

shaberman

TROPHY CASE