🐱 Node.js + TypeScript + SQL = разочарование... но надежда есть Я уже давно пытаюсь найти некоторый оптимум в работе с SQL-ными базами на Node.js + TypeScript

Как я уже писал – ORM я не люблю, а вот что у нас с SQL Builder и Typed SQL?

На ум впервую очередь приходит Knex, но:

Во-первых, хоть у него и есть поддержка TypeScript, он мало что умеет с ним делать (не умеет в alias; select только через ублюдскую конструкцию db.ref(...).withSchema(...) и тоже часто без типизации; where + join = боль)

Во-вторых, и это, на мой взгляд, невероятно дико, вы вообще практически не найдете никакого контента на тему работы Knex + TypeScript, даже на stackoverflow (напомню, 17к звезд на Github)

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

. kysely – Knex, но который сразу написан на TS и умеет в то, что не умеет Knex

. pgtyped – пишите SQL, запускаете клиент pgtyped, он проверяет что это корретный SQL по отношению именно к вашей БД и выгружает типы

. drizzle – хоть это и ORM, но работает она как SQL Builder

. slqc – потрясающая библиотека для Go, в которой сейчас ведут добавление TypeScript (поэтому пока не готова, но надо следить)

Проблема этих технологий: они немного сыроваты и о них только начинают говорить в медиа (1, 2), но это точно то направление, куда стоит смотреть

Ок, а что если у вас уже Knex, ORM или даже чистый SQL и пересесть не получится? На данный момент мои решением являются интеграционные тесты.

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

Обязательно поделюсь всеми моими настройками, потому что я уже перенес их на 4 крупных проекта и они везде работают прям как надо.

А чем пользуетесь вы?

☹️ Нам опять нужны ORM из-за современных БД...

Я не люблю ORM поверх SQL-ных баз.

Основная моя претензия к большинству из них: они создают собственный синтаксис, который надо не только выучить, но и научиться предполагать какой итоговый SQL она сгенерит.

Пример подобной ORM Prisma.

Вот эта непредсказуемость (а чаще всего еще и не оптимизированность) и то, что мне придется учить что-то еще кроме SQL мне дико не нравится.

Я думал, что смогу навсегда отказаться от ORM и использовать Query Builder / Typed SQL, но тут выяснилась одна очень интересная деталь:

Одним из важных свойств современных БД является горизонтальная масштаьбируемость и автошардирование.

И для таких баз поддержка реляционной консистентности (соблюдение правил реляций, как CONSTRAINT в PostgreSQL) – очень сложная задача (она еще называется Referencial Integrity)

Примером таких баз могут быть PlanetScale и YDB Поэтому они перекладывают эту ответственность на пользователя, а значит мы должны в своем коде описывать какие сущности имеют указатели друг на друга и что делать при изменении / удалении / создании той или иной сущности.

Черт, а ведь это именно то, что есть большинстве ORM, потому что они идут со своей встроенной схемой...

Поэтому, рановато отказываться от ORM, НО точно нужно смотреть в сторону ORM, которые по духу близки самому SQL, например, drizzle (с ним я еще поэксперементирую и отпишусь что как)

https://github.com/drizzle-team/drizzle-orm

🎩 Господа, оказывается мы в рекурсии... и виновник этому React 18 Во времена начала моей карьеры фронтенд генерировался через шаблонизаторы на бэке

Тогда "фронтендера" называли "верстальщиком" – это был чепушила, который верстал html шаблоны, а вот уже "бэкендер" брал их, писал функции, достающие данные из базы и засовывал в эти шаблоны

Потом появились библиотеки для SPA (я начинал с Backbone, но, первую революцию сделал Angular 1)

Вот тут у нас произошло полноценное разделение "фронтендеров", которые писали всю клиентскую логику и "бекендеров", создававших под клиента API

Со временем стало понятно, что поисковики адаптироваться под SPA не хотят, да и скорость отрисовки при чистой загрузки с фронта хреновая, поэтому начали появляться фреймворки типа Next.js и Remix

Теперь frontend-ер мог не только делать запросы на бэк, но и сам в отведенной под серверное воспроизведение логике добавлять запросы к БД

