😳 А еще есть serverless и edge базы данных... Дважды переписывал пост, потому что его сложно сформулировать, поэтому оставлю "пробежку по верхам":

i. Где разворачиваем: - Self-hosted – арендовали сервер, сами развернули и поддерживаем БД, платим за железо.
- Vendor-hosted – арендовали базу у какого-нибудь сервиса и он сам занимается поддержкой инстансов и железа.

ii. За что платим в Vendor-hosted - "Classic" БД – платим за инстанс / железо
- Serverless БД – платим за вычисления + объем хранимых данных

iii. Vendor-hosted Serverless Обычно, предполагает специальные БД, разделеные на 3 части: слой хранения данных, слой вычислений и координатор.

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

YDB, Cockroach, PlanetScale, Neon (serveless PostgreSQL) Преимуществом vendor-hosted serverless БД называют "бесконечное масштабирование" (место на дисках в этом случае, может быть, на порядок дешевле, потому что наши данные лежат в перемешку с чужими) + уменьшение костов, поскольку мы платим только за вычисления и небольшую денежку за хранимые данные.

И если масштабирование правда классная фича, то вот прайсинг за вычисления – более опасная история, потому что "вычисления" это в том числе сколько БД прочитала строчек, а значит, если у вас поиск не по индексу, вы заплатите за каждую прочитанную строчку, что из 10 центов может превратиться в 5000$ (эх, не могу найти ссылку на статью, но вы нагуглите кучу таких историй).

iv. Edge Тут больше про брендинг: Edge DB должны давать возможность Edge functions, запускающихся рядом с клиентами, ходить в самый ближайший к ним инстанс БД, а значит основная их фишка – геораспределенность.

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

ScyllaDB, CouchDB, Cassandra Единственная БД, которую сейчас можно найти под тэгом "edge database" это Turso – распредленный SQLite. НО самое смешное, что она при этом master-slave (то есть все запросы на write маршрутизируются на master реплику) причем чуть ли не с serializable транзакциями, а это как-то нехрена не "Edge"...

По ощущениям, это тоже самое, что сделать реплику PostgreSQL для чтения в регионе пользователей, при этом оставив все фишки и плюшки постгресса. Надо еще почитать / попробовать.

v. Когда что использовать: - Self-hosted всегда дешевле, поэтому если у нас средний+ проект, есть DevOps, умеющий в БД и желание сократить издержки, то можно переходить на Self-hosted.

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

А вот использовать ли вам Classic / Serverless / "Edge" зависит чисто от ваших задач и команды и я буду разбирать каждого отдельного представителя с рассуждениями о задачах, для которых это могло бы подойти.

Серебрянной пули опять нет, если брать среднее по больнице, мой совет: "научитесь в classic vendor-hosted" – и будет вам счастье.

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

😡 Не успели понять что такое Serverless, а тут хуяк и Edge Functions Давно хочу написать про отличия self-hosted, serverless containers, serverless functions и тут еще и edge functions подъехали, так что пора:

- Self-hosted – арендовали сервера, развернули там docker-compose / nomad / kubernetes, веселимся как можем

- Serverless containers – сделали докер образ, задеплоили его на площадку и он сам там крутиться, масштабируется и подобное.

Yandex Serveless Containers, Google Cloud Run, AWS Faragate Кстати, мой любимый способ, когда нет Dev Ops.

- Serverless functions – создаете приложение с 1 точкой входа (в 90% это HTTP запрос) и в обработке этого запроса пишите практически все что угодно.

AWS Lambda, Google Cloud Functions, Netlify Functions

Из особенностей: (1) каждый запрос будет создавать "мини виртуалку" (для этого нужно время, которое называется "cold start"), где будет подниматься ваш код, а потом, если нет трафика, ложится, (2) вы привязываете их запуск к определенному региону, (3) ограничения по памяти, времени отработки и нативным API железа.

- Edge functions – тоже самое, что и serverless functions, НО вместо мини виртуалки, ваш код запускается (условно) в рамках уже работающего приложения (это как сделать eval).

Особенности: (1) не занимает практически нисколько времени для запуска, (2) на данные момент на JS ограничено возможностью только делать HTTP запросы (+ WS), (3) более похоже на CDN, поэтому МОЖЕТ запускаться прям на ближайшем доступном сервере от клиента.

