• архитектура меня не покидает ощущение, что её у нас никто не понимает. Слышали где-то, что всё должно быть на эвентах, — давай их пихать во все щели. Разбираться с кафкой/хуяфкой некогда — бизнес ждёт — давай эвенты посадим на AWS SQS/SNS а хендлеры на AWS Lambda.

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

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

    Генерируй месседж на PHP, как бог на душу положит, лови его Node-ом без типов, без схем, и помолись только на прощание...

Replies (7)

  • @janPona, кафка не дороже выйдет чем амазон?
  • @BradleyManning, Смотря на чём она крутится. Но никто же не считал и никто не будет считать — потому и говорю, что нет у нас архитектора.

    Другое дело, что Node (когда особенно пишут тем стилем, как у них) на лямбде дороже, чем например, Go на той же лямбде. Там сильно тяжёлые процессы написанные очень коряво.
  • @janPona, Чтобы с кафкой не разбираться, кстати, написали ред панду — типа то же самое но проще и чуть быстрее(хотя по их же собственым тестам несущественно). Но я не знаю, насколько она хороша.
  • @janPona, Что тебе мешает хэндлить сообщения чем угодно другим кроме лямбды если претензии только к ней?

    И зачем в 2021 самому мэинтэнить кафку/хуяфку если есть готовые SQS/SNS?

    @janPona
  • @Anonymous, Не мне, а им. Я про большие объёмы легаси кода, реализованные на лямбдах. Причём написаны они таким стилем, что вот так вот просто взять бизнес-логику и оторвать не получится.

    Я не против самих SQS/SNS, я за более высокий уровень абстракции.

    А то получается ведь как. Фронтэнд-обезьяна садится писать код под лямбду — и пишет его буквально "под лямбду". Прямо из туториала, в котором, разумеется, на абстракцию всем плевать (ради краткости изложения). В итоге, код становится одним огромным куском бизнес-логики, прибитым гвоздями ко всевозможным AWS APIs.

    Запросы в DynamoDB прямо из функции-хендлера? Да пожалуйста! Unit-тесты? Не, не слышал. Оно ведь никогда не упадёт, да и я ведь никогда ничего не буду дописывать. Ну, во втором случае фронтэнд-обезьяна как раз-таким права — дописывать будет уже следующая фронтэнд-обезьяна, то есть я.

    Как правильно? Правильно разделять код на контракты.

    1. Вот у нас контракт для доступа к данным (не к базе данных, это важно, а именно к данным, поскольку они могут быть сегодня в Dynamo, завтра в Mongo, а через год — в отдельном микросервисе)
    2. А вот у нас контракт для зохавывания месседжа (не SNS-месседжа, а просто абстрактного месседжа, но со вполне конкретной и чётко в рантайме валидируемой структурой)
    3. итд

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

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

    Красота же! И именно это, как дополнительный бонус, позволит сделать тим-ворк быстрее соло-ворка.

    А то ведь как у нас тимворк себе представляют. Так, Иванов, вот тебе пачку хендлеров, приступай к реализации. Так, Петров, вот тебе ещё пачку хендлеров, давай, короче, хуярь.

    Сидят Иванов с Петровым и херачат наживую хард-зависимости в коде. Бизнес-то ждёт.

    А ещё прикол — как они отлаживают код, рассказать? Они, блядь, деплоят лямбды на дев-стейдж и запускают их сразу там. Это девелопмент воркфлоу такой, клянусь, сам видел. Не ну а чо.
  • @janPona, welcome to serverless
  • @Anonymous, Нет, это weclome to govnocode