И наконец, выходит React 18, который добавляет прям внутрь самого себя поддержку компонентов, которые воспроизводятся на сервере... то есть теперь, фронтендер может прям в специальных React компонентах писать запросы к БД, которые загрузятся на сервере и отдадуться клиенту...

https://nextjs.org/docs/advanced-features/react-18/server-components

Если не вдаваться в детали, то это ровно то, как первоначально была устроена веб-разработка, только теперь запросы к БД для рендеринга шаблонов может писать не бекендер, а фронт

На мой взгляд, это очень хорошая новость, потому что, работая бекендером, больше всего я не навижу писать ручки для фронта, особенно всякие CRUD-like

Если сами фронты будут заниматься запросами в БД для доставания / создания данных, я буду только счастлив, готов даже под них делать отдельные оптимизированные под фронт таблички

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

Поживем, увидем, а всем вам мощной прокачки 💪

🤸Гибкость – важнейшее свойство кода Надоело сталкиваться с тем, что каждая новая фича заставляет рефакторить пол кодовой базы?

Значит, пришло время прогнуться!

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

И вместо того, чтобы бороться с этой динамичностью, мы можем принять ее и научиться делать проекты, который готовы прогибаться под тяжестью костылей фич.

В новой главе ФОП я рассказываю про "гибкость" – насколько ваш код и архитектура способны быстро изменяться, чтобы добавлять в них НЕ заложенные первоначально требования.

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

P.S.

На самом деле, я уже почти весь ФОП написан, я просто забыл проанонсировать главы. Скоро допишу последнюю главу и начнем форсировать ФОП в массы.

Всем мощной прокачки 💪

🎥 Ищу frontend-ра для монтирования видео и анимации на базе кода Есть библиотеки, которые позволяют кодом монтировать видосы и анимации:

1. https://www.remotion.dev
2. https://motion-canvas.github.io

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

Более подробное описание вакансии по ссылке

Если интересно, пишите в телеге @davidshekunts или, буду очень признателен, если кините коллегам, которые могут быть в этом заинтересованы

🧩 "Нодовое" программирование Node programming – языки / системы, которые позволяют визуально собирать логику кода из блоков, вместо текста.

Такое очень давно применяется в анимации и создании эффектов, но слабо заходит, например, на backend программирование.

Один из самых современных проектов и интересных проектов в этой среде – https://n8n.io

Один из самых старых и проверенных (даже мной) – https://nodered.org

Попробовав подобные системы, точно могу сказать, что самому писать так код неудобно, поэтому основная их цель – собирать наборы логических блоков, чтобы люди, не умеющие программировать (менеджеры, аналитики, маркетологи, devops и т.д.) могли из этих блоков собирать какие-то цепочки, нужные в их бизнес-задачах

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

⛓ Почему Kafka такая быстрая ⛓

Статья на medium Тут 2 поинта (и бонус), которые применимы ко многим кейсам:

1. Sequential I/O (Последовательный ввод / вывод) – если мы читаем и пишем в файлы (особенно, на HDD) в разных местах – это долго (100Kb/s), но если мы только добавляем записи в конец (append) и читаем записи с определенной точки и последовательно вперед, то эти операции по скорости не уступают чтению и записи из памяти (100Mb/s).

Kafka использует append-only log, где каждая новая запись добавляется в конец, а читаем мы с определенной точки файла (offset) и до конца.

2. Zero copy read (чтение без копирования) – мы хотим начать отправлять клиенту данные из файлов хранилища с определенного места. Для этого, в стандарте, мы получаем запрашиваем данные с диска в приложение (1 копия идет в OS Buffer, 2-я из OS Buffer в наше прилодение), далее мы отправляем в Socker (3-я копия), а Socket уже в NIC Buffer (4-я копия), который уже отправляет данные получателю.

При Zero copy read мы используем системный вызов sendfile, в котором указываем какой файл и откуда читать, и указываем куда его читать, благодаря чему файл записывается в OS Buffer и оттуда сразу попадает в NIC Biffer. При этом при всем даже не задействуется CPU.

III. Бонус В этом видео не сказали еще один хак, который использует Kafka:

Все данные, которые идут через Kafka, сохраняются в отдельных файлах, называемых "сегмент". Когда сегмент достигает заданного лимита (дефолтно 1Gb) Kafka создает следующий сегмент.

