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

ну каких комнатных? 2бп, 2 отдельных ввода, резервирование коммутаторов и аплинков.

Ну, а кто потребители? Тут обычно проблемы со стороны потребителей, потому что у них чаще всего сеть не надежна.

Если у вас какой-то крутой бизнес-сектор, где все работают с терминалов - ну, круто.

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

Хм ... а что мешает провернуть такой подход аналогичным образом, добавить параметр with_user для ордеров и вытягивать пользователя сразу с ордером? Или они будут у вас лежать в разных бд и следить за целосностью вы будете с приложения?

Скажем, какому-то разработчику нужен был не id пользователя, а его имя. И вместо того, что бы делать два запроса, он решил просто поменять формат у orders сервиса.

Если у вас какой-то крутой бизнес-сектор, где все работают с терминалов - ну, круто.

нет, обычные физики. если что-то у 1-20физиков отвалится - фигня. если отвалится у нас - пострадают десятки тысяч физиков.

нет, обычные физики. если что-то у 1-20физиков отвалится - фигня. если отвалится у нас - пострадают десятки тысяч физиков.

То есть вы можете написать реконнект у себя в приложении, как я понимаю. Или я не прав?

Хм ... а что мешает провернуть такой подход аналогичным образом, добавить параметр with_user для ордеров и вытягивать пользователя сразу с ордером? Или они будут у вас лежать в разных бд и следить за целосностью вы будете с приложения?

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

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

Даже если мы говорим про тот же python, уже есть mypy, который позволит сделать проверку на "этого поля в этом абстрактном классе нет"

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

Сложно и неявно, если не обложено тестами, можно даже не сразу заметить, что сломал что-то в редко используемом вызове

То есть вы можете написать реконнект у себя в приложении, как я понимаю. Или я не прав?

не могу.

А как вы избегаете такой же проблемы в микросервисе? Тестами или ручным ревью?

У меня питон-код обложен на 90% и больше юнитами, но все равно где-нибудь за стреляет, про какую ты аналитику говоришь

Ревью у нас везде есть, но заревьювить то, что изменяется api как-то гораздо проще, это проходит тщательный контроль и согласование всех отдельных разработчиков сервисов, если такие есть

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

Даже если мы говорим про тот же python, уже есть mypy, который позволит сделать проверку на "этого поля в этом абстрактном классе нет"

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

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

мы этот вопрос решили проще: grpc.

да, такую фигню мне и ide подсветит, в этом нет проблемы

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

Мне казалось, как раз для взаимодействия стоит использовать абстрактные классы, разве нет?

мы этот вопрос решили проще: grpc.

++

Ну и, кто-то меняет grpc конфиг и загорается желтая лапмочка и все бегут ревьют? Окей, что мешает сделать аналогично, если, скажем, программист меняет модель или AbstractDummyService?

Ну и, кто-то меняет grpc конфиг и загорается желтая лапмочка и все бегут ревьют? Окей, что мешает сделать аналогично, если, скажем, программист меняет модель или AbstractDummyService?

нет. ты не можешь втихую что-то добавить в api или параметры, потому что работать ничего не будет, в первую очередь у тебя.

нет. ты не можешь втихую что-то добавить в api или параметры, потому что работать ничего не будет, в первую очередь у тебя.

Эм ... а что мне мешает сразу взять и поменять это в 2-3 сервисах? И запушить

А на остальные забить

и в рантайме остается только минимум проверок.

А давайте замутим сходочку monlithic vs microservices в стиле battle royale

Эм ... а что мне мешает сразу взять и поменять это в 2-3 сервисах? И запушить

организационные меры. но это решается на стадии деплоя.

А давайте замутим сходочку monlithic vs microservices в стиле battle royale

А где мы найдем такое количество сторонников монолита? У нас в дискуссии только один вот

Уверен, у него есть друзья

Придется в биполярочку сразу за две стороны выступать, а это мы можем и локально

А на остальные забить

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

что за тренды

