Самый Базовой Паттерн микросервисной архитектуры

Ребята, я выложила видос с объяснением и реализацией паттерна, о котором реально должен знать каждый бэкенд разработчик

Пару аргументов в мою пользу:

1) Олды вспомнят, что я проходила летом серию собеседований на senior позиции, на 7 из 10 собесов меня спрашивали про этот паттерн. А на одном тех интервью целый час был посвящен тупо его реализации в прямом эфире

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

3) Он красивый просто пипец в реализации, не особо сложный и при этом дает безумно много пользы в разрабатываемой системе

Видео тут | Ссылка на код здесь

Походу пришло время завести твиттер

(Ps я до сих пор не понимаю как им пользоваться, для меня он как фейсбук - чисто для дедов, без негатива)

Последний шанс восстановить Youtube

Написал тред на английском, указал все детали, попросил разобраться, тэгнул ребят из Youtube. Нужна твоя помощь. Даже если пустой аккаунт: лайк, ретвит, коммент -> переслать друзьям. Если нет твиттера, репост в тг канал подойдет, твиттер есть у твоих подписчиков

https://x.com/M0rtyMerr/status/1829503429246402831

Ты можешь быть со мной не согласны по каким-то моментам. Но, как удалили мой канал, могут удалить и твой. Поддержи, пожалуйста, давай дойдём до гугла

DTO без боли: как не захламить проект дублирующимся кодом

В web сервисах на Javа есть много кода, не несущего в себе никакой бизнес-логики - а именно data transfer objects (DTO). Эти объекты используются для передачи на фронтенд/во внешние сервисы только тех данных, которые необходимы клиенту, а не всех данных из БД.

Создание DTO-классов приводит к росту дублирующегося кода, так как часто они сильно похожи на Entity-классы (классы, представляющие данные из БД), и через какое-то время кодовая база начинает распухать от их количества.

Проблема усугубляется, если DTO нужно передавать клиентам вашего API. Клиенты будут вынуждены дублировать их у себя в коде, и с каждым обновлением API им придется синхронизировать свои версии DTO, что создает сильную связанность кода и захламляет его как на стороне сервера, так и на стороне клиентов.

Как этого избежать и организовать работу с DTO эффективнее?

Наиболее удобными и практичными подходами я считаю именно эти:

1. Выделение в отдельный модуль всего, что касается API

Этот подход заключается в создании отдельного модуля, содержащего все объекты, связанные с API — DTO, модели, контракты, интерфейсы и другие сущности, используемые для взаимодействия между сервисами.

Теперь изменения в API-объектах происходят в одном месте, что облегчает обновление и тестирование. Подключая этот модуль к различным сервисам/ клиентам API, можно избежать дублирования кода и создания идентичных DTO-классов в каждом из них.

2. Описание контрактов с помощью схем и генерация DTO при сборке проекта

Этот подход заключается в автоматической генерации DTO и контрактов на основе схем данных, таких как OpenAPI или JSON Schema. Вместо того чтобы создавать и поддерживать DTO вручную, контракты описываются в формате схем, которые затем используются для автоматической генерации объектов в коде при сборке проекта.

Важно отметить, что этот подход можно использовать не только для REST-интеграций, но и для других типов взаимодействия, таких как обмен сообщениями через Kafka, RabbitMQ и т.д.

А как вы работаете с DTO в своих проектах?

ПС. история с генерацией объектов на основе схем мне нравится больше, однако кайфа от написания yaml файлов не получаю. Видимо больше практики нужно.

#production_case

Так разработчики борются с выгоранием

Это был ахуй!!

А что такое докер?
При подготовке сценария видео по обзору инструментов CI/CD, я поняла, что не могу дать точное и понятное определение тому, что такое Docker.
Начала искать статьи по этой теме и словила бомбеж очка: большинство найденных мною статей не только не объясняют концепцию этого инструмента, но и еще больше запутывают читателя, пытающегося разобраться в теме.

Вот выдержка из одной из таких статей:

Докер — это открытая платформа для разработки, доставки и эксплуатации приложений. Docker разработан для более быстрого выкладывания ваших приложений. С помощью docker вы можете отделить ваше приложение от вашей инфраструктуры и обращаться с инфраструктурой как управляемым приложением.

Даже при том, что я часто использую Docker в работе, у меня возникает куча вопросов при чтении этого определения. Почему Docker называют именно платформой, а не просто программой? Что означает "отделить приложение от инфраструктуры"? Куда именно происходит "быстрое выкладывание"?

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

Причина 1: Автору не хватило времени/желания разобраться в сути и создать качественный, уникальный материал. Был совершен копипаст определения с официального сайта, без попытки объяснить своими словами устройство инструмента и вникнуть в детали.

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

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

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

Докер это вот такая вот заумная херабора, а если хочешь действительно разобраться в том, что это за инструмент, пройти собес и получить жирный оффер, то заполняй заявку на мой курс - только сейчас скидка 90% !!!!

#бомбит

Настолько ли плох Full Scan?

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

Однако в действительности полный скан таблицы не так плох, как это может показаться на первый взгляд.

Какие операции самые долгие при выполнении запроса на чтение данных?

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

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

Так почему же полный скан таблицы не всегда плох?
В случае полного сканирования таблицы СУБД применяет оптимизации, позволяющие сократить количество обращений к диску:

1. Выгрузка данных с диска большими блоками

Хотя данные в таблицах могут быть фрагментированы, в большинстве случаев записи одной таблицы хранятся на диске последовательно. Это позволяет СУБД считывать данные большими блоками за один раз, минимизируя количество обращений к диску.

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

2. Кэширование данных

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

3. Поддержка многопоточного выполнения

Современные СУБД поддерживают многопоточную обработку, позволяя делить большую таблицу на несколько сегментов, которые обрабатываются одновременно разными потоками

Индекс неэффективен при выборке большого количества данных

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

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

Поставь 🔥 если пост был полезен и хочешь еще постов на технические темы

Я заболела ((

В связи с этим еще больше убедилась в том, что мне необходима няня/мама кошка/мучача.

Нужна взрослая женщина в возрасте моей мамы, с теплыми руками и добрым сердцем.

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

Пока непонятно, где такую искать - на портале эскортниц или на профи ру

Пишите, если можете посоветовать хороших женщин в маленькие ручки

АНОНС СТРИМА - ОТВЕЧАЮ НА ВОПРОСЫ ОБ IT И НЕ ТОЛЬКО

В ЧЕТВЕРГ В 19 30

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

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

Поделюсь инсайтами, лайфхаками и немного поною

Неравнодушный дорогой подписчек, задать вопрос ты можешь здесь

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

Приходи на стрим, чтобы я не была (опять) тем челом, на тусовку которого никто не пришел

Подписаться на начало стрима ты можешь здесь

СТРИМ БУДЕТ В ТГ

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

Поэтому стрим будет здесь, начнем в 19 30

Комменты к стриму можно писать под этим постом

Отправить донат здесь

Спасибо всем, кто пришел вчера на стрим!

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

Родилось много локальных мемов, было очень вайбово, еще раз спасибо, ребята ❤️

Посмотреть запись можно на бусти