У Kafka есть возможность указать время жизни сообщения (через сколько его надо удалить), так вот, Kafka не сразу удаляет это сообщение, она ждет пока в рамках одного сегмента устареют все сообщения и разом удаляет весь сегмент.

Это в разы быстрее, чем пытаться удалить каждый какие-то отдельные данные из файла.

👢 "Сапожник без сапог" 👢

Что общего между этими 4-мя сайтами?

veed.io vidyard.com getsharex.com freescreenrecording.com Во-первых, они посвящены инструментам по создания и монтажу видеоинструкций с экрана.

А во-вторых... ни на одной из этих главных страниц нет видео с демонстрацией продукта...

Вы делаете софт, который должен помогать создавать видеоинструкции и при этом не показываете ниодной видеоинструкции... 😐

Волшебная тупость

P.S.

А вообще, кто-нибудь может посоветовать приложение по захвату экрана, которое автоматически отправляет мои видосы в какой-нибудь Google Drive?

🪐 Jupyter NoteBook на Node.js + TypeScript 🪐

https://github.com/Dionid/JupyterNotebook.ts

Иногда мне бывает нужно сделать аналитику по БД или логам (будь то выгрузка для маркетинга, тех подов или просто проверить консистентность данных)

В стандарте я накидываю кучу запросов в DataGrip / Compass / PgAdmin, но это подходит для просмотра 1-3-х запросов и тем более не подходит, если вам нужно произвести какую-то логику между запросами

Более хороший вариант – воспользоваться Jupyter NoteBook, который позволяет создать файл с исполнянемыми скриптами и все это визуализировать

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

НО Я НАШЕЛ РЕШЕНИЕ

Я использовал проект tslab и добавил поверх него немного удобств (типа env-ов и возможность добавлять кастомные библиотеки)

Вот получившийся код: https://github.com/Dionid/JupyterNotebook.ts

Чтобы было нагляднее, вот вам преза, которая показывает возможности Jupyter + tslab: https://slides.com/yearofmoo/jupyter-notebooks-with-es6-and-typescript/fullscreen

Всем мощной прокачки 💪

🐘 PostgreSQL vs MySQL 🐬

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

Статья на medium (с картинками) Одна из луууучших лекций на тему сравнения PSQL и MYSQL, так еще и с конференции моих товарищей

Коротко:

- Функционально MySQL уже догнал PSQL

- PSQL на каждый connection открывает отдельный процесс, а MySQL отдельный тред, поэтому на PSQL надо использовать PgBouncer и/или PGPool-II для оптимизации работы с connection

- PSQL и MYSQL строят запросы примерно одинаково заисключением этапа Executor, где в MySQL процедуры передаются в движок, который вы используете для таблицы, а в PSQL движок всего один, что позволяет PSQL быть более оптимизированным (он конкретно знает как устроен его движок и обращается к нему напрямую)

– Статистика на PSQL знает гораздо больше о данных, которые в нем храняться (поскольку он может собирать ее напрямую из единственного движка), что в свою очередь дает возможность оптимизатору выстраивать запросы SELECT более оптимизировано

– PSQL и MySQL используют MVCC для работы с транзакциями.

PSQL при каждом изменении создает копию записи с указанием в каком id транзакции произошли изменения и помечает этим же id старую запись, (2) при удалении указывает транзакцию. Далее при процессе AutoVacuum он очистит все данные, который были удалены ранее самой старой активной транзакции.

MySQL же всегда держит 1 актуальную версию объекта, а в отдельном месте (undo_log) создает запись с тем, что было изменено (включая INSERT, UPDATE и DELETE).

Соответственно: UPDATE в PSQL потребует больше места на диске и дольше, а INSERT меньше и быстрее, также откат транзакций быстрее. Но в целом, MySQL быстрее в операциях INSERT, UPDATE и DELETE.

– Индексы бывают кластерные (храняться вместе с данными, сразу отсортированы по нему и может быть всего один) и некластерные (индексы храняться рядом)

В PSQL все индексы некластерные + PSQL поддерживает множество видов и типов индексов.

В MySQL есть кластерный индекс (PRIMARY KEY) + поддеживает только B+ Tree index.