🖕🏽 Откажись от RabbitMQ, Kafka и других очередей 🖕🏽

(продолжение в комментариях)

#rmq #kafka #mq #postgresql

🔤 Авто-масштабирующаяся БД - Реляции + ХХХ = Ляпота 🔤

"Авто-масштабирующаяся БД" – автошар-дируемая база формата master-master (CockroachDB, YDB, ScyllaDB, Clickhouse, PlanetScale, etc.), что позволяет писать много данных быстро и с условно неограниченной параллельностью

"- Реляции" потому что в 90% таких БД не будет CONSTAINT, благодаря которым БД при изменении / уничтожении данных чистить / менять связанные с ними данные. Чаще всего, поддержание реляций в распределенных базах - задача, за которую авторы БД не могут дать требуемых каждому отдельному проекту гарантий и времени исполнения.

Думаю, большинство разрабов, годик другой поработавших с реляцими очень их любят, поэтому сложно отказаться от такой роскоши как: "если я удаляю User я хочу чтобы все связанные с ним данные тоже удалились и как мне это организовать, если нет реляций?"

И для начала, ложка дегтя: я неоднократно слышал и только со временем поверил в то, что реляции (особено CASCADE DELETE) – палка о двух концах. Это слабо контролируется, весь каскад тяжело увидеть в БД, некоторые случайные удаления могут вызвать необратимые последствия. Статейки 1, 2. Иногда лучше оставить данные на месте "до лучших времен", ведь часто при запросе пользователю или не увидит уже несвязанные с ними данные (из-за отсутствия реляции) или эти данные относятся к "фактам прошлого", которые вообще не стоит удалять.

Ок, а если надо удалить, или убрать FORIEGN KEY, или проставить deletedAt?

. Простой вариант – крон, который чистит записи "сироты" (orphaned rows)

. Надежный, но кропотливый – ручками, в каждом отдельном месте понимать что и как нужно удалить / поменять (на сложных проектах иногда приходится к такому прибегать вместо реляций)

. Кривоватый, но рабочий вариант – ORM или свой плагин, который на уровне кода применяет каскадом действия при изменении / удалении сущности. Крайне опасная и часто малопредсказуемая история (хотя, я видел подобный успешный опыт)

. Более продвинуто – закидывать событие об удалении сущности в Queue, читать отдельным сервисов и принимать нужные решения. Придется иметь и настраивать MQ, а еще и не забывать писать все эти ивенты.

. А вот самый заебись вариант это Change Data Capture (CDC) – механизм базы, который позволяет подписаться на события об изменении данных, которые она будет присылать вам на лету.

И вот именно встроенный CDC является тем самым ингридиентом ХХХ, который добавляет этим базам удобства и надежности решения вопроса с реляциями.

Поэтому, ищите новенькую топовую базу? Посмотрите чтобы у нее в комплекте шли или реляции, или CDC, а лучше и то и другое

Мощной вам прокачки 😎

P.S.

Я затронул только удаление данных, да, еще существует проверка на существование в момент записи и подобного рода вещи, но это уже решается скорее архитектурой, а не CDC да и пост итак длинный, так что как-нибудь потом

#postgresql #db #highload #ydb

😍 Мы нашли шикарную альтернативу 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

🙏 Откажитесь от TypeORM, в пользу … 🙏

Мне есть очень много чего сказать про ORM в целом, и особенно на Node.js...

Я поработал с ORM на Golang, PHP, Python, C#, поэтому есть с чем сравнивать.

Начну как минимум с того, чтобы сразу обозначить свою позицию: TypeORM – несусветное гавно.

Почему, рассказываю в статье:

Ссылка на статью А дальше, буду писать кучу статей на тему ORM, потому что мы с командой решили выбрать новую для всех своих проектов и мне будет что вам рассказать.

P.S.

Prisma тоже не подарок, но точно лучше TypeORM.

#db #postgresql #mongodb #nodejs #typescript #orm

😮 Knex.js обновил документацию и подход к TypeScript 😮

Вау, это прям приятно. Предыдущая их документация была нечитабельной простыней дерьма, а тут...

https://knexjs.org

Так ко всему прочему они подошли с новой стороны к типизации, что выглядит очень неплохо

Если вы уже потестировали, то напишите в комментарии как оно, а если нет, то я в ближайшие 2 неделе протестирую сам и отпишусь

#nodejs #typescript #postgresql

👴🏿 Заветы Senior-ов. Базы данных 💾 Еще одна черта отличающая Senior от Middle разраба:

| Middle разработчик умеет пользоваться БД, а Senior умеет выбирать БД Рассказываю в заметке, что, я считаю, должен знать Middle и Senior разработчик про БД

#db #postgresql #mongodb

🐘 Локальное и удаленное шардирование / партицирование в PostgreSQL Всем привет!

На полноценные посты меня сейчас не хватает, но есть много маленьких полезных заметок, которыми я буду постепенно делиться с вами

Ссылка на статью #db #postgresql