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

>>20780
Существует ли более быдлокодерский язык чем п*тон?

>>20780
Здесь проблема только в статик методе.
Статик методы - ненужный кал. Специально для даунов придумали модули, ниеееет не хочу, хочу жрать говно и упаковывать в отдельные классы.
Сразу имагинировал харю жавадауна это написавшего на петухоне.

>>21224
Хаха, ты не осилил даже ООП, вот и рвешься, да?

>>21273

>Статик метод

>ООП

Ты ведь даже не понял?

Нейроговно ломает поиск.
Сперва оно в яндексе сломало поиск по хентай картинкам. Искать и находить точные совподения перестало вообще, выдает одно "похожее".

Теперь уже в гугле сам поиск сломало нахуй, один раз спросил как перенаправить сокет в stderr/out и все, на любые запросы оно теперь выдает одно и то же.

>>22043
Вайб-кодеров наверное наняли

>>23470
Ещё и работает над микросервисами 2 человека, а не 20, я угадал?

>>23535
Обычно один. Он же и девопс этой хуйни.

>>23542
Мда. Учитывая архитектурное решение про общую БД и количество инженеров нужно было делать модульный монолит. Микросервисная архитектура имеет единственный плюс над монолитом это возможность изоляции разработчиков в отдельных микросервисах.

Вспоминаем закон Конвея про то, что 1 разработчик делает задачу за 10 единиц времени, а 10 разработчиков делают ту же задачу за 5 единиц времени. Почему не в 10 раз быстрее, а только в 2 раза быстрее? Потому что большая часть потенциально выигрышного времени на разработку было потеряно вследствие согласований действий этих разработчиков между собой.

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

Ответом на эти проблемы организации разработки ПО стала микросервисная архитектура, которая буквально разбила 10 разработчикам на 10 отдельных микросервисов сказав им, что они должны согласовывать свою работу только с одним солюшен архитектором. В итоге у нас 10 параллельно (в идеале) выполняемых задач, без мердж конфликтами, с маленькими и изолированным кодовым базами.

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

недавно лекцию про это слушал

>>23545
Микросервисы - это чисто галерная хуйня. Они нужны, чтобы нанять литерали любых васянов с любым стеком и быстро-быстро накидать очередной финтех очередному арабу, пока араб не одумался.
На проде с микросервисами сначала все долго ебутся с консистентностью и распределенными транзакциями, джуны вращают деревья, потом приходит новый грамотный СТО и просто объединяет 100500 микропенисов в один монолит.

>>23546

> На проде с микросервисами сначала все долго ебутся с консистентностью и распределенными транзакциями

Поэтому и нужен хороший солюшен архитектор, чтобы ебаться меньше.

> джуны вращают деревья, потом приходит новый грамотный СТО и просто объединяет 100500 микропенисов в один монолит.

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

>>23553
Большинство людей слишком сыкуны чтобы применять их. Нужно выделить БД отдельные, продумать линии раздела ответственности.

Как раз наличие разделеных транзакций признак ошибки. Мое ИМХО, в идеале сервисы не знают друг о друге и пукают сообщения и события о том что они делают, другие на них реагируют не зная кто и как их пукает.
Прямые вызовы оправданы при обращение к каким-то базовым узлам типо сервиса авторизации и прав, сервисы хранилища и тп. Также необходимо продумать как фронт с ними общается, возможно нужны BFF сервисы которые выступают фасадом для фронта.

Нужно понимать стоит ли вся эта ебатека того. Тем более это ебучий миф что на микросервисы можно нанимать кого угодно, ровно наоборот для них нужны команды из одних мидлов и 1-2 ультра сильных сенек которые держат в голове систему.

>>23639

>пукают сообщения и события

Классическая ошибка. Кто в этой охуительной архитектуре будет делать откаты и ретраи, если все только пукают в кафку и друг о друге не знают?

>>23710

>Кто в этой охуительной архитектуре будет делать откаты и ретраи

Никто. Ретраи не нужны, очереди гарантируют at least once. Сообщение или обработано или нет, дальше проблемы твоего говнокода который потвердил обработку без реальных действий.

Откаты не нужны если ты нормально поделил сервисы. В любом случае ты можешь порадить событие "заказ проебан", "заказ не может быть доставлен", "докуемент был отклонён" и тд. Дальше сервисы реагируют на них.

