Вооот. Наконец-то появилось на ютубе видео, которое объясняет реальные подходы к написанию кода. Надеюсь и дальше будут похожие видео, спасибо! Про транзакшнл идея хорошая, туда же можно и про аннотацию лок добавить, жду с нетерпением!😊
Катя, сделай пожалуйста видео про объяснение АНОТАЦИЙ СПРИНГА, КЛАССЫ КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В СПРИНГЕ И ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ СЕТЬ. плииииз. залайкайте комент чтобы Катюньдель увидела и сделала видео
15:31 - верное замечание по-поводу интерфейсов - однозначно лойс. У нас на проекте сейчас (!) интерфейсы используются как правило в библиотеках, поскольку слепое следование SOLID ведет к раздутости кода. Тем ребятам, кто впоследствии будет смотреть код, где слепо следуют этому принципу будет очень неприятно разбираться во всех этих кишках и простынях кода
интерфейсы это про ООП, а не про SOLID. солиду нужно следовать всегда в промышленном коде. как раз в простынях кода разбираться и не придется, потому что каждая ответственность будет сосредоточена в отдельном классе/пакете/модуле
годный контент, надеюсь такие видосы будут каждый день выходить. темный фон конечно депрессивно смотрится, но эт уже вкусовщина, мне бы и снятый на кухне такой видос зашел бы
классное объяснение по такой полезной и в то же время мало-известной (как мне показалось) теме 💯💯 был личный опыт - на собесе спросили как можно убедиться в целостности данных при распределённых транзакциях (ни про 2х фазный коммит, ни сагу, ни аутбокс я не знал), пришлось самому что то выдумывать 😅😅
1 из 10 соответствующий должности - это очень хороший показатель. И это релевантно для любой сферы. Было время подбирал сотрудников в строительную компанию. Я бы мог только мечтать, если бы 1 из 10 кандидатов подходил.
канал интересный, подписался, правда вопрос это по сути самописанный RabbitMQ в своей базе данных, async messaging pub-sub with retry, я правильно понял?
Из пула точно берутся транзакции, не коннекшн?) 34:47 например, executorService + countdownLatch) 37:21 Да что за "запихиваем"? Инжектим, внедряем, применяем мб? Спасибо за видео❤
Все отлично по содержанию, спасибо! Классно будет, если на канале будет такой контент. Его не хватает. P.S. По мне слишком часто отдаляется/приближается камера. Прям тяжело смотреть
32:59 Решение конечно красивое, но зачем было помечать их service если используете new ? И потом, почему service а не component? Service для бизнес логики то что в нашем домене, а тут какие то retryableTask о которых бизнес не знает даже
1) Сервисы помеченные как бины спринга не нужно создавать через new. Если хотите сделать стратегию через спринг, посмотрите доклад Евгения Борисова про паттерны на спринге... 2) Помоему у вас select for update и сам update в разных транзакциях, думаете локи будут работать?:) А так в целом нормально. 🎉
Ну ещё бы надо добавить, что это at least once доставка, так как отправитель может упасть после сделанной отправки , не успев проставить соответствующий статус.
Провожу собеседования много лет, никогда не спрашивал(и у меня никто не спрашивал) такого ^__^ и у меня есть ряд вопросов по коду * зачем отдельная транзакция на создание таски, ведь она уже создана в сервисе выше? я понимаю что она пропагейтится, но фигачить на каждый метод не круто * в мапстракт маппере создается еще один джексон маппер, зачем когда он уже есть в контексте спринга который и настраивается еще из пропертей? а тут 2 маппера с разными настройками * последнее и самое главное, начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая :) на счет микросервисности, этот паттерн применим везде, но текущая реализация не подходит для микросервисов(джоба только в 1 поток может работать) код на бусти не видел, может там skip locked и тред пулы есть)
Да тут вообще дизайн полный ужас. Это в какой компании интересно такой подход используют? И полагаться на время в разных выборках тоже так себе практика время скорее всего не будет суперточно совпадать на разных инстансах особенно если они на разных физических машинах. Ну и да сваливать все в одну таблицу что бы потом из type городить огромный бородатый switch который будет решать в какую очередь отправить.. вообще вишенка.
Здравствуйте, но возник такой вопрос: зачем такие данные хранить в sql бд, почему нельзя засунуть это в редис. Не знаю как в java, но знакомы ли вы с Celery?
На джвае нет что ли готовых шедуле библиотек ? - свой велосипед для типовой задачи как-то кринжово. На счет интерфейса для заказов . я бы небыл так уверен , сегодня в БД пишете заказы . а завтра решили сливать их в какую либо CRM-ку , да и в целом бизнес логика оформления заказа часто меняется , лучше пусть будет интерфейс он каши не просит реализуется за пять сек, и это точно не сложнее чем все потом править.
Что делать при подходе один сервис - одна база? Для отдельного сервиса Sceduler есть отдельная база, в которую нужно положить сообщение - это опять отправка данных в другой сервис во время транзакции... Или Scheduler отдельный сервис внутри микросервиса?
@@ggnet-lm7pgНет, rest это не соглашение формата данных. Строго говоря, данные могут быть в любом формате: json, xml, html, byte file, plain text и т.д. Rest в первую очередь соглашение о формате урла и отображении состояния запрашиваемой/передаваемой инофрмации путем внедения уникального идентификатора. Согласно модели OSI, rest не протокол, а SOAP вполне, т.к. имеет строгие ограничения формата передаваемых данных, при чем оба они работают с протоколом http.
@@channel-yg2xc Я и не говорил, что REST - это протокол. Я сказал что это data transfer architectural pattern/view, который накладывает определённые ограничения на передачу данных. В названии SOAP - явно указывается, что это протокол, в отличии от REST. REST - не является имплементацией, и не зависит от application/transport протокола.
@@ggnet-lm7pg - REST это не протокол, а соглашение - протокол это и есть соглашение - я не говорил что Rest - это протокол ))) Но это такое, ты сказал, цитирую: "...Но REST сам по себе лишь один из видов представления передачи данных", я ответил, что это не так. Все ограничения формата данных, передаваемых по REST - это ограничения протокола http. В самом же REST нет ограничений http request body ни логически-концептуальных, ни физических, - его физически ограничивает протокол http и ни что более. Соответственно "вид/view"(проще говоря, данные запроса и ответа) может быть любым, который удовлетворяет протоколу http.
Отличный видос! Действительно обязательная тема для миддл+/синьор бэкендеров. Nit: Кажется в видео было упущено сохранение обновленных значений retryTime для тех retryableTasks которые мы все же не смогли обработать. Не сильно шарю в джаве, но кажется если обновленные значения закинуть в цикле через сеттер, то в бд они не отразятся. Наверное надо было просто добавить метод в репо, который бы обновил те записи, у которых статус не изменился на success.
Говорят, если снимаешь примитив, то много просмотров. Интересно, сколько просмотров набрал бы ролик про то, как узнать подходит ли тебе программирование 🤔
Какую именно информацию? При оформлении заказа уже есть адрес доставки и отправки. Расстояние между двумя точками, время примерной доставки и стоимость вполне можно рассчитать в синхроне. Данные о курьере, если такой предусмотрен, ты не получишь, пока система его не подберёт. Это может быть и секунда, и минута, и десять минут. Поэтому на фронт обычно отдаётся статус заказа 'PENDING', отрисовывая экран с оформленным заказом и надпись "подбираем курьера", при подборе курьера отправляется пуш на клиента, который отрисовывает уже другой экран с информацией о курьере. Именно так работает Bolt такси, например.
@@channel-yg2xc а что, у тебя фронт будет получать полную информацию о курьере через сервис заказов? Или все таки достаточно зарегистрировать синхронно доставку, получить id?
@@channel-yg2xc а у тебя что, сервис заказов возвращает полную информацию о доставке на фронт? Может все таки зарегистрировать доставку, получить id? Я конечно рад за bold такси, что у них распределённый монолит работает, но все таки я бы предпочел микросервисы
Я все равно не уловил фишку. Почему не послать просто в очередь? Зачем это все? И это как по мне не решает проблему, а переносить в другое место. Планировщик так же будет блокировать таблицу на добавление новых записей. Собственно, поэтому никто не знает ответ на собесах - слишком это кривое, неэлегантное решение.
Какие новые записи создаёт планировщик и что блокирует? В виде не сказано про idempotent Id в каждом запросе от планировщика к другому сервису. Этот id помогает слать один запрос много раз. А после успешной отправки запроса или ответа 409/406 (и т.д.) открыть транзакцию и обновить bool поле "отправлено"
Я не понял, а чем собственно rest запрос на другой микросервис, который может быть "долгим" отличается от той же самой записи в базу данных, которая тоже может быть долгой. Это два внешних сервиса, никто не гарантирует что в какой-то из них запрос будет идти дольше/быстрее
И даже если мы запишем запрос с json в базу чтобы потом когда то там куда то там его отправить - мы все ещё не гарантируем что он дойдет до нужного сервиса. Даже не гарантируем когда он дойдет до сервиса. Просто поменяли шило на мыло.
Вопрос правильный, ответ такой: базу выбираете вы сами и рассчитываете под свои потребности и можете подкрутить, если что. Другой же микросервис вы не контролируете, ну по крайней мере будем так считать. Ну и вот.
Тем что в первом случае у тебя вся транзакция отвалится по таймауту. Второй вариант позволяет тебе сохранить транзакционность доставки не имея проблем с таймаутом и тем что транзакция занята ожиданием ответа от другого сервиса. Конечно transactional outbox не под все задачи подходит. Но на видео разобрали очень популярный юзкейс. Если тебе нужная транзакционность между сервисами, посмотри в сторону 2PC и связанные паттерны. Вижу что в комментах люди пытаются натянуть сову на глобус.
@@paxpax1707 извините конечно но каким боком сохранение в базу и бесконечные ретраи обеспечивают транзакционность? Запрос спокойно себе может никогда не осуществится. Это полный бред
Подскажите, очень надо. Java не учил ещё, знаю только python. Часто нужно получить apk. Декомпилировать. И собственно реверс и поиск как значений, так и методы формирования значений для запросов приложения, которые отснифаны ранее. Либо снятие защиты от снифа или от запуска на эмуляторе андроида , снова упаковка в apk и запуск. Реверс инженеринг. Как? Где? Чем? Каким образом? В общем, сервисы, ресурсы, где можно учить, изучать, использовать, для решения подобных задач. Java выучу, клянусь и ещё 4-5 языков, чуть позже, сейчас другое важное учу и решаю. Подскажи, очень нужно дельный совет. Заранее спасибо. Целую в щёчки, жму сосочки.
Устал слушать воду на 4й минуте. Пошел в гугл и прочитал за 3 минуты, что представляет из себя данный паттерн. Зачем эти 40 минут? Краткость - сестра таланта! В общем, только вводную часть можно было сократить до 30 секунд. Дальше не знаю. Обсасывать простейший паттерн 40 минут, это сильно.
Как минимум во вступлении отсутствует информация что мы что-то сохраняем в базу данных, это смешно просто слушать, что сообщение может потеряться в Кафке, а из тмб оно не может потом потеряться в Кафке, дилетантство, прочитали пару статей в интернете и давай клепать ролики для хомяков
Проблема в необходимости писать в больше чем один сервис, с этого надо начинать, у вас каша полная, вы не понимаете ничего в этом и не умеете выражать свои мысли последовательно
![Eminem - Fuel (Shady Edition) feat. Westside Boogie & GRIP [Official Audio]](http://i.ytimg.com/vi/k1OquBida9s/mqdefault.jpg)
Вооот. Наконец-то появилось на ютубе видео, которое объясняет реальные подходы к написанию кода. Надеюсь и дальше будут похожие видео, спасибо!
Про транзакшнл идея хорошая, туда же можно и про аннотацию лок добавить, жду с нетерпением!😊
Умничка, очень хорошо объясняешь) приятно слушать + пример кода, что ещё нужно для счастья
Катя, сделай пожалуйста видео про объяснение АНОТАЦИЙ СПРИНГА, КЛАССЫ КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В СПРИНГЕ И ВЗАИМОДЕЙСТВИЕ ЧЕРЕЗ СЕТЬ. плииииз. залайкайте комент чтобы Катюньдель увидела и сделала видео
Катя, спасибо за видос! Тема действительно актуальная!
Мегаполезный видос, столько сопутствующих тем затронуто. Ну прям бест практикс! Огромное спасибо!
Спасибо за отличное видео! Было бы интересно увидеть реализацию реактивного подхода(если сталкивалась) 🙃
15:31 - верное замечание по-поводу интерфейсов - однозначно лойс. У нас на проекте сейчас (!) интерфейсы используются как правило в библиотеках, поскольку слепое следование SOLID ведет к раздутости кода. Тем ребятам, кто впоследствии будет смотреть код, где слепо следуют этому принципу будет очень неприятно разбираться во всех этих кишках и простынях кода
Разве что чтоб потом в тестах мокать было удобнее
Тут кто как понял солид. Инжектируемый инстанс репозитория сам по себе интерфейс. Тут как посмотреть
интерфейсы это про ООП, а не про SOLID. солиду нужно следовать всегда в промышленном коде. как раз в простынях кода разбираться и не придется, потому что каждая ответственность будет сосредоточена в отдельном классе/пакете/модуле
полезное видео! спасибо!
Многопоточку и transactional было бы интересно послушать 🙏
Очень круто рассказываешь детали! Спасибо за труд, продолжай в том же духе!
Отличный контент, спасибо! Пилите больше
Мне понравилось видео, отдельное спасибо за пример кода!
годный контент, надеюсь такие видосы будут каждый день выходить. темный фон конечно депрессивно смотрится, но эт уже вкусовщина, мне бы и снятый на кухне такой видос зашел бы
классное объяснение по такой полезной и в то же время мало-известной (как мне показалось) теме 💯💯
был личный опыт - на собесе спросили как можно убедиться в целостности данных при распределённых транзакциях (ни про 2х фазный коммит, ни сагу, ни аутбокс я не знал), пришлось самому что то выдумывать 😅😅
Наконец-то!!! Эту информацию нужно нести в массы. Спрашиваю на собесе уже 10 лет, 1 из 10 может хоть что-то ответить, а ведь это азы!
1 из 10 соответствующий должности - это очень хороший показатель. И это релевантно для любой сферы. Было время подбирал сотрудников в строительную компанию. Я бы мог только мечтать, если бы 1 из 10 кандидатов подходил.
Качественный контент, наконец-то!
Как насчет аналогичного примера с гарантированной доставкой/получением в/из Кафка?
Процессоры можно было бы тоже сделать бинами)
В одном потоке несколько тасков лучше не обрабатывать либо брать из базы одну таску под локом
Тоже не вижу смысла сразу создавать интерфейсы на все подряд. Понадобится вторая реализация, тогда можно выделить интерфейс.
крутяк, спасибо за видео!
канал интересный, подписался, правда вопрос это по сути самописанный RabbitMQ в своей базе данных, async messaging pub-sub with retry, я правильно понял?
про transactional было бы интересно
Классное видео, хоть я php разраб но было интересно как у вас в java мире это все пишется, спасибо за видео!
В пхп мире ровно так же используется этот паттерн
Прошу еще про другие паттерны, начал изучать java
Лучшее видео за последнюю тысячу лет!!! О нем будут слагать легенды и эпосы!!
Об этом комментарии точно сложат легенды. Так глубоко никто никого не нахваливал в нашей галактике последние миллиард лет😂
В каком месте?
@@mugen31337 справа
@@mugen31337 справа
Ё спасибо было круто😊
Из пула точно берутся транзакции, не коннекшн?)
34:47 например, executorService + countdownLatch)
37:21 Да что за "запихиваем"? Инжектим, внедряем, применяем мб?
Спасибо за видео❤
Все отлично по содержанию, спасибо! Классно будет, если на канале будет такой контент. Его не хватает.
P.S. По мне слишком часто отдаляется/приближается камера. Прям тяжело смотреть
32:59
Решение конечно красивое, но зачем было помечать их service если используете new ?
И потом, почему service а не component? Service для бизнес логики то что в нашем домене, а тут какие то retryableTask о которых бизнес не знает даже
1) Сервисы помеченные как бины спринга не нужно создавать через new. Если хотите сделать стратегию через спринг, посмотрите доклад Евгения Борисова про паттерны на спринге...
2) Помоему у вас select for update и сам update в разных транзакциях, думаете локи будут работать?:)
А так в целом нормально. 🎉
У меня глаз задёргался, когда я увидел new
годно, пили еще
Очень полезно. Отдельное спасибо за англословечки с нормальным русским произношением, слух не режет.
Такие все классные программисты , а где ваш видео-Хостинг взамен RUclips интересно спросить
380 подписчиков?! Я ожидал как минимум 380 тысяч!
Годно по состоянию на начало 200х. А сейчас уж лучше event driven вокруг брокера
Ну ещё бы надо добавить, что это at least once доставка, так как отправитель может упасть после сделанной отправки , не успев проставить соответствующий статус.
вокруг брокера(сага - хореография) уже не модно. Последние новости моды: temporal(сага оркестрируемая + FSM) :)
Провожу собеседования много лет, никогда не спрашивал(и у меня никто не спрашивал) такого ^__^
и у меня есть ряд вопросов по коду
* зачем отдельная транзакция на создание таски, ведь она уже создана в сервисе выше? я понимаю что она пропагейтится, но фигачить на каждый метод не круто
* в мапстракт маппере создается еще один джексон маппер, зачем когда он уже есть в контексте спринга который и настраивается еще из пропертей? а тут 2 маппера с разными настройками
* последнее и самое главное, начинали с "держать транзакцию пока выполнится запрос плохо", но пришли к "теперь мы держим транзакцию n*requestTime" что еще дольше и еще хуже чем первая :)
на счет микросервисности, этот паттерн применим везде, но текущая реализация не подходит для микросервисов(джоба только в 1 поток может работать)
код на бусти не видел, может там skip locked и тред пулы есть)
Да тут вообще дизайн полный ужас. Это в какой компании интересно такой подход используют? И полагаться на время в разных выборках тоже так себе практика время скорее всего не будет суперточно совпадать на разных инстансах особенно если они на разных физических машинах. Ну и да сваливать все в одну таблицу что бы потом из type городить огромный бородатый switch который будет решать в какую очередь отправить.. вообще вишенка.
Skip locked нужен, видос хорошая попытка объяснить, но косячнула чуток
22:01 Зачем @Transactional над createRetyableTask?
Привет? В вб получилось пройти отбор или не дотянула? Спасибо. Просьо интересно.
Здравствуйте, но возник такой вопрос: зачем такие данные хранить в sql бд, почему нельзя засунуть это в редис. Не знаю как в java, но знакомы ли вы с Celery?
Привет, давай про @Transactional, что за плагин который подсказывает автокомплитит код?
топ
Паттерн стратегия, изи!)
prevet krasavisa
На джвае нет что ли готовых шедуле библиотек ? - свой велосипед для типовой задачи как-то кринжово.
На счет интерфейса для заказов . я бы небыл так уверен , сегодня в БД пишете заказы . а завтра решили сливать их в какую либо CRM-ку , да и в целом бизнес логика оформления заказа часто меняется , лучше пусть будет интерфейс он каши не просит реализуется за пять сек, и это точно не сложнее чем все потом править.
Спасибо за видео, на гитлабе не видно проект
Что делать при подходе один сервис - одна база? Для отдельного сервиса Sceduler есть отдельная база, в которую нужно положить сообщение - это опять отправка данных в другой сервис во время транзакции... Или Scheduler отдельный сервис внутри микросервиса?
Если тебе нужна транзакционность между сервисами, посмотри в сторону Saga или в целом 2PC.
REST это не протокол, а соглашение.
стандарт*
протокол - это и есть соглашение, в каком виде приходят данные. Но REST сам по себе лишь один из видов представления передачи данных.
@@ggnet-lm7pgНет, rest это не соглашение формата данных. Строго говоря, данные могут быть в любом формате: json, xml, html, byte file, plain text и т.д. Rest в первую очередь соглашение о формате урла и отображении состояния запрашиваемой/передаваемой инофрмации путем внедения уникального идентификатора. Согласно модели OSI, rest не протокол, а SOAP вполне, т.к. имеет строгие ограничения формата передаваемых данных, при чем оба они работают с протоколом http.
@@channel-yg2xc Я и не говорил, что REST - это протокол. Я сказал что это data transfer architectural pattern/view, который накладывает определённые ограничения на передачу данных. В названии SOAP - явно указывается, что это протокол, в отличии от REST. REST - не является имплементацией, и не зависит от application/transport протокола.
@@ggnet-lm7pg
- REST это не протокол, а соглашение
- протокол это и есть соглашение
- я не говорил что Rest - это протокол
)))
Но это такое, ты сказал, цитирую: "...Но REST сам по себе лишь один из видов представления передачи данных", я ответил, что это не так. Все ограничения формата данных, передаваемых по REST - это ограничения протокола http. В самом же REST нет ограничений http request body ни логически-концептуальных, ни физических, - его физически ограничивает протокол http и ни что более. Соответственно "вид/view"(проще говоря, данные запроса и ответа) может быть любым, который удовлетворяет протоколу http.
На бусти нюдсы будут?
ruclips.net/video/HI-XvL2FkTQ/видео.htmlsi=YM1n8aHc0c-GOgNp&t=220
Привет.
Почему транзакция на запись блокирует чтение?
Отличный видос! Действительно обязательная тема для миддл+/синьор бэкендеров.
Nit: Кажется в видео было упущено сохранение обновленных значений retryTime для тех retryableTasks которые мы все же не смогли обработать. Не сильно шарю в джаве, но кажется если обновленные значения закинуть в цикле через сеттер, то в бд они не отразятся. Наверное надо было просто добавить метод в репо, который бы обновил те записи, у которых статус не изменился на success.
Хата волкаа? ❤🎉
Говорят, если снимаешь примитив, то много просмотров. Интересно, сколько просмотров набрал бы ролик про то, как узнать подходит ли тебе программирование 🤔
А если ux дизайнеры решили, что нужно сразу получать информацию о доставке? А у вас delivery service отвечает минуту. Что будете делать?
Какую именно информацию? При оформлении заказа уже есть адрес доставки и отправки. Расстояние между двумя точками, время примерной доставки и стоимость вполне можно рассчитать в синхроне. Данные о курьере, если такой предусмотрен, ты не получишь, пока система его не подберёт. Это может быть и секунда, и минута, и десять минут. Поэтому на фронт обычно отдаётся статус заказа 'PENDING', отрисовывая экран с оформленным заказом и надпись "подбираем курьера", при подборе курьера отправляется пуш на клиента, который отрисовывает уже другой экран с информацией о курьере. Именно так работает Bolt такси, например.
@@channel-yg2xc а что, у тебя фронт будет получать полную информацию о курьере через сервис заказов? Или все таки достаточно зарегистрировать синхронно доставку, получить id?
@@channel-yg2xc а у тебя что, сервис заказов возвращает полную информацию о доставке на фронт? Может все таки зарегистрировать доставку, получить id? Я конечно рад за bold такси, что у них распределённый монолит работает, но все таки я бы предпочел микросервисы
Я все равно не уловил фишку. Почему не послать просто в очередь? Зачем это все? И это как по мне не решает проблему, а переносить в другое место. Планировщик так же будет блокировать таблицу на добавление новых записей. Собственно, поэтому никто не знает ответ на собесах - слишком это кривое, неэлегантное решение.
Какие новые записи создаёт планировщик и что блокирует?
В виде не сказано про idempotent Id в каждом запросе от планировщика к другому сервису. Этот id помогает слать один запрос много раз. А после успешной отправки запроса или ответа 409/406 (и т.д.) открыть транзакцию и обновить bool поле "отправлено"
А что если мы успешно заретраили, но упали на апдейте статуса тасок?
@@pagorbunov сообщение отправится ещё раз. Тип доставки at least once
Откуда ты все это знаешь
Здесь после каждого слова склейка видео? 😸 Теперь я знаю способ делать из женщин разрабов 😹😹
Просто она через каждое слово матерится, заводская привычка, пришлось вырезать
Я не понял, а чем собственно rest запрос на другой микросервис, который может быть "долгим" отличается от той же самой записи в базу данных, которая тоже может быть долгой. Это два внешних сервиса, никто не гарантирует что в какой-то из них запрос будет идти дольше/быстрее
И даже если мы запишем запрос с json в базу чтобы потом когда то там куда то там его отправить - мы все ещё не гарантируем что он дойдет до нужного сервиса. Даже не гарантируем когда он дойдет до сервиса. Просто поменяли шило на мыло.
Также потенциально таблица с заданиями отправить запросы может невероятно разрастись. Добавляется ещё одна потенциальная точка отказа
Вопрос правильный, ответ такой: базу выбираете вы сами и рассчитываете под свои потребности и можете подкрутить, если что. Другой же микросервис вы не контролируете, ну по крайней мере будем так считать. Ну и вот.
Тем что в первом случае у тебя вся транзакция отвалится по таймауту. Второй вариант позволяет тебе сохранить транзакционность доставки не имея проблем с таймаутом и тем что транзакция занята ожиданием ответа от другого сервиса. Конечно transactional outbox не под все задачи подходит. Но на видео разобрали очень популярный юзкейс. Если тебе нужная транзакционность между сервисами, посмотри в сторону 2PC и связанные паттерны. Вижу что в комментах люди пытаются натянуть сову на глобус.
@@paxpax1707 извините конечно но каким боком сохранение в базу и бесконечные ретраи обеспечивают транзакционность? Запрос спокойно себе может никогда не осуществится. Это полный бред
Подскажите, очень надо.
Java не учил ещё, знаю только python.
Часто нужно получить apk.
Декомпилировать.
И собственно реверс и поиск как значений, так и методы формирования значений для запросов приложения, которые отснифаны ранее.
Либо снятие защиты от снифа или от запуска на эмуляторе андроида , снова упаковка в apk и запуск.
Реверс инженеринг.
Как?
Где?
Чем?
Каким образом?
В общем, сервисы, ресурсы, где можно учить, изучать, использовать, для решения подобных задач.
Java выучу, клянусь и ещё 4-5 языков, чуть позже, сейчас другое важное учу и решаю.
Подскажи, очень нужно дельный совет.
Заранее спасибо.
Целую в щёчки, жму сосочки.
чудовищно растянутая логика в части базы данных
Герои не носят плащи
Устал слушать воду на 4й минуте. Пошел в гугл и прочитал за 3 минуты, что представляет из себя данный паттерн. Зачем эти 40 минут? Краткость - сестра таланта! В общем, только вводную часть можно было сократить до 30 секунд. Дальше не знаю. Обсасывать простейший паттерн 40 минут, это сильно.
Там ещё код такой и в целом "архитектура".
Спасибо, сэкономил время
Описание проблемы неверное, она не понимает о чем говорит.
Так опиши конкретно, что не правильно
Как минимум во вступлении отсутствует информация что мы что-то сохраняем в базу данных, это смешно просто слушать, что сообщение может потеряться в Кафке, а из тмб оно не может потом потеряться в Кафке, дилетантство, прочитали пару статей в интернете и давай клепать ролики для хомяков
Проблема в необходимости писать в больше чем один сервис, с этого надо начинать, у вас каша полная, вы не понимаете ничего в этом и не умеете выражать свои мысли последовательно
Катя, иди борщ варить.
А я реально очень вкусный кубанский борщ готовить умею, видимо нужен кукинг стрим
@@JAVAGYMRAT 💋
Хо-хо-хо, мать, ты появилась как раз вовремя, тебя то я и искал
Кстати, что у тебя за ноут, MagicBook16?
Дыа