Vercel Edge Functions, Netlify Edge Functions Подробнее буду разбирать в следующих постах, но сразу скажу: я написал "МОЖЕТ" с большой буквы, потому что главной проблемой в скорости для большинства приложений является скорость запросов к не распределенной БД, поэтому на данный момент Edge Function дают большое преимущество над Serverless Functions, когда вы указываете их регион запуска рядом с вашей БД, а не рядом с клиентами.

Сам с Edge Functions еще только начал играться, но с остальными видами какой-то опыт есть, так что продолжу дальше делиться инфой + некоторыми интересными рассуждениями.

Тизер: все варианты гавно в том или ином контексте, тут нет и никогда не будет "оптимального", тут все невероятно сильно зависит от контекста. Универсален только совет: "как минимум научитесь делать self-hosted" – а все остальное уже будет сильными оптимизациями поверх этого в зависимости от контекста.

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

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

🫥 И Go в случается Goвно Раз уж я заговорил про анализ библиотек, недавно произошел случай, который отлично демонстрирует написанное выше:

Http пакет для Go gorilla/mux был заархивирован.

Там 19к звезд, он используется более 100к проектов, но еще в 2018-ом году авторы позвали на помощь в поддержке проекта и, никто так и не отозвался

Там такаяже история с релизами, как и в objection.js – с 2019-го года особо ничего не менялось.

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

По-идее, ничего страшного не произойдет: если они использовали стандартные HTTP функции, они продолжат с ними жить, но любые изменения в стандартной библиотеке (на которой он основан), починка багов^ развитие в сторону HTTP 2.0 или какой-либо дополнительный функционал уже появляться не будет

Если кому интересно, на go я всегда использовал echo и с ним подобных проблем не предвидится

🌟 Зведочки на JS репозиториях 🦞 В прошлом посте я ни разу не написал "смотрим на звездочки"

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

Как только вы перестанете смотреть на здвездочки и начнете смотреть на сам код, вы станете настоящим программистом Серьезно, почитайте код: самой либы, PR-ов, релизов, тестов

Кроме того, что вы сможете отыскать брилианты, так ко всему прочему многому научитесь

Например, я недавно наткнулся на TS либу для SQL, которая умеет парсить SQL строчку, используя для этого описание AST дерева SQL, с компилятором, навписанным на TS.

Вот она https://github.com/ivank/potygen, а вот ее код описания SQL AST дерева Там 49 звезд (одна из них моя), но при этом проект может в 10 раз больше по типизации, чем Knex (посмотрите на примеры SQL, которые он может парсить), я невероятно впечатлен

НО она не проходит по другим признакам, описанным выше, поэтому пока рановато для production

👇🏾 Как выбрать библиотеку не отстрелив себе тестикулы Вот смотришь на либу в Github и не понимаешь стоит ли ее использовать, или нет

Напишу набор действий, которые делаю я:

– Почитайте код релизов – если библиотека должна развиваться, а релизы были давно или они про изменение доки / 1 строчки кода, то плохо

– Много ли контрибьютор и как часто они коммитят

– Читаем Issues (особенно закрытые) – сколько закрыто, как давно, как много открыто, есть ли среди них критичные для вас моменты. Я находил либы, в которых авторы просто подряд закрывали абсолютно все Issues без ответа и люди недоумевали, что происходит.

– Как много вопросов и ответов на StackOverflow, если много, то хорошо

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

– Лучше, чтобы библиотека была в рамках одного стэка – например, в Prisma у вас будет идти еще Rust библиотека трансляции запроса в SQL, а значит чтобы поправить в ней баг, придется править не только JS / TS код, но и Rust

– Есть ли тесты на код – если есть, то это лучше, чем документация

Пример на Objection.js Под постом выше спросили про то, что я думаю, про Objection.js, я пошел освежить память, потому что давно им не пользовался:

– Релиз есть свежий, но он один... до этого релизами не пользовались, поэтому идем в commits и видим что коммиты раз в полгода... для ORM – очень плохо, потому что БД и задачи к БД постоянно развиваются, значит и ORM должна

– Среди контрибьюторов есть создатель Knex – это хорошо

– Идем в Issues и видим, что создатель не может поддерживать эту либу (а энтузиастов так и не нашлось) и сам называет ее устаревшей

На этом уже можно остановится и подвести итог – библиотека мертва

🐱 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 или, буду очень признателен, если кините коллегам, которые могут быть в этом заинтересованы