Атомарность бизнеса миф. Даже транзакции в банке идут не атомарно, там атомарны только этапы проверки возможности перевода денег, операция списание/зачисление, но это могут делать разные сервисы в разное время в разных частях планеты на разных физических машинах они не связаны и друг о друге не знают.
Сервис проверки возможности проведения операции по счету не знает зачем его об этом спросили, а сервис клиринга не знает откуда пришёл приказ, он только знает что в случае ошибки он должен сообщить об этом в этот канал и продолжить работу.

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

>>23730
О, вы из яндекс маркета!

Бамп. Мне скучно. Набугуртите чего-нибудь

>>27874
Легко.
ОТПРАВЛЯЕШЬ РЕЗЮМЕ НА ЛИНКЕДИНЕ
@
ПОЯВЛЯЕТСЯ ОКСАНКА UA, ЗАДАЕТ ВОПРОСЫ ПРО ОПЫТ И СТЕК
@
ВСЕ ОТВЕТЫ ЛИТЕРАЛИ НАПИСАНЫ В РЕЗЮМЕ
@
ОТВЕЧАЕШЬ
@
ОКСАНКА БОЛЬШЕ НЕ ПИШЕТ

>>29202
полный айтикапец не наступит. потому что на анальника сычева можно наорать, заставить фиксить свое говно, уволить, засудить, вывезти в лес в багажнике в конце концов.
а невросеть будет просто отвечать "ой) извините за путаницу))" пока кабанчик бегает кругами и теряет миллиарды

>>29931
Я думаю реальная перспектива замены кодерков появится когда выкатят кодописательные сервисы с возмещением ущерба от проёбов в сгенерированном коде.

>>30242
Да все это страхуется, находится коэффициент итд. В результате будет подписка за 100 баксов в месяц, со включенной страховкой за упавший прод.
Профит.

>>30242
У программистов нет материальной ответственности. У нейросеток её не будет тем более.
У любого софта в лицензионном соглашении написано, что его производители никакой ответственности ни за что не несут, всё использование на свой страх и риск.

>>30248
Ты плохо себе представляешь, какое раздолье откроется для махинаций.

>>21224
статик метод - чистая функция. ООП говно не нужно

>>21915
ПРИВЕТ
@
ПРИВЕТ
@
печатает 5 минут
@
устаешь ждать и переключаешься
@
он наконец допечатал и высрал 2 предложения

>>33370
В чем не прав?

Вспомнил как админил шаред хостинги, там 1 упоротый клиент хранил тонны важной бизнес информации в MySQL базе tmp, бесплатно без регистрации и смс. Когда она была дропнута, бугурт был выше неба..

>>33622
В том что токен буквально нужен чтобы передавать в нем информацию про права пользователя и прочее вместо 100500 запросов во все сервисы на каждый пук.

>>33856
Токен нужен, чтобы передать в нем session ID, который как правило совпадает с user ID. Все остальное хранится в редисе.

>>33370
JWT - это вообще полная залупа, которую нельзя отозвать. Или надо хранить список отозванных токенов. Почему обычные рэндомные токены нельзя использовать? Мне кажется они безопаснее

>>37201
JWT-токены задумывались для интеграций, где нет проблем с отзывом, но дебилы, которые вообще нихуя не слышали об информацонной безопасности, начали их использовать для аутентификации пользователей.

>>37201
Ты родился в 2010 году, что ли?
Раньше все использовали рандомные токены и шифровали куки как могли, везде со своими уязвимостями. Потом придумали единый механизм JWT. Токен - это обычная кука сессии, только теперь тебе не надо париться за криптографию. Кладешь туда юзер айди, дальше сперва проверяешь валидность подписи на нжинксе, затем проверяешь, что у тебя в редисе есть сессия с таким айди. В сессии лежат роли пользователя и прочая хуйня.

>>37698
Какие редисы блять.
Токен буквально нужен для передачи клеймов пользователя и валидации без участия сервера авторизации.

Кладёшь в json нужную информацию, подписал, передал.

>>37764
Мы вам не перезвоним.

>>37805
Но он прав. Особенно если у тебя сингл сайн он в нескольких приложениях.

А если приложение одно, то токены нахер не нужны, положил ид сессии в куку и всё.

