Комментарии 12
Я вижу у Вас в примере - include: { posts: true }. Чем это лучше Post.includes(:author).limit(10) ? и нет ли тут протекающих абстракций?
Да, абстракция протекает. Но:
ActiveRecord протекает в синтаксисе:
.includes vs .joins vs .eager_load
Какой использовать? Нужно знать SQL
Когда LEFT JOIN, когда подзапрос? Нужно знать реализацию
Prisma протекает в производительности:
include всегда работает одинаково
Но может быть медленным
Отсюда и появился prisma-sql
Prisma уменьшила "протечку" с уровня синтаксиса до уровня производительности. Разработчик пишет рабочий код без знания SQL. Но для оптимизации всё равно нужно понимать, что происходит под капотом.
prisma-sql пытается заткнуть последнюю "протечку" - производительность - не увеличивая сложность API. Та же декларативность, просто быстрее.
О господи. Статья не про ИИ и вместо ссылки на телегу - ссылка на гитхаб.
А по делу: для себя перепробовал многие эти подходы и остановился на чистом sql. В typescript через template strings очень удобно. Экранирование, задание возвращаемого типа.
Конечно приходится следить за опечатками в названии полей и иногда лезть в бд и вспоминать их, но по скорости - нет равных. Запрос любой сложности как на ладони.
Если честно, удивляет только одно, почему это не сделали раньше внутри самой Prisma
Hibernate это худшее что могло случиться с Java как минимум,юзаю только r2dbc,никаких orm
Действительно, спасибо
https://github.com/multipliedtwice/prisma-to-sql
Звучало отлично, думал это новая фича призмы, как недавние нативные join (если кто не знал, всё это время они выполнялись в рантайме, хоть и в rust части движка). Но пробовать либу без единой звёзды в проде никто не даст. Буду следить за успехами!

Prisma ORM на скорости чистого SQL? Конвертация JSON-запросов в SQL-строку