Если в кластере пара десятков нод, то в aio-pika есть пулы, чтобы цепляться к разным хостам (там тоже не так просто, но тем-не менее). В RabbitMQ, политика по умолчанию, распределяет очереди по тем нодам на которых они были объявлены, таким образом если в рамках одного соединения, задекларировать 1000 очередей, то нагрузка на кластер будет неравномерная.
Вредный совет, если не конкретизировать, тебе нужно подобрать инструменты так, чтобы примерно всем они подходили, и никого ни к чему принуждать не пришлось бы. А так да, молоток хуже отвертки выкручивает шурупы, но зато "закручивает" – сильно быстрее (перформанс оптимизации с помощью молотка)
"Увы", потому, что в вашем настоятельном примере, по моей догадке, скорее описан ваш идеальный мир (если это был не сарказм, и я его не понял, тогда просто читайте "идеальный мир" с кавычками).
У нас в команде есть строгое правило, перед тем как что-то утверждать, не плохо бы это проверить. Мы в целом с тем заходом и "шли к успеху", который описан в посте. Я считаю что инженеру по другому просто нельзя. Если хочешь убедиться в том, что кому-то подойдет та библиотека/технология/фреймворк (нужное подчеркнуть), просто дай её "пощупать" тем кому "с ней потом жить". Будь готов к критике, проведи опыты, напиши докуметацию, которой будет достаточно, чтобы понять почему все задумано и работает именно так.
А самое прикольное что это работает в две стороны, если я что-то предлагать возьмусь, совершенно справедливо получить вопрос: "Дима, а ты как понял что станет лучше?", классно-же. "Пропихнуть" что-то спорное разумеется можно, но придется спорить :-D.
Мы же не дизайнеры, которых просят "сделать красный чуть краснее", мы инженеры, можем все померять, пожем все проверить, провести эксперимент, тесты написать в конце концов, в общем почти нормальный научный процесс.
Можно удариться в карго-культ, и всего этого не делать, а просто прочитать на условном хабре (желательно прямо в этом коменте), что "Все надо переписать на Go/Erlang/Elixir/Python/NodeJS/Typescript/Rust/Zsh"(нужное подчеркнуть), и все станет сразу как в AANGе – тоже подход, но лично по мне, не надежный просто, может станет а может нет.
Так к чему это я, работать в команде это всегда работа с людьми. И тем проще работать, чем люди больше вовлечены, пытаются улучшать те инструменты которыми пользуются, привносят что-то, что поможет всем.
В статье это описано, в первых прототипах админок, был index.html, который надо было врукопашную сортировать, не большая беда, но вот сели и переделали на ESM.
Случилось бы это если бы все были просто "винтики", которых "заставили писать REST-API на С++"? Сомневаюсь. Да и в том что кого-то прям заставляют этим заниматься, тоже.
Можно ли было переделать что-то во flask-admin, тоже наверное можно, но уровень контроля все-же не тот-же самый, по крайней мере мне приятно думать что я все еще имею мою иллюзию контроля.
Ребята писали что сделали по своему, ты писал на flask-admin )))
UPD: И не просто сделали, а провели исследование что не стало хуже, порверили экспериментально что пользователям админок стало удобнее, код лучше, проще разрабатывать, и критерий "выкатываем формочку за день" в медиане сходится, и самое главное теперь админки начали писать все, а ты тогда один отдувался за всех.
а потом как начинаются пляски с частичной вадидацией формы на 40 полей, ты где будешь хранить то, что запомнил пользователь? В query-string? Или на каждую валидацию POST отправлять? В последем случае пользователь расстроится, если случайно нажмет back в браузере.
Если бы ты не написал бóльшую часть наших админок на фласке, я бы наверное поспорил. Но всякие штуки с реактивностью, с частичной валидацией форм, да даже select2 делается не то чтобы очень гибко и просто.
Вебсокет – это не просто транспорт в этом случае, это еще и контекст который привязан к конкретному процессу конкретного инстанса работы пользователя с бекендом. А инстансов той-же админки, минимум 2-3. То есть пока жив конкретный инстанс веб-сокета, сервер может держать в памяти то, что прислал пользователь, без необходимости шарить состояние между всеми инстансами.
Попробуй как-нибудь на досуге, сделать на фласк-админе форму, куда загружаешь CSVшку и нужно перед сохраниением данных из неё дать пользователю, проверить что все поля нормально помапились.
С flask-admin да и любым CRUD тебе придется все-таки сначала сохранить эту csvшку в базу, потом отрендерить пользователю табличку с мапингом, плюс пагинация плюс фильтры, и плюс много всего еще.
С сокетом просто просишь сервер вот этот блоб провалилировать, потом отдельным rpc вызовом, просишь показать первые 10 строк, к примеру, серверу можно хоть в /tmp/ хранить все время до комита в базу этот файл, и просто ходить по нему вперед-назад.
Когда файл 100мегабайт начинает весить, flask-admin начинает по 60 секунд отвечать на это, так как ему нужно на каждый чих перелопачивать 100 мегабайт в базу и обратно.
Так-же стоит отметить, что у меня был точно такой-же риск, как у руководителя, когда мы с@Alvinerвнедряля вышеописанное решение, никого не потеряли, к счастью.
И как мне кажется, именно потому, что мы никого не превращали в "фулстек"ов, мы четко ограничили проблемы, и наше видение их решения. И диапазон применимости, нашего решения мы умышленно не распространяли дальше вот этих вот "админок".
Ну а если вдруг найдутся коллеги, кому "зашло" то почему-бы не идти в сторону "фулстек"ов.
Если не вырывать из контекста, то целиком цитата выглядит так:
Так как всё же заставить бэкендера писать фронтенд? Краткий ответ звучит так — никак.
На рынке труда очень много вакансий, если человек занимается тем, что ему не нравится, зачем себя мучать?
В вашей истории про коллегу, я так и не понял, ему нравилось то, чем он занимается, в процессе получения галочки "фуллстек", или нет ? Если и там нет, и он поменял работу потому что не смог договориться с руководителем – это прекрасно, не нужно никого мучать.
Мне кажется, что постоянные секьюрити проблемы, во всем что касалось PHP, 10-15 лет назад тому виной.
И, с моей точки зрения, непонятно почему PHP лучше или хуже чем тот-же Flask-Admin на Python. Принципиально тоже самое.
Мы преследовали цель свести верстку и все что касается фронтенда к минимуму, поэтому просто готовые компоненты на vue https://element.eleme.io/#/en-US/component/form которые просто нужно описать, и все, форма готова.
Вот в вашем утверждении "не так много" я сомневаюсь. Мне, лично, кажется что "очень много", если у вас есть какие-то ссылки на исследования, по этой теме, любопытно было-бы почитать.
Наша цель, была в том, чтобы разработчику, даже если он не знает JS, но знает Python, нужно было посмотреть JS Quick Start, и просто начать на нем решать задачи, а не заниматься вопросами сборки, транспиляцией, и всем тем что вы описали выше. Да и отлаживать такой код куда проще, просто поставил breakpoint в Developer Tools, и остановился там где надо. В случае с любой транспиляцией – это не так просто.
Как и написано в статье, наша цель была в том, чтобы разработчику потратить минимум усилий для начала, и в нашем случае – получилось, просто делаешь git clone, и запускаешь браузер, все.
Если в кластере пара десятков нод, то в aio-pika есть пулы, чтобы цепляться к разным хостам (там тоже не так просто, но тем-не менее). В RabbitMQ, политика по умолчанию, распределяет очереди по тем нодам на которых они были объявлены, таким образом если в рамках одного соединения, задекларировать 1000 очередей, то нагрузка на кластер будет неравномерная.
Я и не говорил что его нет :-)
Вредный совет, если не конкретизировать, тебе нужно подобрать инструменты так, чтобы примерно всем они подходили, и никого ни к чему принуждать не пришлось бы. А так да, молоток хуже отвертки выкручивает шурупы, но зато "закручивает" – сильно быстрее (перформанс оптимизации с помощью молотка)
Лень тогда-уж.
"Увы", потому, что в вашем настоятельном примере, по моей догадке, скорее описан ваш идеальный мир (если это был не сарказм, и я его не понял, тогда просто читайте "идеальный мир" с кавычками).
У нас в команде есть строгое правило, перед тем как что-то утверждать, не плохо бы это проверить. Мы в целом с тем заходом и "шли к успеху", который описан в посте. Я считаю что инженеру по другому просто нельзя. Если хочешь убедиться в том, что кому-то подойдет та библиотека/технология/фреймворк (нужное подчеркнуть), просто дай её "пощупать" тем кому "с ней потом жить". Будь готов к критике, проведи опыты, напиши докуметацию, которой будет достаточно, чтобы понять почему все задумано и работает именно так.
А самое прикольное что это работает в две стороны, если я что-то предлагать возьмусь, совершенно справедливо получить вопрос: "Дима, а ты как понял что станет лучше?", классно-же. "Пропихнуть" что-то спорное разумеется можно, но придется спорить :-D.
Мы же не дизайнеры, которых просят "сделать красный чуть краснее", мы инженеры, можем все померять, пожем все проверить, провести эксперимент, тесты написать в конце концов, в общем почти нормальный научный процесс.
Можно удариться в карго-культ, и всего этого не делать, а просто прочитать на условном хабре (желательно прямо в этом коменте), что "Все надо переписать на Go/Erlang/Elixir/Python/NodeJS/Typescript/Rust/Zsh" (нужное подчеркнуть), и все станет сразу как в AANGе – тоже подход, но лично по мне, не надежный просто, может станет а может нет.
Так к чему это я, работать в команде это всегда работа с людьми. И тем проще работать, чем люди больше вовлечены, пытаются улучшать те инструменты которыми пользуются, привносят что-то, что поможет всем.
В статье это описано, в первых прототипах админок, был index.html, который надо было врукопашную сортировать, не большая беда, но вот сели и переделали на ESM.
Случилось бы это если бы все были просто "винтики", которых "заставили писать REST-API на С++"? Сомневаюсь. Да и в том что кого-то прям заставляют этим заниматься, тоже.
Можно ли было переделать что-то во flask-admin, тоже наверное можно, но уровень контроля все-же не тот-же самый, по крайней мере мне приятно думать что я все еще имею мою иллюзию контроля.
У всех свои минусы, у нас походу просто команда была не правильная, не хотели flask-admin.
¯\_(ツ)_/¯https://wsrpc.readthedocs.io/en/latest/00-quick-start.html
Пока жив сокет, можешь сохранять все что хочешь, ты же будешь в том-же процессе пока не отключишься
Здорово если есть команда котрая уже это все умеет, но увы в нашей истории все начиналось не так.
Ребята писали что сделали по своему, ты писал на flask-admin )))
UPD: И не просто сделали, а провели исследование что не стало хуже, порверили экспериментально что пользователям админок стало удобнее, код лучше, проще разрабатывать, и критерий "выкатываем формочку за день" в медиане сходится, и самое главное теперь админки начали писать все, а ты тогда один отдувался за всех.
а потом как начинаются пляски с частичной вадидацией формы на 40 полей, ты где будешь хранить то, что запомнил пользователь? В query-string? Или на каждую валидацию POST отправлять? В последем случае пользователь расстроится, если случайно нажмет back в браузере.
Если бы ты не написал бóльшую часть наших админок на фласке, я бы наверное поспорил. Но всякие штуки с реактивностью, с частичной валидацией форм, да даже select2 делается не то чтобы очень гибко и просто.
Вебсокет – это не просто транспорт в этом случае, это еще и контекст который привязан к конкретному процессу конкретного инстанса работы пользователя с бекендом. А инстансов той-же админки, минимум 2-3. То есть пока жив конкретный инстанс веб-сокета, сервер может держать в памяти то, что прислал пользователь, без необходимости шарить состояние между всеми инстансами.
Попробуй как-нибудь на досуге, сделать на фласк-админе форму, куда загружаешь CSVшку и нужно перед сохраниением данных из неё дать пользователю, проверить что все поля нормально помапились.
С flask-admin да и любым CRUD тебе придется все-таки сначала сохранить эту csvшку в базу, потом отрендерить пользователю табличку с мапингом, плюс пагинация плюс фильтры, и плюс много всего еще.
С сокетом просто просишь сервер вот этот блоб провалилировать, потом отдельным rpc вызовом, просишь показать первые 10 строк, к примеру, серверу можно хоть в /tmp/ хранить все время до комита в базу этот файл, и просто ходить по нему вперед-назад.
Когда файл 100мегабайт начинает весить, flask-admin начинает по 60 секунд отвечать на это, так как ему нужно на каждый чих перелопачивать 100 мегабайт в базу и обратно.
Короткий ответ зачем нам понадобился vue:
В вашем случае, на 40-й формочке, у вас уже будет фреймворк, и вам придется его поддерживать.
Мы тогда на brython смотрели, было... забавно, но совршенно неясно, зачем какая-то надстройка над ES6 который нативно выполняет браузер.
Так-же стоит отметить, что у меня был точно такой-же риск, как у руководителя, когда мы с@Alvinerвнедряля вышеописанное решение, никого не потеряли, к счастью.
И как мне кажется, именно потому, что мы никого не превращали в "фулстек"ов, мы четко ограничили проблемы, и наше видение их решения. И диапазон применимости, нашего решения мы умышленно не распространяли дальше вот этих вот "админок".
Ну а если вдруг найдутся коллеги, кому "зашло" то почему-бы не идти в сторону "фулстек"ов.
Если не вырывать из контекста, то целиком цитата выглядит так:
На рынке труда очень много вакансий, если человек занимается тем, что ему не нравится, зачем себя мучать?
В вашей истории про коллегу, я так и не понял, ему нравилось то, чем он занимается, в процессе получения галочки "фуллстек", или нет ? Если и там нет, и он поменял работу потому что не смог договориться с руководителем – это прекрасно, не нужно никого мучать.
Мне кажется, что постоянные секьюрити проблемы, во всем что касалось PHP, 10-15 лет назад тому виной.
И, с моей точки зрения, непонятно почему PHP лучше или хуже чем тот-же Flask-Admin на Python. Принципиально тоже самое.
Мы преследовали цель свести верстку и все что касается фронтенда к минимуму, поэтому просто готовые компоненты на vue https://element.eleme.io/#/en-US/component/form которые просто нужно описать, и все, форма готова.
В яднексе запрещен PHP.
Вот тут как-раз про то, будет ли интересна статья, с неким таким hello-world-project, где по шагам можно воспроизвести это.
Вот в вашем утверждении "не так много" я сомневаюсь. Мне, лично, кажется что "очень много", если у вас есть какие-то ссылки на исследования, по этой теме, любопытно было-бы почитать.
Наша цель, была в том, чтобы разработчику, даже если он не знает JS, но знает Python, нужно было посмотреть JS Quick Start, и просто начать на нем решать задачи, а не заниматься вопросами сборки, транспиляцией, и всем тем что вы описали выше. Да и отлаживать такой код куда проще, просто поставил breakpoint в Developer Tools, и остановился там где надо. В случае с любой транспиляцией – это не так просто.
Как и написано в статье, наша цель была в том, чтобы разработчику потратить минимум усилий для начала, и в нашем случае – получилось, просто делаешь git clone, и запускаешь браузер, все.