>>37873
Токен это и есть универсальная кука для всех клиентов, не только для браузера. Со стандартной защитой и проверкой в два этапа.

>>20703

> коды состояния HTTP должен отдавать веб-сервер, а не приложение,

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

другое дело это может быть не всегда удобно (например у приложения может быть 100500 кодов возврата, и однозначно переложить их на http-коды будет проблематично) и не всегда возможно (например варианты вызова не через http-транспорт).

>>37877
У кук есть куча встроенных фич типа времени действия и защит от распространения. Для твоего токена в хедере это всё придётся писать руками.
Зачем что-то писать, если можно не писать?

>>39380
Не, ну нахуй, там же нихуёвый риск помереть, и чё я тогда делать буду? Вдруг в аду нет двача???

>>37764
а как проверять что sign в jwt токене совпадает с содержимым? Я например расшариваю соль подписи между серверами

>>39448
Между какими серверами? Ты внутри кубера гоняешь токены?

>>38215
это вопрос архитектуры и философии

http используется как транспортный протокол. Следовательно читать и писать http коды могут только транспортные устройства - вебсерверы в данном случае.

Твоя приложуха - это чистый бизнес, бизнес должен знать только про бизнес, но не про транспорт и коды транспорта. Ты же не задаешь в своей приложухе какие-нибудь TCP коды?

Соответственно приложуха не должна ничего знать про http и коды http.

Вебсервер получил 200 - транспорт сработал корректно, передаем результат приложухе, она разбирает ответ, и возможно в этом ответе есть бизнес-код результата, ошибка валидации например.
Но кто и в какой момент вдруг решил что "не сведён баланс" требует изменения http кода?

>>39454
сервер авторизации
сервер заказов
сервер предложений

Пришёл запрос в сервис заказов с jwt токеном. Как узнать что подпись корректная? Гнать ещё один синхронный запрос в сервис авторизации? Или проще добавить jwt либу и расшарить соль, чтобы сервис заказов мог проверять корректность подписи

>>39456
Ты делаешь неправильно. Запрос приходит в гейтвей, там сначала на нжинсе проверяется валидность подписи, потом наличие сессии в редисе. Если все ок, дальше между серверами ездит просто юзер айди без всяких токенов.
Сервер авторизации нужен, чтобы по логину@паролю получить пару токенов и потом по рефреш токену получить новую пару. Его не надо дергать на каждом запросе.

>>39456

>Пришёл запрос в сервис заказов с jwt токеном. Как узнать что подпись корректная?

Хранить сертификат сервера авторизации и проверять токен?

>>39458
Скажи где ты работаешь чтобы не попасть в такую порашу. То есть в вашей хуйне достаточно попасть за гетвей и ты НИКОГДА не поймёшь что в системе работает шпион.

>>39458
>>39468
Алсо.
Для проверки токена не нужно вообще обращаться с серверу авторизации.

Токен публичная информация ты можешь открыть его любым удобным способом просто прочитав из base64. Далее мы проверяем метку времени что он вообще ещё не истек, потом мы берём публичный ключ сервера. Ведь наш сервер соответствует OAuth2, да? С помощью публичного ключа мы локально проверяем подпись токена чтобы убедиться в том что он не был изменен или подделан.
Публичный ключ запрашивается как сертификат x509, один раз, повторно он запрашивается только в случае провала проверки чтобы убедиться что он не был перевыпущен или просто раз в N дней.

В любом нормальном языке есть куча библиотек, часто это часть базовой библиотеки, которые берут на себя всю тряхомудию по хранению сертификата и его актуализации и проверке токена.

>>39473
кстати зачем вообще придумали все эти 100500 видов файлов сертификатов с вечными проблемами? Почему нельзя взять просто набор символов в виде ключа?

>>39479
Ты же рубишь за асимметричную кривографию и принципы управления ключами?

>>39523
не. Ключи это не просто набор байтов?

>>39525
Чувствуешь себя в безопасности?

>>39479
Чтобы убедиться что сертификат выдан кем надо и подпись на нем какая надо и тд и тп.
Криптография реально довольно заебная штука из-за 100500 слоев безопасности на безопасность для безопасности.

>>39479
Какие 100500? Формат сертификата это X509 стандарт, кодируется либо в DER либо в PEM формате. Последнее это привычный текстовый формат в base64.