А откуда у вас уверенность в этом? Судите, что это ошибка? А судьи то кто?:)
Пока складывается впечатление, что вы действительно не читали статью. Задач которые появятся в приложение будет около 150. Сейчас там всего 2 - это мойки машин. Для остальных и закладывалось это:)
Прошу вас, прочитайте вы уже статью, потратьте свое время, там все ответы на ваши не очень корректные, но язвительные комментарии. Надеюсь у вас все хорошо, а то прям токсом отдает:) При чем токсом такого явного сноба, который "я в IT с 80-х, а вы тут лезете"
Что вы пытаетесь доказать? Что нужно писать монолиты, вместо того, чтобы закладывать будущее? Повторюсь, мы уже активно переносим остальные задачи под ту архитектуру, что уже сделали:) Кстати, напишем об этом в отдельной статье, приглашу вас почитать, вряд ли вы до того момента сделаете что-то стоящее, чтобы об этом рассказать. Вот поэтому придется тащить нам, молодым :)
Удачи вам, ждем ваших успехов, присылайте почитать, как что-то будет
И повторю конкретный пример: монолит бы вы написали вдвое быстрее. 11000 строк 3 человека 3 месяца это слишком долго (это ведь только бэк? Иначе совсем плохо)
вот это в вас и выдает человека который не думает наперед. В решении между монолитом и микросервисной архитектурой выбрать первое, потому что написать монолит быстрее.
Все прям как у Галича: "А то, что придется потом платить Так ведь это ж, пойми, — потом!"
Стоит все таки было написать монолитик? Если бы вы внимательно читали, то поняли - мы закладывали архитектуру сразу, под дальнейшее развитие приложения - задач выполняемых через него, как и пользователей станет больше. И мы готовы к такому масштабированию, даже код почти дописывать не надо, все ляжет идеально.
Это и отличает грамотного архитектора который смотрит в будущее от разработчика, который хочет таким быть, но пока только пишет статьи с указанием сухих "функциональные и нефункциональные" требований и не думает наперед.
Не, челочек, что кичится про +20 лет разницы, выставляя это как аргумент, который задает банальные вопросы, которые раскрыты в первых предложениях - тут не проблемы с soft skills, тут отсутствие оных. Удачи вам, ждем ваших успехов:)
Кстати, по поводу пункта "А потом побежали писать сюда в самовлюбленном формате, не заботясь об удобстве чтения, погружения читателя в контекст проблемы."
В статье, в самом начале, хотя понимаю, что сложно и "многа букав", но всё же, в самом начале, пункт 1. Как все было устроено до
Вы определитесь, то вам много букв, то погрузите еще сильнее
С другой стороны, ладно с этими 300+ экранами и строками кода
Понимаю, + 20 лет, тяжело читать большие технические и продуктовые статьи, но хотел бы увидеть примеры с вашей стороны, как вы меняли бизнесс-процессы и растили метрики с помощью приложения и новых систем.
И если делали, то как вы умещаете такой путь в более короткую статью А раз нет статьи и рассказа, то и хвалится нечем?
+ 20 лет это скорее минус, чем плюс :) Дорогу молодым:)
В статье нигде не написано, что у наших микросервисов общая бд :) По умолчанию микросервисная архитектура подразумевает подход database per mocroservice, чего мы и придерживаемся.
Взаимодействие через Кафку ведется с теми системами, которые сейчас поддерживаются в компании. Но есть старые системы, в том числе и монолиты, которые поддерживают только REST и написаны на другом языке, а дописывать их никто не планирует. Что лучше - нанять нового разработчика, который разберется в монолите, докрутит к нему Кафку и спустя полгода задержек эта схема заработает, либо же отправить в монолит REST запрос отдельной горутиной?
Насчет HTML, не совсем понял ваш аргумент. Насчет HTML на стороне мобильного приложения дал ответ выше. Если вы говорите о реализации фронтенда на чистом HTML, то эта практика стала неактуальной уже году в 2010 в связи с тем, что плюсов в сравнении с тем же React у нее нет, а вот минусов полно
Ну а если серьезно,не совсем понятно, как планируется использовать html при том выборе стека мобильного приложения, который мы сделали.
Но даже если бы мультиплатформа без костылей поддерживала html, то концепция остается той же. На бэкенде мы храним схему задачи, только генерируем по ней не JSON, а HTML? Звучит сомнительно по многим причинам. Как минимум встает вопрос, а кто будет верстать такое чудо, бэкенд разработчик или фронтенд разработчик, или же нанимать фулл-стека?
Насчет рисков, здесь вы правы, использование BPMN схем, как и любое другое архитектурное решение (хотя даже больше чем любое другое!) сопряжено с определенными рисками и имеет определенные трейд-оффы. Цель архитектора эти риски грамотно просчитать, принять часть из них и отдать решение в разработку.
Ну и спойлер: с этими рисками, я считаю, мы справились :) Потому что мы имеем на руках дизайны остальных флоу задач, и наша архитектура их поддерживает ровно настолько, насколько мы изначально это просчитали: на остальные задачи будут созданы не более, чем новые микросервисы-стратегии
- Вы кто? Достаточно открыть глазки и прочитать первые предложения статьи. Я - Даня :) - Все тоже самое - что такое FMS в первых же предложениях статьи. Все еще достаточно открыть глазки - Про птичий язык комментировать не буду:) - Нет никаких предложений, нет никаких советов. Описан только лишь наш путь создания большой системы и приложения и распил монолита в очень сжатые сроки и очень маленьким составом команды. Может быть он кому-то покажется интересным, ни на что не претендуем, только лишь рассказываем.
Через 5 минут становится уже всё равно? но коммент на несколько абзацев написали, значит не все равно.
К слову, у вас есть примеры из работы на питончике о создании подобных систем и приложений? Поделитесь, пожалуйста. Посмотрел ваши статьи, и у меня тот же вопрос: "Вы кто?"
Завидовать плохо, почти завидовать тоже плохо.
Приходи к нам, у нас есть ставки миддла:)
на HTML бы точно завелось?
Теперь понятно, почему вам статья не зашла, увидели как разваливают ваши любимые монолиты в заголовке и не читали дальше. Понимаем, принимаем.
Попробуйте тенденции в разработке не из 80-х - обещаю, вам понравится
Прочитал ваше коммент в другой теме
"Я наконец то понял что такое микросервисы
Я мало работал с микросервисами и точно не видел когда их нужно сотни и тысячи."
Тут комментировать - только портить
оставим это тут:)
А откуда у вас уверенность в этом? Судите, что это ошибка? А судьи то кто?:)
Пока складывается впечатление, что вы действительно не читали статью. Задач которые появятся в приложение будет около 150. Сейчас там всего 2 - это мойки машин. Для остальных и закладывалось это:)
Прошу вас, прочитайте вы уже статью, потратьте свое время, там все ответы на ваши не очень корректные, но язвительные комментарии. Надеюсь у вас все хорошо, а то прям токсом отдает:) При чем токсом такого явного сноба, который "я в IT с 80-х, а вы тут лезете"
Что вы пытаетесь доказать? Что нужно писать монолиты, вместо того, чтобы закладывать будущее? Повторюсь, мы уже активно переносим остальные задачи под ту архитектуру, что уже сделали:) Кстати, напишем об этом в отдельной статье, приглашу вас почитать, вряд ли вы до того момента сделаете что-то стоящее, чтобы об этом рассказать. Вот поэтому придется тащить нам, молодым :)
Удачи вам, ждем ваших успехов, присылайте почитать, как что-то будет
И повторю конкретный пример: монолит бы вы написали вдвое быстрее. 11000 строк 3 человека 3 месяца это слишком долго (это ведь только бэк? Иначе совсем плохо)
вот это в вас и выдает человека который не думает наперед. В решении между монолитом и микросервисной архитектурой выбрать первое, потому что написать монолит быстрее.
Все прям как у Галича:
"А то, что придется потом платить
Так ведь это ж, пойми, — потом!"
Стоит все таки было написать монолитик?
Если бы вы внимательно читали, то поняли - мы закладывали архитектуру сразу, под дальнейшее развитие приложения - задач выполняемых через него, как и пользователей станет больше. И мы готовы к такому масштабированию, даже код почти дописывать не надо, все ляжет идеально.
Это и отличает грамотного архитектора который смотрит в будущее от разработчика, который хочет таким быть, но пока только пишет статьи с указанием сухих "функциональные и нефункциональные" требований и не думает наперед.
Не, челочек, что кичится про +20 лет разницы, выставляя это как аргумент, который задает банальные вопросы, которые раскрыты в первых предложениях - тут не проблемы с soft skills, тут отсутствие оных. Удачи вам, ждем ваших успехов:)
Но вы прочитали, и даже комменты оставили. Классическая иллюстрация "И хочется, и - колется".
Уже доказали) Ждем кстати ваших примеров, догоняйте:)
Нет, просто монолиты были популярны в вашей молодости, сейчас тенденции другие
Простите, что не следуем канонам:)
Кстати, по поводу пункта "А потом побежали писать сюда в самовлюбленном формате, не заботясь об удобстве чтения, погружения читателя в контекст проблемы."
В статье, в самом начале, хотя понимаю, что сложно и "многа букав", но всё же, в самом начале, пункт 1. Как все было устроено до
Вы определитесь, то вам много букв, то погрузите еще сильнее
С другой стороны, ладно с этими 300+ экранами и строками кода
Понимаю, + 20 лет, тяжело читать большие технические и продуктовые статьи, но хотел бы увидеть примеры с вашей стороны, как вы меняли бизнесс-процессы и растили метрики с помощью приложения и новых систем.
И если делали, то как вы умещаете такой путь в более короткую статью
А раз нет статьи и рассказа, то и хвалится нечем?
+ 20 лет это скорее минус, чем плюс :)
Дорогу молодым:)
покажите, пожалуйста, примеры вашего приложения на 300+ экранов
и 11 микросервисов, а пока вопрос всё тот же: "кто вы?"
Привет!
В статье нигде не написано, что у наших микросервисов общая бд :) По умолчанию микросервисная архитектура подразумевает подход database per mocroservice, чего мы и придерживаемся.
Взаимодействие через Кафку ведется с теми системами, которые сейчас поддерживаются в компании. Но есть старые системы, в том числе и монолиты, которые поддерживают только REST и написаны на другом языке, а дописывать их никто не планирует. Что лучше - нанять нового разработчика, который разберется в монолите, докрутит к нему Кафку и спустя полгода задержек эта схема заработает, либо же отправить в монолит REST запрос отдельной горутиной?
Насчет HTML, не совсем понял ваш аргумент. Насчет HTML на стороне мобильного приложения дал ответ выше. Если вы говорите о реализации фронтенда на чистом HTML, то эта практика стала неактуальной уже году в 2010 в связи с тем, что плюсов в сравнении с тем же React у нее нет, а вот минусов полно
а вы кто?
Ну а если серьезно,не совсем понятно, как планируется использовать html при том выборе стека мобильного приложения, который мы сделали.
Но даже если бы мультиплатформа без костылей поддерживала html, то концепция остается той же. На бэкенде мы храним схему задачи, только генерируем по ней не JSON, а HTML? Звучит сомнительно по многим причинам. Как минимум встает вопрос, а кто будет верстать такое чудо, бэкенд разработчик или фронтенд разработчик, или же нанимать фулл-стека?
Насчет рисков, здесь вы правы, использование BPMN схем, как и любое другое архитектурное решение (хотя даже больше чем любое другое!) сопряжено с определенными рисками и имеет определенные трейд-оффы. Цель архитектора эти риски грамотно просчитать, принять часть из них и отдать решение в разработку.
Ну и спойлер: с этими рисками, я считаю, мы справились :) Потому что мы имеем на руках дизайны остальных флоу задач, и наша архитектура их поддерживает ровно настолько, насколько мы изначально это просчитали: на остальные задачи будут созданы не более, чем новые микросервисы-стратегии
Привет! кидать HTML на мобилку? Сильное решение
Привет!
- Вы кто? Достаточно открыть глазки и прочитать первые предложения статьи. Я - Даня :)
- Все тоже самое - что такое FMS в первых же предложениях статьи. Все еще достаточно открыть глазки
- Про птичий язык комментировать не буду:)
- Нет никаких предложений, нет никаких советов. Описан только лишь наш путь создания большой системы и приложения и распил монолита в очень сжатые сроки и очень маленьким составом команды. Может быть он кому-то покажется интересным, ни на что не претендуем, только лишь рассказываем.
Через 5 минут становится уже всё равно? но коммент на несколько абзацев написали, значит не все равно.
К слову, у вас есть примеры из работы на питончике о создании подобных систем и приложений? Поделитесь, пожалуйста. Посмотрел ваши статьи, и у меня тот же вопрос: "Вы кто?"