Привет! Меня зовут Давид Шекунц, я – Full-Stack Go & TS Tech Lead и вы находитесь на сайте с постами из моей 🦾 IT-Качалки 💪
🪲 Ошибки надо возвращать (return), а не выкидывать (throw)
Короче, я раньше к этой теме подходил деликатно, типа "это полезно", "было бы круто, если бы вы делали так", "ну если вы решитесь" и так далее, а сейчас полностью убедился, что это точно верный подход и другого советовать не хочу.
У этого подхода куча преимуществ: (1) вы четко видете какие виды ошибок возвращаете (особенно если создаете кастомные ошибки), (2) нет неявных перехватчиков ошибок, (3) try очень громоздкая и некрасивая конструкция, которая может добавить несколько уровней вложенности и много других полезных пунктов.
Ну и всегда был концептуальный вопрос, которому посвящены множество конференций и статей: почему я должен выбрасывать (throw) ошибку, которая является нормальной частью бизнес-логики (например, NotFound на сущность, которой реально может не быть) при том, что это может убить мою программу, если не будет отловлено.
Что так резко меня убедило?
1. Исторически так было в C.
2. Далее эту фишку подхватил Go.
3. В Rust такая же история, НО они возвращают типа монаду Result<T, Error>.
4. И тут я узнаю, что в Zig (языке, на который я делаю сейчас огрмную ставку) прям встроенный оператор Union Type для возврата ошибок.
Ну, а про функциональные языки даже говорить не буду, там это просто стандарт, тоже через монады.
Если использовать TS, то самый адекватный вариант это: type Result<T, E extends Error = Error> = T | E – могу потом рассказать почему.
Да, есть некоторые места (например, валидация отдельных свойств), где это может сильно засрать код, но и для этого есть решение (об этом в следующих постах)
Мне теперь интересно: насколько вам заходит идея возвращать ошибки, а не выбрасывать их?
Короче, я раньше к этой теме подходил деликатно, типа "это полезно", "было бы круто, если бы вы делали так", "ну если вы решитесь" и так далее, а сейчас полностью убедился, что это точно верный подход и другого советовать не хочу.
У этого подхода куча преимуществ: (1) вы четко видете какие виды ошибок возвращаете (особенно если создаете кастомные ошибки), (2) нет неявных перехватчиков ошибок, (3) try очень громоздкая и некрасивая конструкция, которая может добавить несколько уровней вложенности и много других полезных пунктов.
Ну и всегда был концептуальный вопрос, которому посвящены множество конференций и статей: почему я должен выбрасывать (throw) ошибку, которая является нормальной частью бизнес-логики (например, NotFound на сущность, которой реально может не быть) при том, что это может убить мою программу, если не будет отловлено.
Что так резко меня убедило?
1. Исторически так было в C.
2. Далее эту фишку подхватил Go.
3. В Rust такая же история, НО они возвращают типа монаду Result<T, Error>.
4. И тут я узнаю, что в Zig (языке, на который я делаю сейчас огрмную ставку) прям встроенный оператор Union Type для возврата ошибок.
Ну, а про функциональные языки даже говорить не буду, там это просто стандарт, тоже через монады.
Если использовать TS, то самый адекватный вариант это: type Result<T, E extends Error = Error> = T | E – могу потом рассказать почему.
Да, есть некоторые места (например, валидация отдельных свойств), где это может сильно засрать код, но и для этого есть решение (об этом в следующих постах)
Мне теперь интересно: насколько вам заходит идея возвращать ошибки, а не выбрасывать их?
Развернуть
👋 Svelte уходит от TypeScript и как это поменяет мир типизации
Новостью уже обсудили 100к раз, но я запрыгну на хайп-трейн и расскажу вам кое-что интересное и базируется это на 2-х фактах:
1. Я никогда в жизни не хочу писать приложения без типизации.
2. Я не считаю, что при создании библиотек типизация обязательно нужна.
И TypeScript дает для этого в 10 раз больше, чем большинство других типизированных языков:
Есть такой очень странный казус – когда ты пишешь некоторый абстрактный код, который потом будет использоваться в разных контекстах кодовых баз других разработчиков, типизация может начать очень сильно мешать.
Да, вы 1000% должно протипизировать инпуты (аргументы функций) и аутпуты (результат функций), но содержимое этих функций авторы библиотек часто приводят к any, потому что в таком коде тебе нужен перформанс и НЕтипобезопасные операции, учитывающие контекст.
Код библиотек должен подстраиваться под контекст разработчика, а значит быть "динамичным", а не "статичным".
НО это не означает, что типизация тут мешает. Абсолютно нет. Потому что по итогу вам НУЖНО описать правильные типизированные входы и выходы.
И тут TypeScript, позволяет вам написать код либы на JS (или даже 1 отдельный файл) и далее покрыть его .d.ts, что по факту хедер файл .h из мира С.
То есть, мы пишем нетипобезопасный код так, как нам нужно, а потом покрываем его типами, чтобы это было удобно другим разработчикам.
Такой подход претит большинству TS разрабов, НО не из-за "неправильности" подхода, а потому что большинство проектов написанных таким образом – гавно с точки зрения типизации (типы неполные, ошибочные, супер-сложные и невозможные к кастомизации)
И опять же "НО": библиотеки имеющие хреновые .d.ts просто были в первую очередь написанны без оглядки на TS, он появился потом, как придаток.
Если же создатель библиотеки будет писать .js сразу с учетом того, как это будет работать в .ts вы даже разницы не заметите.
+ всегда можно сделать хак, где только 1-n файлов из всей либы на js, а остальные, на ts, если нужно.
Короче, наша задача – использовать типизацию во-благо себе и другим разрабам и иногда это означает пойти не по "стандартной дорожке", а по "правильной дорожке".
Всем мощных дорог 🛣️
1. Я никогда в жизни не хочу писать приложения без типизации.
2. Я не считаю, что при создании библиотек типизация обязательно нужна.
И TypeScript дает для этого в 10 раз больше, чем большинство других типизированных языков:
Есть такой очень странный казус – когда ты пишешь некоторый абстрактный код, который потом будет использоваться в разных контекстах кодовых баз других разработчиков, типизация может начать очень сильно мешать.
Да, вы 1000% должно протипизировать инпуты (аргументы функций) и аутпуты (результат функций), но содержимое этих функций авторы библиотек часто приводят к any, потому что в таком коде тебе нужен перформанс и НЕтипобезопасные операции, учитывающие контекст.
Код библиотек должен подстраиваться под контекст разработчика, а значит быть "динамичным", а не "статичным".
НО это не означает, что типизация тут мешает. Абсолютно нет. Потому что по итогу вам НУЖНО описать правильные типизированные входы и выходы.
И тут TypeScript, позволяет вам написать код либы на JS (или даже 1 отдельный файл) и далее покрыть его .d.ts, что по факту хедер файл .h из мира С.
То есть, мы пишем нетипобезопасный код так, как нам нужно, а потом покрываем его типами, чтобы это было удобно другим разработчикам.
Такой подход претит большинству TS разрабов, НО не из-за "неправильности" подхода, а потому что большинство проектов написанных таким образом – гавно с точки зрения типизации (типы неполные, ошибочные, супер-сложные и невозможные к кастомизации)
И опять же "НО": библиотеки имеющие хреновые .d.ts просто были в первую очередь написанны без оглядки на TS, он появился потом, как придаток.
Если же создатель библиотеки будет писать .js сразу с учетом того, как это будет работать в .ts вы даже разницы не заметите.
+ всегда можно сделать хак, где только 1-n файлов из всей либы на js, а остальные, на ts, если нужно.
Короче, наша задача – использовать типизацию во-благо себе и другим разрабам и иногда это означает пойти не по "стандартной дорожке", а по "правильной дорожке".
Всем мощных дорог 🛣️
Развернуть
👊 Когда кто-то наезжает на Go, батя идет быть *бычы
Наткнулся на статью, где, на мой взгляд, бездарно срут на Go. И я бы прошел мимо, если бы не кол-во лайков и видеоразборов на YouTube...
Никому не позволю обижать моего малыша.
Претензия автора: "Слишком мало синтаксического сахара, не хочу писать руками, это придумали старперы, которые не хотят смотреть дальше С"
Еще, он как стандартный автор подобной статьи приводит намеренно исковерканные примеры, а в противовес предлагает язык D... ну, опустим эти детали, они присущи многим статьям подобного рода (но почему же D... какой странный и абсолютно безумный выбор...)
Мой ответ таков: – Кол-во строчек кода не должно быть меркой качества кодовой базы. Чаще всего, дополнительные строчки – это более детальное раскрытие мысли от 1 строчки, которая может компактнее, но намного менее понятным образом что-то объяснить (пример, if против тернарника).
Да, когда ты пишешь сам свой код, хочется воспользоваться красивым тернарником, возможно, даже двойным-тройным, но каждый раз, когда ты наткнешься на такую конструкцию, написанную кем-то другим твой пукан загорится.
Поэтому понятность кода, важнее его кол-ва и Go со своим лаконичным синтаксисом заставляет разработчиков писать такой код.
– Тебе не НУЖЕН синтаксический сахар, ООП, дженерики и подобное, чтобы делать приложение с быстрым IO и не заниматься менеджментом памяти Еще одна из претензий автора: "Его сделали люди, которые кроме С ничего не хотят изучать" – наоборот, его сделали люди, которые выучили столько языков, что поняли, что С и процедурщины достаточно, чтобы максимально качественно, просто и производительно решать вопросы массивного IO и не решать вопросы с памятью, засчет встроенного Garbage Collector, для чего Go и был придуман.
Вот это вот все, что написано сверху может быть крайне удобно для написания комплексной бизнес-логики (добро пожаловать в C#, Java и даже TypeScript), но не является необходимостью для задач, которые идеально решает Го.
Хотя я очень скучаю по Union types и Pattern Matching 😢
– По-настоящему "умный программист" (как объявлено в заголовке статьи) ценит тупость Чем меньше процессорных мощностей мозгов уходит на разбор и понимание каждой строчки, каждого слова и символа, тем лучше, потому что ты высвобождаешь память и фокусировку на более сложные вещи. Потому что сложнее самого кода – логика, по которой он строится, еще сложнее – цепочки логики всей кодовой базы, еще сложнее – понимание логики набора кодовых баз, разделенных на разные приложения.
Я буду рад, если мой язык не забирает у меня слишком много сил на осознание, что в нем происходит и Go с этим справляется просто отлично.
Итоги Несомненно, идеальных языков не существует, но существуют языки, которые для определенных задач ну очень хороши, например, Go и веб, или Go и кросплатформенные утилиты, или JS и поедание говна
Всем мощной прокачки 🥱
Наткнулся на статью, где, на мой взгляд, бездарно срут на Go. И я бы прошел мимо, если бы не кол-во лайков и видеоразборов на YouTube...
Никому не позволю обижать моего малыша.
Претензия автора: "Слишком мало синтаксического сахара, не хочу писать руками, это придумали старперы, которые не хотят смотреть дальше С"
Еще, он как стандартный автор подобной статьи приводит намеренно исковерканные примеры, а в противовес предлагает язык D... ну, опустим эти детали, они присущи многим статьям подобного рода (но почему же D... какой странный и абсолютно безумный выбор...)
Мой ответ таков: – Кол-во строчек кода не должно быть меркой качества кодовой базы. Чаще всего, дополнительные строчки – это более детальное раскрытие мысли от 1 строчки, которая может компактнее, но намного менее понятным образом что-то объяснить (пример, if против тернарника).
Да, когда ты пишешь сам свой код, хочется воспользоваться красивым тернарником, возможно, даже двойным-тройным, но каждый раз, когда ты наткнешься на такую конструкцию, написанную кем-то другим твой пукан загорится.
Поэтому понятность кода, важнее его кол-ва и Go со своим лаконичным синтаксисом заставляет разработчиков писать такой код.
– Тебе не НУЖЕН синтаксический сахар, ООП, дженерики и подобное, чтобы делать приложение с быстрым IO и не заниматься менеджментом памяти Еще одна из претензий автора: "Его сделали люди, которые кроме С ничего не хотят изучать" – наоборот, его сделали люди, которые выучили столько языков, что поняли, что С и процедурщины достаточно, чтобы максимально качественно, просто и производительно решать вопросы массивного IO и не решать вопросы с памятью, засчет встроенного Garbage Collector, для чего Go и был придуман.
Вот это вот все, что написано сверху может быть крайне удобно для написания комплексной бизнес-логики (добро пожаловать в C#, Java и даже TypeScript), но не является необходимостью для задач, которые идеально решает Го.
Хотя я очень скучаю по Union types и Pattern Matching 😢
– По-настоящему "умный программист" (как объявлено в заголовке статьи) ценит тупость Чем меньше процессорных мощностей мозгов уходит на разбор и понимание каждой строчки, каждого слова и символа, тем лучше, потому что ты высвобождаешь память и фокусировку на более сложные вещи. Потому что сложнее самого кода – логика, по которой он строится, еще сложнее – цепочки логики всей кодовой базы, еще сложнее – понимание логики набора кодовых баз, разделенных на разные приложения.
Я буду рад, если мой язык не забирает у меня слишком много сил на осознание, что в нем происходит и Go с этим справляется просто отлично.
Итоги Несомненно, идеальных языков не существует, но существуют языки, которые для определенных задач ну очень хороши, например, Go и веб, или Go и кросплатформенные утилиты, или JS и поедание говна
Всем мощной прокачки 🥱
Развернуть
💄Девчонка, сделавшая то, что мы не смогли...
Вы знаете, редко у меня возникает профессиональная ревность: это вот когда человек добился чего-то, о чем я только мечтаю.
И для меня это: (1) создавать используемые Open Source, (2) чтобы они еще денежку приносили.
Увы, сколько у меня не было попыток, обычно я заканчиваю на стадии бесконечных итераций над этим Open Source (даже у этого есть ооочень крутые следствия, расскажу о них позже)
И тут я натыкаюсь на нее... Alyssa X (и нет, это ссылка не на onlyfans... хотя мне было бы очень приятно, если бы кто-нибудь купил бы у меня нативную рекламу на onlyfans)
Что в ней такого особенного?
– Она запилила кучу Open Source, которые получили огромные рейтинги на Product Hunt
– Каждый из проектов занимал у нее где-то несколько месяцев
– Большинство из них реально имеют ценность (например, я начал пользоваться вот этим) – Все проекты тем или иным образом связаны с визуальными редакторами в браузере (а это огого как непросто)
А ТЕПЕРЬ ПРОСТО MINDBLOWING
Почти все эти проекты она пишет на чисто JS... с jQuery... rаждый репозиторий – это 1 html, 1 css и набор js скриптов... пример Из преимуществ – (1) ее код суперпроцедурный и похож больше на С (за что, я лично, люблю JS), (2) несомненно, такой подход позволяет добиться максимальной скорости и отзывчивости без страха "отрендерить лишнее", поскольку она сама контролирует каждый цикл рендера.
Из недостатков – поддерживать такой проект достаточно сложно, потому что половина кода – это рендеринг в дом, то, что с нас снимают такие библиотеки как React и Vue
Короче, очень интересный персонаж, я подписался на все что можно, чтобы следить за ее успехами, надеюсь, она начнет монетизировать свои проекты (потому что сейчас все бесплатно), ну и всегда интересно, как люди из самых простых вещей собирают что-то по-настоящему грандиозное
Короче, завидую, но прям с теплом в сердце 🖤
И для меня это: (1) создавать используемые Open Source, (2) чтобы они еще денежку приносили.
Увы, сколько у меня не было попыток, обычно я заканчиваю на стадии бесконечных итераций над этим Open Source (даже у этого есть ооочень крутые следствия, расскажу о них позже)
И тут я натыкаюсь на нее... Alyssa X (и нет, это ссылка не на onlyfans... хотя мне было бы очень приятно, если бы кто-нибудь купил бы у меня нативную рекламу на onlyfans)
Что в ней такого особенного?
– Она запилила кучу Open Source, которые получили огромные рейтинги на Product Hunt
– Каждый из проектов занимал у нее где-то несколько месяцев
– Большинство из них реально имеют ценность (например, я начал пользоваться вот этим) – Все проекты тем или иным образом связаны с визуальными редакторами в браузере (а это огого как непросто)
А ТЕПЕРЬ ПРОСТО MINDBLOWING
Почти все эти проекты она пишет на чисто JS... с jQuery... rаждый репозиторий – это 1 html, 1 css и набор js скриптов... пример Из преимуществ – (1) ее код суперпроцедурный и похож больше на С (за что, я лично, люблю JS), (2) несомненно, такой подход позволяет добиться максимальной скорости и отзывчивости без страха "отрендерить лишнее", поскольку она сама контролирует каждый цикл рендера.
Из недостатков – поддерживать такой проект достаточно сложно, потому что половина кода – это рендеринг в дом, то, что с нас снимают такие библиотеки как React и Vue
Короче, очень интересный персонаж, я подписался на все что можно, чтобы следить за ее успехами, надеюсь, она начнет монетизировать свои проекты (потому что сейчас все бесплатно), ну и всегда интересно, как люди из самых простых вещей собирают что-то по-настоящему грандиозное
Короче, завидую, но прям с теплом в сердце 🖤
Развернуть
🤼 Кейс для YDB и почему я не стану пока его использовать
YDB - это SQL база с автошардированием и ACID консистненостью (но без реляций), разработанная Яндексом и выпущенная в open source около года назад
В комментариях к предыдущему посту рассуждал про то почему мне она нравится концептуально, но почему я пока не готов ее использовать, решил продублировать в виде поста
Представим кейс: нам нужно построить систему с огромным кол-вом инсерта + хранением исторических данных за год, а далее их денормализовывать, чтобы показывать пользователям (например, система телеметрии или парсер из кучи источников) при этом сервис наш не то чтобы очень много зарабатывает и может зарабатывать (короче, резать косты важно)
Что я сделал бы среднестатистически: развернул бы на нескольких тачках Kafka (а поскольку это часто больно, я бы попробовал RedPanda), писал бы туда события, читал в других процессах и переписывал в PostgreSQL (условно, это наша основная база бизнес-логики, если нужно было бы что-то типа OLAP, тогда ClickHouse)
Если же YDB окажется достойной технологией, то можно и события в нее писать и читать их из ее же топиков и денормализованные данные обратно складывать (причем с умеренной денормализацией, потому что YDB поддерживает как вторичные индексы, так и JOIN), соответственно, она может стать даже основной базой для бизнес-логики
Никакого вендор лока (даже если начать с Yandex.Cloud, дальше можно уйти на self-hosted и ничего не потерять), поддержка всего одной системы, уменьшение стоимости, масштабируемость и скорость
Но YDB я бы пока не стал использовать в production: 1. Найти новых достойных разрабов на ноде, которые знаю PostgreSQL / Kafka - дико тяжело, найти на YDB будет невозможно, придется учить с нуля
2. Проблемы с драйверами точно будут, а значит нужно будет выделять время на контрибьютинг
3. Мы точно столкнемся с проблемами и особенностями YDB (потому что во многом она уникальна) и из-за отсутствия mass adoption вряд ли сможем найти ответы на Stack overflow, а значит придется как и искать кого-то, кто может подсказать что делать, самим шерстить исходники (а значит, знать С) так и экспериментировать пока не получится
Я буду готов взять в полноценный продакшен только:
1. Если очень прижмёт по масштабируемости и без экспериментов будет некуда
2. Когда в вакансиях начнут писать "Знание YDB", а это годик другой, в зависимости от агрессивности маркетинга Яндекса
3. Кор команда проекта будет готова контрибьютить в драйвер YDB для Node.js
Как-то так, поэтому долгих лет здоровья и процветания YDB, надеюсь, что где-нибудь в 2024-ом я смогу уверено брать его с собой в прод
И вам здоровья, друзья 😍
В комментариях к предыдущему посту рассуждал про то почему мне она нравится концептуально, но почему я пока не готов ее использовать, решил продублировать в виде поста
Представим кейс: нам нужно построить систему с огромным кол-вом инсерта + хранением исторических данных за год, а далее их денормализовывать, чтобы показывать пользователям (например, система телеметрии или парсер из кучи источников) при этом сервис наш не то чтобы очень много зарабатывает и может зарабатывать (короче, резать косты важно)
Что я сделал бы среднестатистически: развернул бы на нескольких тачках Kafka (а поскольку это часто больно, я бы попробовал RedPanda), писал бы туда события, читал в других процессах и переписывал в PostgreSQL (условно, это наша основная база бизнес-логики, если нужно было бы что-то типа OLAP, тогда ClickHouse)
Если же YDB окажется достойной технологией, то можно и события в нее писать и читать их из ее же топиков и денормализованные данные обратно складывать (причем с умеренной денормализацией, потому что YDB поддерживает как вторичные индексы, так и JOIN), соответственно, она может стать даже основной базой для бизнес-логики
Никакого вендор лока (даже если начать с Yandex.Cloud, дальше можно уйти на self-hosted и ничего не потерять), поддержка всего одной системы, уменьшение стоимости, масштабируемость и скорость
Но YDB я бы пока не стал использовать в production: 1. Найти новых достойных разрабов на ноде, которые знаю PostgreSQL / Kafka - дико тяжело, найти на YDB будет невозможно, придется учить с нуля
2. Проблемы с драйверами точно будут, а значит нужно будет выделять время на контрибьютинг
3. Мы точно столкнемся с проблемами и особенностями YDB (потому что во многом она уникальна) и из-за отсутствия mass adoption вряд ли сможем найти ответы на Stack overflow, а значит придется как и искать кого-то, кто может подсказать что делать, самим шерстить исходники (а значит, знать С) так и экспериментировать пока не получится
Я буду готов взять в полноценный продакшен только:
1. Если очень прижмёт по масштабируемости и без экспериментов будет некуда
2. Когда в вакансиях начнут писать "Знание YDB", а это годик другой, в зависимости от агрессивности маркетинга Яндекса
3. Кор команда проекта будет готова контрибьютить в драйвер YDB для Node.js
Как-то так, поэтому долгих лет здоровья и процветания YDB, надеюсь, что где-нибудь в 2024-ом я смогу уверено брать его с собой в прод
И вам здоровья, друзья 😍
Развернуть
😳 А еще есть 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" – и будет вам счастье.
Всем мощной прокачки 💪
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" – а все остальное уже будет сильными оптимизациями поверх этого в зависимости от контекста.
Если у вас есть более точечные вопросы, пишите в комментарии к этому посту
Всем мощной прокачки 💪
- 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 и с ним подобных проблем не предвидится
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
Потому что в 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 и видим, что создатель не может поддерживать эту либу (а энтузиастов так и не нашлось) и сам называет ее устаревшей
На этом уже можно остановится и подвести итог – библиотека мертва
Напишу набор действий, которые делаю я:
– Почитайте код релизов – если библиотека должна развиваться, а релизы были давно или они про изменение доки / 1 строчки кода, то плохо
– Много ли контрибьютор и как часто они коммитят
– Читаем Issues (особенно закрытые) – сколько закрыто, как давно, как много открыто, есть ли среди них критичные для вас моменты. Я находил либы, в которых авторы просто подряд закрывали абсолютно все Issues без ответа и люди недоумевали, что происходит.
– Как много вопросов и ответов на StackOverflow, если много, то хорошо
– Как много статей в интернете по названию библиотеки и какой они даты – Лучше, чтобы библиотека не зависела от кучи других, потому что контрибьютить, придется делать изменения не только в самой либе, но и в завсимостях
– Лучше, чтобы библиотека была в рамках одного стэка – например, в Prisma у вас будет идти еще Rust библиотека трансляции запроса в SQL, а значит чтобы поправить в ней баг, придется править не только JS / TS код, но и Rust
– Есть ли тесты на код – если есть, то это лучше, чем документация
Пример на Objection.js Под постом выше спросили про то, что я думаю, про Objection.js, я пошел освежить память, потому что давно им не пользовался:
– Релиз есть свежий, но он один... до этого релизами не пользовались, поэтому идем в commits и видим что коммиты раз в полгода... для ORM – очень плохо, потому что БД и задачи к БД постоянно развиваются, значит и ORM должна
– Среди контрибьюторов есть создатель Knex – это хорошо
– Идем в Issues и видим, что создатель не может поддерживать эту либу (а энтузиастов так и не нашлось) и сам называет ее устаревшей
На этом уже можно остановится и подвести итог – библиотека мертва
Развернуть