биполярные расстроства ото всех слышу

самоосознавать себя начали чтоли

психологи комнатые)

биполярные расстроства ото всех слышу

феномен Баадера-Майнхоф небось

А давайте замутим сходочку monlithic vs microservices в стиле battle royale

а смысл? итог будет очевиден: окажется что у одептов монолита просто нет соответствующего опыта написания/эксплуатации.

феномен Баадера-Майнхоф небось

спасибоньки

новая информация

а смысл? итог будет очевиден: окажется что у одептов монолита просто нет соответствующего опыта написания/эксплуатации.

А как же ядро линукс, у Торвальдса нет опыта скажешь?)

да Торвальдс вообще дилетант!

только странно одно

https://kray-zemli.livejournal.com/368252.html

инфу я эту получил год-2 назад

(это пост одного сумасшедшего бывшего коллеги)

ну и Торвальдс к нам, скорее всего, не придёт

(это пост одного сумасшедшего бывшего коллеги)

блин, это пост правда близкого к шизофрении человека, как он умудряется в одном посте про linux и демографическую яму 90-х в рашке писать. Чем nt-ядро лучше линукса тоже непонятно..

ближе некуда

А как же ядро линукс, у Торвальдса нет опыта скажешь?)

Там все довольно грустно, потому что одна ошибка и либо паника, либо порча данных.

https://kray-zemli.livejournal.com/368252.html

Ядро Windows и правда классная только win32api ужасен

Ядро Windows и правда классная только win32api ужасен

Я не знаю, что классного ты там увидел, оно неплохое, что я видел в вузе и что MS распространяют для обучения, но супер-пупер там тоже ничего. Например, ядра qnx или xnu совершенно другая история

а смысл? итог будет очевиден: окажется что у одептов монолита просто нет соответствующего опыта написания/эксплуатации.

Мне кажется, абсолютно тоже самое можно сказать и про адептков микросервисной архтитектуры. Все те проблемы, которые вы решаете техническими средствами в микросервисах, их же можно решить в монолите. Единственная проблема, которую нельзя решить - частичный деплой.

Я не знаю, что классного ты там увидел, оно неплохое, что я видел в вузе и что MS распространяют для обучения, но супер-пупер там тоже ничего. Например, ядра qnx или xnu совершенно другая история

Оно продумано, инфраструктура драйверов-фильтров, работающий aio

Дисскусии о цене решения довольно такое себе, потому что сильно зависит от подхода и в кадом случае будет разной.

Мне кажется, абсолютно тоже самое можно сказать и про адептков микросервисной архтитектуры. Все те проблемы, которые вы решаете техническими средствами в микросервисах, их же можно решить в монолите. Единственная проблема, которую нельзя решить - частичный деплой.

Использование разных языков под задачу?

Использование разных языков под задачу?

https://hackernoon.com/extending-python-3-in-go-78f3a69552ac https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/ Всегда можно сделать shared library и подключить если язык компилируемый. Если нет, всегда можно создать объект рантайма и с ним работать.

Мне кажется, абсолютно тоже самое можно сказать и про адептков микросервисной архтитектуры. Все те проблемы, которые вы решаете техническими средствами в микросервисах, их же можно решить в монолите. Единственная проблема, которую нельзя решить - частичный деплой.

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

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

Всмысле? В микросервисной архитектуре вам не нужен человек, который будет знать как все эти штуки вместе работают, что бы принимать решения о том, что апи менять можно или нет? Это автоматизировано? Что мешает так сделать в монолите?

Ребят, есть кто работал с апи сайта на битриксе?

Если у вас для каждого сервиса отдельный человек, так же можно сделать для каждого компонента в монолите.

https://hackernoon.com/extending-python-3-in-go-78f3a69552ac https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/ Всегда можно сделать shared library и подключить если язык компилируемый. Если нет, всегда можно создать объект рантайма и с ним работать.

Например ты уперся в производительность Django: что именно ты будешь заменять? OK, не Django а asyncio?

