Айтишник обыкновенный 🐰

Кстати, для меня немного не ожиданный результат. Я думал, что gRPC будет если не впереди, то как минимум неподалеку от REST. По сути gRPC, если не упарываться в нюансы, то это тот же REST только круче. Еще раз подчеркну - грубо говоря, очень грубо)))

Видимо все голосовали не по принципу «кто круче», а по принципу, что понятнее, роднее, ближе к сердечку. Поэтому и победил «кандидат от народа»)))

Таким образом, стабильность системы осталась под вопросом. Как мне кажется, для стабильности все-таки наиболее подходящий вариант - Kafka. И гарантированная доставка из коробки, и сетка лишний раз не грузится избыточными запросами, и в случае сбоя электричества, все сообщения сохранятся. Хотя стабильность, тут, конечно, больше зависит от реализации. Например, возвращаясь к Transaction outbox, за счет этого паттерна мы по сути и покрыли бы часть запросов(гарант доставки и сохранение транзакций).

Выбор был сделан! 🗳️

Победили демократы RESTful партия.
Республиканцы Kafka показала наибольшее сопротивление.

Make RESTful great again

Поделитесь в комментах, почему выбрали именно REST. Или иной вариант. Я, например, голосовал Кафку, люблю надежность очередей.

Выборы окончены, идет подсчет голосов.

🚨🚨 Срочное включение 🚨🚨

Мы находимся в штате New Moscow, в избирательном пункте Kommunarka Street. Здесь мы видим как RESTful партия вырывается вперед!1!!

Однако, до конца голосования еще сутки, все еще может поменяться и не раз. Следите за новостями. Завтра подведение итогов и оглашение результатов.

Делитесь в комментариях своими прогнозами.

#юморэзки

На самом деле, как я уже написал в комментах, Миша больше любит мегаудобно развалиться. Так сказать, расчилиться на всю катушку 🤩

#кабачок

Transactional outbox pattern

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

Условно, при такой огромной цепочке взаимодействий, может произойти все, что угодно. Обязательно моргнет сеть, будет недоступен один из смежных сервисов или сбойнет что-то по иным причинам. Как в такой аварийной или около того ситуации ничего не потерять?

Правильно — записывать все ходы, как говорится.

Outbox паттерн подразумевает под собой модель с тасками. Когда микросервис получает запрос или вычитывает сообщение из топика, создается запись в БД с полученными данными. Пока ничего нового. А еще необходимо записать в отдельную outbox таблицу задачу на отправку запроса/сообщения следующему по бизнес-процессу смежнику.

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

Ну и конечно, помимо огромного плюса в виде «не потерять данные» из паттерна вытекают и другие:

Во-первых, многопоточноть и распределенность входящих запросов/задач и тд.

Во-вторых, это повышенная надежность.

В-третьих, простота в масштабировании при соблюдении определенных условий(например, установка блокировки на взятые в работу таски).

В-четвертых, удобнее переобрабатывать ошибки. Обычно реализация паттерна выглядит таким образом, что ошибки записываются в аналогичную Outbox таблицу также в виде задач. Такие задачи в дальнейшем при необходимости можно повторно взять в работу, переместив в таблицу outbox.

В-пятых, это простота. Не думаю, что здесь стоит что-то объяснять. Просто лепи на каждый пук задачу и будет тебе счастье))

Кстати, делитесь в комментах каким паттерном пользуетесь на своем проекте для достижения консистентности данных и гарантирования доставки

Ставь:
🤩 — если тоже используешь transaction outbox

💅 — если используешь другие паттерны(пиши в комменты какие)

😬 — если не используешь паттерны, они для слабаков

#словодня и #быстростатья

Кстати, по поводу первой «заповеди», а если точнее о смене места. У коллеги по цеху вышла интересная публикация-интервью с HR, который занимается подбором СА, БА и архитекторов.

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

После прочтения предлагаю обсудить спорные и интересные моменты в комментариях. Ну и поддержите чтоль начинающий канал Сергея))

Интересно, а я один стараюсь разграничивать синхронность/асинхронность взаимодействия от процесса?

Синхронный - один объект отправляет запрос и обязательно получает что‑то в ответ от другого объекта. Как пример, взаимодействие браузера с сервером при первичной отрисовке страницы. При этом в классическом понимании синхрона отправитель именно ждёт ответ и обычно другие функции заблокированы.

Асинхронный - один объект шлет запрос другому, но ответ не получает. Как пример, работа очередей или топиков: один объект положил данные в топик, а второй объект забрал эти данные, но никакой отбивки первому объекту при этом не пришло.

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

Попробую объяснить:

Все прекрасно знают, что есть условный REST, который считается синхронным. Есть очереди, которые принято считать асинхронными. И сейчас я не хочу вдаваться в технические нюансы, за счет которых можно сделать и рест асинхронным, да и очереди условно синхронными. Хочу поговорить о том, что есть еще синхрон/асинхрон бизнес-процесса.

Что это означает?

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

#быстростатья

#юморэзки

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

Мои «заповеди», почему так получилось:

*️⃣Во-первых, я обожаю свою работу. Мне нравятся задачи, которые я выполняю, очень повезло с классными коллегами, крутой и интересный проект(предметка). Это все очень важно. Моя первая работа была продавцом-консультантом. Работа, которая мне не просто не нравилась, я постоянно пытался сбежать, уйти раньше, меньше смен отработать и тд. Поэтому это хоть и очевидно, но не все готовы к переменам, а их совершать нужно. Особенно, если работаешь там, где тебя ничего не радует. Кстати, не за долго до увольнения дошло вообще до смешного, я получал зп в районе 12к, так как работал слишком мало и постоянно отмазывался учебой))

*️⃣Во-вторых, работа, конечно, важна. Я всегда стараюсь выполнять ее качественно. Иногда банально я перерисовываю диаграммы только из-за того, чтобы они были ровными и аккуратными, внутренний перфекционист требует идеала. НО я никогда не ставлю работу на первое место. На первом месте - моя семья🧑‍🧑‍🧒. Именно поэтому, когда я заканчиваю работать, я не продолжаю в ней вариться(если, конечно, на работе не совсем беда). Мне кажется, этот фактор хоть и заставляет меня работать меньше или менее интенсивно, чем я мог бы, но зато я не убиваюсь из-за каких-то мелочей на работе.

*️⃣В-третьих, эмоциональная отстраненность. Кажется, что это плохо, но я не знаю, я не психолог и все такое. Однако, эта фича в моем характере также позволяет мне не выгорать из-за того, что я не переживаю лишний раз по каким-то проблемам(не только связанными с работой). Но опять же это и плохо, иногда нужно порадоваться, а не всегда получается.

Подчеркну, это мое мнение, наверное, местами очевидное как — «делай хорошо, плохо не делай».

Не является частной рекомендацией
😂😂😂

Призываю вас поделиться в комментах вашими «заповедями», которые помогают не выгорать. Или можете наоборот порефлексировать о том, что вам мешает. Мне, например, мешает то, что мне сложно переключаться между задачами, делами домашними и тд. Стараюсь это фиксить.

#быстростатья

Ура! Всем спасибо, все реакции, что были раньше, снова доступны.
💗

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

Может, накидаете?
https://t.me/boost/default_itshnik

А то как теперь ставить грустные смайлики? 😬

На улице полный джингбелз. От снегопада улыбка до ушей 😁

Осталось только дома все украсить и наслаждаться этим новогодним вайбом.

А еще у меня осталось 3 дня до моего двухнедельного отпуска, пока пишу это, улыбка становится еще больше😂😂😂

А потом вспоминаю про работу. Вспоминаю, что там аврал и вообще непонятно как все успеть сделать за 3 дня до отпуска. На этом этапе улыбка куда-то испаряется😂

#юморэзки

Удобно ппц

#кабачок

Мне кажется, все тут знакомы с REST и понимают, что это определенные правила и стандарты для синхронного взаимодействия систем через HTTP(при должных манипуляциях еще и асинхронного). Соответсвенно, знаете про подходы в организации связей «ресурсов».

Для получения списка клиентов, обычно выполняем GET-запрос на адрес /customers

Для получения инфо по конкретному клиенту, выполняем GET-запрос на адрес
/customers/{customer_id}

Давайте теперь выясним, как вы организуете запрос на получение определенного заказа у определенного клиента?

Ставь 🤩, если ты за
/customers/{customer_id}/orders/{order_id}

Ставь 💅, если ты за
/orders/{order_id} и customer_id в теле/параметре запроса

Да будет битва!

#словодня

#юморэзки

#юморэзки

В продолжение поста. Планирую пересборку в новогодние праздники. Для этого купил дистропанель(штука на передней стенке компа на фото) с помпой d5(сейчас стоит ddc). С новой дистрой поменяется расположение нескольких элементов, за счет этого освободится место под еще один радиатор. Ни то, чтобы не хватало 2 тех, что есть сейчас, просто радиатор давно покупал, но так и не использовал, а новую дистру всегда планировал поставить на переднюю стенку.

Кстати, про помпы. D5 производительнее и тише, единственный ее минус, что она крупнее и дороже ddc. Поэтому, если вдруг кто-то, не может определиться, выбирайте всегда в пользу d5. У меня это уже вторая ddc, первую пришлось поменять, так как работала слишком громко, как будто трещала. Наверное, попалась с браком.

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

Что думаете? У кого-нибудь еще есть кастомная вода?