⚓️ Эй, JS разработчик, хочешь узнать что тебя тянет на дно? ⚓️

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

🤬 Deploy Туретта 🤬

Как закалялось очко

#db #cicd #highload #deploy

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

👑 Ультиматиный подход для realtime систем: чаты, игры, IoT и многое другое 👑

За свою карьеру я вывел в прод 3 чата и 6 IoT систем и только сейчас дошел до одной важной концепции

#top #highload #db #async #actor

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

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

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

#rmq #kafka #mq #postgresql

🤑 hyUnity 🤑

Жидомассоны разбушевались и решили обокрасть бедных инди-разработчиков

#gamedev #news #unity #godot

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

👶🏾Первый язык программирования 👶🏾

Вопрос был настолько частый, что у меня есть появился конкретный ответ

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

😐 Bun и даже тут напортачил 😐

#js #nodejs #bun

🥧 Вышел Bun 1.0 🥧

Ну вышел и вышел

#js #nodejs #typescript #bun

💩 Какой язык программирования выбрать 💩

Что выбираю я: – Full-stack web приложение с кучей бизнес-логики? TypeScript
– Нужен более быстрый IO или терминальная утилита? Go
– Нужен тонкий memory management? Zig
– Сделать какую-то аналитику? Python (хотя я и на TypeScript нашел способ)
– Мобильное приложение? Cordova (она до сих пор отлично работает), на крайняк React Native
– Десктоп? Electron / Tauri
– Микроконтроллеры? JS на Mongoose OS + C
– GameDev? – Godot + GoScript / C / Zig

Почему не: – Ruby / Python – без типизации, медленные, неудобные IO
– C# – по факту старший брат TypeScript, но слишком жирный
– Java – старый, жирный, некрасивый (описал мое будущее)
– Kotlin / Scala – если бы нравилась Java, но не хотел писать на Java
– Haskell / Elixir / F# – функциональное программирование классное, но у меня не было кейса, когда оно мне было нужно, а в остальном, слишком маленький рынок разрабов
– Rust – ненавижу borrow checker
– C – нравится, но много чего привычного не хватает
– С++ – это пиздец
– Swift / Objective C – лучше C++

Есть ли у моего стэка минусы? Только они и есть

Стоит ли ориентироваться на мой список при выборе своего стэка? Нет

У вас свои задачи и предпочтения, поэтому, если он вам откликается, то значит вы узнали, что мы с вами в одной лодке, если нет, то лодки просто немного другой формы и назначения

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

"Авто-масштабирующаяся БД" – автошар-дируемая база формата 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