Можно же взять cursor и сделать то же самое проще и быстрее, ничего не надо будет копипастить туда-сюда. Он прямо локально создаст проект целиком, со всеми файлами, и сам всё напишет в них.
Плюс поверх прототипа там супер-легко делать багфиксы и новые фичи, достаточно попросить сделать что надо.
Ну конечно, сейчас уже много инструментов, которые это делают очень сносно. Недавно в cursor так сделал - нарисовал от руки макет на листочке, сфоткал - получил рабочий фронтенд.
И наверное ещё одна сторона кафки, которая может быть полезной - сообщения хранятся в брокере даже после прочтения.
Например, если попортили данные в БД, например стерли случайно таблицу, то можно восстановить БД сервиса из бэкапа, а потом накатить заново все сообщения с того времени по текущее время, даже те, которые уже были тогда прочитаны.
Если бы это был REST, то пришлось бы просить клиентов повторно отсылать запросы.
И ещё несколько архитектурных приёмов становятся доступны из-за того, что сообщения хранятся на брокере.
если гонец успешно отправлен то рано или поздно он доедет и будет радушно принят
Это если ваш гонец доедет до брокера, и его по дороге не скушают страшные волки (потери пакетов) или не окажется что мост разрушен и не проехать (сетевая недоступность брокера). Тогда гонец либо вернется обратно (с ошибкой сети) или и вовсе пропадёт без вести.
Передать сообщение в брокер - это считай сделать такой же REST-запрос, со всеми его возможными проблемами.
Вот если сообщение уже передали в брокер, то да, дальше всё гораздо лучше, получатель его прочитает рано или поздно, если не продолбается.
Спасибо что подсветили, в статье действительно переход резкий.
Применение микросервисной архитектуры порождает распределённые системы.
На самом деле монолит на бэке + БД, доступная по сети - это уже штука с признаками распределённой системы. Просто на таком масштабе удобней их игнорировать.
Когда у вас хотя бы 2 микросервиса - пользователи и заказы, то тут и встают вопросы - а будут ли данные консистентны между ними (C - consistency)? Как оба сервиса отреагируют на недоступность другого и как себя поведут, когда доступность снова восстановится (P - partition tolerance)? Насколько доступной будет вся система в целом, а не каждый микросервис в отдельности (A - availability)?
CAP-теорема начинает нам быть интересной в микросервисной архитектуре в самом практическом смысле.
Enduro/X похоже делает 2 phase commit, а оркестраторы в списке делают саги.
Ещё это похоже, если я правильно читаю, это комбайн, который делает ещё 10 разных вещей кроме оркестрации транзакций, например может использоваться как брокер сообщений.
Вам стоит отделить мухи от котлет. Есть документация кода, есть документация проекта.
Документация кода - это про то, в каких случаях метод кидает какое исключение, какое значение когда возвращает, какие требования к входным параметрам. Плюс на уровне компонента - его цель, как пользоваться, многопоточный ли он и так далее.
Документация проекта - это глоссарий, описание бизнес-процессов, API, архитектуры.
Разница между ними в том, что первое читают только разработчики, второе - очень много кто, и они не хотят лезть в исходники, чтобы это увидеть.
У этих двух вещей различий больше чем общего, общее только название "документация".
от того, насколько хорошо все настроено в архитектуре,
Если грамотно распределить нагрузку
Здесь встает вопрос о смене архитектуры, когда чувствуете, что монолитная уже не работает на вас
Главное — не забыть все грамотно связать
Как правило, когда нужно обновить систему, выбора переходить или нет не остается
В правильно настроенном, амбициозном проекте, все само приведет к переходу на микросервисы
Главное — золотая середина: не слишком рано, когда для этого не будет команды с высокой квалификацией и денег, и не слишком поздно, когда от высокой нагрузки ничего уже не работает.
В статье какой-то набор из чувств, ощущений и рекомендаций делать "грамотно" и "правильно", а "неграмотно" и "неправильно" видимо не делать. И ещё соблюдать золотую середину.
Какая польза от таких пространных рассуждений, мне вообще непонятно. Вот прочитал я это, и что дальше? Как мне ваши чувства и рекомендации делать "правильно" конвертировать в оценки и действия? Они субъективны, и в статье просто налита вода к сожалению.
Спасибо ИИ за статью про ИИ!
Можно же взять cursor и сделать то же самое проще и быстрее, ничего не надо будет копипастить туда-сюда. Он прямо локально создаст проект целиком, со всеми файлами, и сам всё напишет в них.
Плюс поверх прототипа там супер-легко делать багфиксы и новые фичи, достаточно попросить сделать что надо.
А то это не вайб кодинг, а мучение какое-то.
Ну конечно, сейчас уже много инструментов, которые это делают очень сносно. Недавно в cursor так сделал - нарисовал от руки макет на листочке, сфоткал - получил рабочий фронтенд.
Комментарий правильный, но бесполезный, не конструктивный: любители статей продолжат лепить публикации сотнями на хабр.
Простите, не удержался :)
Не найдется ли более конкретных рекомендаций мне в помощь?
Верно, но верно и то, что тимлиду работу найти сложнее/дольше, чем синьору.
В общем и нанять тимлида, и найти работу тимлидом сложнее, и противоречия тут нет.
Да.
Kafka: the definitive guide от компании-создателя кафки. Хорошо описывает все основы.
Книжка довольно толстая, но практически всё из этого мне уже понадобилось.
Если в вашей метафоре "гонец отправлен" это "брокер принял сообщение и ответил ок", то да, верно. Но это ещё не обязательно случится.
И может ещё быть например, что брокер не ответил ок, но сообщение принял.
И наверное ещё одна сторона кафки, которая может быть полезной - сообщения хранятся в брокере даже после прочтения.
Например, если попортили данные в БД, например стерли случайно таблицу, то можно восстановить БД сервиса из бэкапа, а потом накатить заново все сообщения с того времени по текущее время, даже те, которые уже были тогда прочитаны.
Если бы это был REST, то пришлось бы просить клиентов повторно отсылать запросы.
И ещё несколько архитектурных приёмов становятся доступны из-за того, что сообщения хранятся на брокере.
Это если ваш гонец доедет до брокера, и его по дороге не скушают страшные волки (потери пакетов) или не окажется что мост разрушен и не проехать (сетевая недоступность брокера). Тогда гонец либо вернется обратно (с ошибкой сети) или и вовсе пропадёт без вести.
Передать сообщение в брокер - это считай сделать такой же REST-запрос, со всеми его возможными проблемами.
Вот если сообщение уже передали в брокер, то да, дальше всё гораздо лучше, получатель его прочитает рано или поздно, если не продолбается.
Спасибо что подсветили, в статье действительно переход резкий.
Применение микросервисной архитектуры порождает распределённые системы.
На самом деле монолит на бэке + БД, доступная по сети - это уже штука с признаками распределённой системы. Просто на таком масштабе удобней их игнорировать.
Когда у вас хотя бы 2 микросервиса - пользователи и заказы, то тут и встают вопросы - а будут ли данные консистентны между ними (C - consistency)? Как оба сервиса отреагируют на недоступность другого и как себя поведут, когда доступность снова восстановится (P - partition tolerance)? Насколько доступной будет вся система в целом, а не каждый микросервис в отдельности (A - availability)?
CAP-теорема начинает нам быть интересной в микросервисной архитектуре в самом практическом смысле.
Enduro/X похоже делает 2 phase commit, а оркестраторы в списке делают саги.
Ещё это похоже, если я правильно читаю, это комбайн, который делает ещё 10 разных вещей кроме оркестрации транзакций, например может использоваться как брокер сообщений.
Вообще хорошей документацией могут быть тесты:
Они помогают увидеть, как пользоваться компонентом можно, как нельзя. Посмотрел тест и пишешь свой код так же
Они проверяют, что код работает как описано в тестах. Такая автопроверка документации получается
Они заставляют разработчиков писать более понятный код и думать над тем, какие контракты у компонентов и методов
Они ещё и качество кода повышают, ловят баги
Вам стоит отделить мухи от котлет. Есть документация кода, есть документация проекта.
Документация кода - это про то, в каких случаях метод кидает какое исключение, какое значение когда возвращает, какие требования к входным параметрам. Плюс на уровне компонента - его цель, как пользоваться, многопоточный ли он и так далее.
Документация проекта - это глоссарий, описание бизнес-процессов, API, архитектуры.
Разница между ними в том, что первое читают только разработчики, второе - очень много кто, и они не хотят лезть в исходники, чтобы это увидеть.
У этих двух вещей различий больше чем общего, общее только название "документация".
Спасибо за красочные эпитеты в мой адрес и такое внимание к моей персоне.
Не думал, что статью можно унизить, приношу ей свои извинения, если её это обидело.
Надеюсь за всеми переживаниями от моих нападок у вас выйдет уловить и суть сказанного. Удачи:)
Ну не знаю, не знаю что там субъективного.
Не, ну я так не играю. "Молодой человек, это не для вас написано!"
Вы тогда в статью так и напишите, а то на хабре писать статью для людей без технического бэкграунда и не упомянуть об этом - это интересный подход :)
Много в разработке субъективного или мало, а лить воду пользы всё равно нет.
"Зависит от потребностей" и субъективно - это не одно и то же если что.
В статье какой-то набор из чувств, ощущений и рекомендаций делать "грамотно" и "правильно", а "неграмотно" и "неправильно" видимо не делать. И ещё соблюдать золотую середину.
Какая польза от таких пространных рассуждений, мне вообще непонятно. Вот прочитал я это, и что дальше? Как мне ваши чувства и рекомендации делать "правильно" конвертировать в оценки и действия? Они субъективны, и в статье просто налита вода к сожалению.
Рад, что оживил дискуссию по теме микросервисов, но не очень радует качество этой дискуссии.
Не понял, так как понять?
Всё-таки некрасиво обвинять людей в плагиате ради подгона траффика на свой материал.
Тема и сентимент безусловно те же, но обвинять людей в плагиате, причем не оригинала, а именно вашего перевода - это вообще топ.
Не надо так.