Переписать конкретный кусок кода на cyhton?

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

Вот прямо вся django тормозит?

Всмысле? В микросервисной архитектуре вам не нужен человек, который будет знать как все эти штуки вместе работают, что бы принимать решения о том, что апи менять можно или нет? Это автоматизировано? Что мешает так сделать в монолите?

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

Очень много простых функций из разных модулей вызывают друг друга. Какой кусок кода переписывать?

Переписать конкретный кусок кода на cyhton?

Так появился uvloop. Но он ускоряет всего в 3-4 раза, не более

Переписать конкретный кусок кода на cyhton?

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

Очень много простых функций из разных модулей вызывают друг друга. Какой кусок кода переписывать?

Звучит как "десять микросервисов, единого формата обмена данными нет, каждый работает с каждым и в API куча шлака, никакой версионности, какие методы что использует никто не знает и все тормозит, что будете переписывать в первую очередь?". Почему-то вы берете крайний плохой случай монолита и крайний хороший случай микросервисной архитектуры. Почему так?

https://hackernoon.com/extending-python-3-in-go-78f3a69552ac https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/ Всегда можно сделать shared library и подключить если язык компилируемый. Если нет, всегда можно создать объект рантайма и с ним работать.

Как по-твому, написать shred library с других языков и с биндингами это тот же уровень знаний, что и разбить на микросервисы и писать на том, на чем это эффективно?

К сведению питон-прогрммист перегоняется в го-программиста в среднем за 2 недели и способен уже нормально контрибутить

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

К сведению питон-прогрммист перегоняется в го-программиста в среднем за 2 недели и способен уже нормально контрибутить

Потому что go это язык, к которому нужно в добавок учить несколько инструментов для кодогенерации?

Полгода пишу, еще ничего не генерировал, чяднт?

К сведению питон-прогрммист перегоняется в го-программиста в среднем за 2 недели и способен уже нормально контрибутить

+

И даже interface{} не использовал? Магия какая-то :)

И даже interface{} не использовал? Магия какая-то :)

грепнул проект, использовал один раз, с целью обернуть ответ в data - Data interface{} json:"data" map[string]interface{} часто для работы с модельками

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

я тоже еще пока кодогенерацией не пользуюсь

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

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

Багдрайвен девелопмент)

я правильно понимаю, что мокросервисы это попытка сделать юникс-вей?

Bogdan (SirEdvin) спасибо за дискуссию энивей, но мне пора уходить)

но без учета того, что юникс-вей подразумевает две вещи (а не одну, которую обычно все имеют в виду, когда говорят про юникс-вей)

Я не согласен с тем, что с микросервисами у них все будет лучше, но удачи)

я правильно понимаю, что мокросервисы это попытка сделать юникс-вей?

Пишите программы, которые делают что-то одно и делают это хорошо. Пишите программы, которые бы работали вместе. Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс». Последний пункт точно мешает

ну я поэтому говорю две вещи - потому что пункты 2 и 3 я бы переформулировал как "которые бы использовали простой универсальный интерфейс"

я правильно понимаю, что мокросервисы это попытка сделать юникс-вей?

Именно

ребят, посоветуйте по рефакту явно дублирую код https://pastebin.com/rbvPy2eP чё тут можно сделать?

ну я вижу функции, которые различаются только строкой sql

сразу скажу - не надо конструировать строку sql, надо делать prepare с плейсхолдерами и потом подставлять значения

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

def my_decorator(func): def inner(self, *args, **kwargs): try: бла-бла cur = тыц-тыц func(self, cur, *args, **kwargs) бла-бла except чота: куда-то return inner ... @my_decorator def add_email(self, cur, email='', status=0): cur.execute(чего-то)

не сильно понял чё делать (разве что завернуть в декораторы) но всяко спасиб я хотел обернуть работу с бд в класс... что б поковырять ООП

примерно так

cur.execute("INSERT INTO main_table(email, status) VALUES (?, ?)", email, status)