😍 Мы нашли шикарную альтернативу TypeORM, Prisma и Knex 😍
Вот вроде, 2023 год, вроде, Node JS один из самых хайповых и быстрорастущий стэков, но блять до сих пор нет понятного ответа на: "Какую хорошую ORM / Query Builder выбрать?"
До недавнего времени я сказал бы: "Все гавно, выбери Go (шутка)"
TypeORM забагованный, непредсказуемый, неоптимизированный и неудобный (создание класса и дальнейшее присвоение значения параметрам через .... зачем вообще тогда было использовать TypeScript...)
Prisma неплоха, но синтасис настолько далеко от SQL , что я бы назвал его "PrismaQL", непредсказуемость тоже присутствует, Rust байндинг, который требуется для запуска и интерпретации "PrismaQL" в SQL тоже жрет ресурсы и недоступен в некоторых средах (например, serverless) и своя собственная схема за рамки которой ты никак не выйдешь, если тебе понадобится какая-нибудь особенная фича PostgreSQL
Knex еще более менее (им я и пользовался) по какой-то причине практически нет ответов на StackOverflow и самое главное – у него очень плохая поддержка TypeScript (когда .leftJoin возвращает T[] вместо T[] | null это для меня красный флаг)
В итоге, после долгих поисков и сомнений ответ наконец-то нашелся!!!
🎉 Kysely 🎉 Это проооосто потрясающий Query Builder:
– Типизация невероятно сильная: .with, subquery, json_agg, parametric condition, CASE WHEN – все это и очень много другого абсолютно автоматически и правильно типизировано
– Очень понятный и похожий на SQL синтаксис (синтаксис выражений и предикатов лучший из мною увиденных)
– Ему достаточно интроспекции типов из БД, чтобы начать работать (мы используем kysely-codegen), поэтому очень просто интегрировать в любой уже существующий проект (мы используем его в новых фичах и при рефакторинге переписываем старые, а все легаси по-прежнему на TypeORM / Knex)
– Супер легко расширять колонки интроспекции своими кастомными типами (например, брендированными типами)
– Можно самому полнолстью настроить пуллы (мы для внедрения в проект с TypeORM просто переиспользуем пулл из самого TypeORM)
Короче, если вы хотите крутой Query Builder я теперь на 100% могу посоветовать вам Kysely
P.S.
Я болел последние пару месяц, но вот наконец-то выздоравливаю, поэтому постепенно начну больше писать постов, а писать есть о чем – мы недавно запустили крупный High Load проект и постепенно переносим на него нагрузку с легаси системы
Так что ждите и мощной вам прокачки 💪
#nodejs #ts #orm #postgresql #top #hot
Вот вроде, 2023 год, вроде, Node JS один из самых хайповых и быстрорастущий стэков, но блять до сих пор нет понятного ответа на: "Какую хорошую ORM / Query Builder выбрать?"
До недавнего времени я сказал бы: "Все гавно, выбери Go (шутка)"
TypeORM забагованный, непредсказуемый, неоптимизированный и неудобный (создание класса и дальнейшее присвоение значения параметрам через .... зачем вообще тогда было использовать TypeScript...)
Prisma неплоха, но синтасис настолько далеко от SQL , что я бы назвал его "PrismaQL", непредсказуемость тоже присутствует, Rust байндинг, который требуется для запуска и интерпретации "PrismaQL" в SQL тоже жрет ресурсы и недоступен в некоторых средах (например, serverless) и своя собственная схема за рамки которой ты никак не выйдешь, если тебе понадобится какая-нибудь особенная фича PostgreSQL
Knex еще более менее (им я и пользовался) по какой-то причине практически нет ответов на StackOverflow и самое главное – у него очень плохая поддержка TypeScript (когда .leftJoin возвращает T[] вместо T[] | null это для меня красный флаг)
В итоге, после долгих поисков и сомнений ответ наконец-то нашелся!!!
🎉 Kysely 🎉 Это проооосто потрясающий Query Builder:
– Типизация невероятно сильная: .with, subquery, json_agg, parametric condition, CASE WHEN – все это и очень много другого абсолютно автоматически и правильно типизировано
– Очень понятный и похожий на SQL синтаксис (синтаксис выражений и предикатов лучший из мною увиденных)
– Ему достаточно интроспекции типов из БД, чтобы начать работать (мы используем kysely-codegen), поэтому очень просто интегрировать в любой уже существующий проект (мы используем его в новых фичах и при рефакторинге переписываем старые, а все легаси по-прежнему на TypeORM / Knex)
– Супер легко расширять колонки интроспекции своими кастомными типами (например, брендированными типами)
– Можно самому полнолстью настроить пуллы (мы для внедрения в проект с TypeORM просто переиспользуем пулл из самого TypeORM)
Короче, если вы хотите крутой Query Builder я теперь на 100% могу посоветовать вам Kysely
P.S.
Я болел последние пару месяц, но вот наконец-то выздоравливаю, поэтому постепенно начну больше писать постов, а писать есть о чем – мы недавно запустили крупный High Load проект и постепенно переносим на него нагрузку с легаси системы
Так что ждите и мощной вам прокачки 💪
#nodejs #ts #orm #postgresql #top #hot
Комментарии: 5
🦾
Я даже думал сделать о нем преписку: это вторая технология, которую мы бы попробовали, если бы не kysely
Смущает несколько вещей:
– Drizzle дальше от SQL, чем kysely: у Drizzle чтобы получить реляции можно использовать "with: { ... }", которого не существует в SQL, значит будет как-то по-своему интерпертироваться, а в kysely только SQL возможности (например, join или json_agg), причем очень качественно описанные – Для kysely достаточно иметь типизацию (type, interface) таблиц базы, что супер легко сделать даже своими инструментами интроспекции (у нас свой скрипт был, мы потом его поменяли на официальный, но скоро вернемся обратно на свой), а также очень легко расширять (импортируете в соседний файл, кастомизируем типы, используете кастомныеы типы), а в drizzle придется использовать их интроспекцию (она ломалась на наших базах из-за недоработанности по некоторым типам) + я пока вообще не понимаю как можно расширять его интроспекцию
– ИМХО у kysely более продвинутая документация
Но с учетом, что kysely сработал, у меня нет никакого повода и преимущества даже смотреть на drizzle, потому что kysely покрывает гораздо большую часть моих потребностей главная из которых – иметь максимальную типобезопасность и гибкость в написании нестандартных SQL запросов (пример в следующем посте покажу)
Смущает несколько вещей:
– Drizzle дальше от SQL, чем kysely: у Drizzle чтобы получить реляции можно использовать "with: { ... }", которого не существует в SQL, значит будет как-то по-своему интерпертироваться, а в kysely только SQL возможности (например, join или json_agg), причем очень качественно описанные – Для kysely достаточно иметь типизацию (type, interface) таблиц базы, что супер легко сделать даже своими инструментами интроспекции (у нас свой скрипт был, мы потом его поменяли на официальный, но скоро вернемся обратно на свой), а также очень легко расширять (импортируете в соседний файл, кастомизируем типы, используете кастомныеы типы), а в drizzle придется использовать их интроспекцию (она ломалась на наших базах из-за недоработанности по некоторым типам) + я пока вообще не понимаю как можно расширять его интроспекцию
– ИМХО у kysely более продвинутая документация
Но с учетом, что kysely сработал, у меня нет никакого повода и преимущества даже смотреть на drizzle, потому что kysely покрывает гораздо большую часть моих потребностей главная из которых – иметь максимальную типобезопасность и гибкость в написании нестандартных SQL запросов (пример в следующем посте покажу)
🦾
Ближе к концу года у меня появится достаточно много свободного времени и я планирую собрать 2 примера сервисов по ФОП для TypeScript и Golang
Там будет код + набор статей + возможно, серия видео, как я это все пилю
Мне кажется это будет самый наглядный способ продемонстрировать преимущества ФОП
Если есть классные примеры демонстрации возможностей ФП, ПП или ООП, буду признателен ссылке, чтобы я возможно написал тоже самое, но на ФОП
Там будет код + набор статей + возможно, серия видео, как я это все пилю
Мне кажется это будет самый наглядный способ продемонстрировать преимущества ФОП
Если есть классные примеры демонстрации возможностей ФП, ПП или ООП, буду признателен ссылке, чтобы я возможно написал тоже самое, но на ФОП
N
🦾
В ФОП все трюки ФП опциональны, поэтому ФОП намного ближе к Процедурному Программированию, чем к ФП, а Go как раз-таки процедурный, так что ФОП себя там отлично чувствует)
Реально в Go только не хватает паттерн мэтчинга, чтобы на нем можно было использовать абсолютно все трюки ФОП
Про Rust скажу, что опыт ФОП с TS и Go на нем вполне можно применить (потому что использование ФОП никак не пересекается с отличиями Rust от этих языков, например, в вопросах memory и concurrency management)
А вот для Python придется использовать некоторые трюки: поскольку в нем нет type / interface, надо использовать class, для pattern matching тоже нужны хитрости, а брендированные типы там возможно недоступны, ну и так далее
Реально в Go только не хватает паттерн мэтчинга, чтобы на нем можно было использовать абсолютно все трюки ФОП
Про Rust скажу, что опыт ФОП с TS и Go на нем вполне можно применить (потому что использование ФОП никак не пересекается с отличиями Rust от этих языков, например, в вопросах memory и concurrency management)
А вот для Python придется использовать некоторые трюки: поскольку в нем нет type / interface, надо использовать class, для pattern matching тоже нужны хитрости, а брендированные типы там возможно недоступны, ну и так далее