Как это противоречит тому что написано? Это конечно же можно делать как часть процесса обработки месседжа. А там как хотите так и делайте. Хоти в s3 кидайте, хотите в базу. Хотите по ключу определяйте что такой рипорт уже просили и возвращайте данные с прошлой обработки. А где вы их храните — это же ваш бизнес решает.
Тут же не об этом. Тут о том что браузер не будет ждать так долго и оборвет коннекшен. И в добавок если что-то временно пошло не так, можно делать попробовать позже и захендлить этот кейс а не ждать пока юзер обнаружит что что0то зафейлилось и он должен повторить просьбу.
Ну да. Шардинг это не про «отдельный топик по id» (id как пример), это про обеспечение условия fifo по id. Это просто условие что мессежди одного и того же юзера будут обработаны в определенном порядке, за счет того что они прилетят на один и тот же консюмер.
Решение с топиком под каждого юзера кажется мне избыточным и возможно даже не реализуемым. Вот что пишут в самой кафке
Unlike many messaging systems Kafka topics are meant to scale up arbitrarily. Hence we encourage fewer large topics rather than many small topics. So for example if we were storing notifications for users we would encourage a design with a single notifications topic partitioned by user id rather than a separate topic per user.
The actual scalability is for the most part determined by the number of total partitions across all topics not the number of topics itself (see the question below for details).
И
Jun Rao (Kafka committer; now at Confluent but he was formerly in LinkedIn's Kafka team) wrote:
At LinkedIn, our largest cluster has more than 2K topics. 5K topics should be fine. [...]
With more topics, you may hit one of those limits: (1) # dirs allowed in a FS; (2) open file handlers (we keep all log segments open in the broker); (3) ZK nodes.
Проблема в том что в раббите нужно свой велосипед писать для ребалансировки шардов если вдруг нужно убрать/добавить консюмер. Насчет медленности раббита — зависит от задачи. У нас мессежди обрабатываются сравнительно медленно, поэтому скорость самого раббита вообще не интересна.
Давно работаем с раббитом… топлю теперь на работе за ввод кафки в некоторые процессы. В раббите мне не хватает шардинга из коробки, ну и остальные плюшки. Иногда когда все упало нужно риплей сделать, и приходится танцевать с бубном и вытаскивать данные с тяжелых хранилищ типа snowflake. А так как кафка это аппенд онли лог, восстановление системы должно стать намного легче.
Роутинга там как в кролике нет конечно нет, но думаю это можно пережить…
Так паб саб вроде же не хранит сообщения если нет консюмеров… Все таки это больше для fire and forget. Раббит же будет держать месседжи пока ваши сервисы которые возможно лежат из за бага или еще чего не поднимутся, и вы не потеряете данные.
Ну я так думаю ошибка в том, что инвалидация токена это совсем другая проблема и решается она по другому. Так что в брать роль с токена это нормально. А ваше решение возвращает нас назад к сессиям…
Practical engineer
(הנדסאי)
A practical engineer is a professional degree awarded by technological colleges in Israel and validated by the National Institute for Technological Training of the Ministry of Industry, Trade & Labor. Wikipedia.
Вместо 4х лет бакалавриата, тут за 2-3 года в зависимости от программы готовят как вы сказали «готовых рабочих для рынка». Менее престижно конечно, чем инженер, но в принципе если мозги есть то работы всем хватает. Там основной упор идет именно на практику. Вот есть язык, есть фреймоворк, делай так и так. А как оно там устроено, что такое машина тьюринга и O(n) мало кого волнует.
И хоть я 80% знаний получивший от инженерного образования вряд-ли смогу где-то применить, мой потолок роста гораздо выше чем у самоучки (кем я был до учебы) и у таких рабочих. Но, как говорится, кто то пишет калькуляторы, а кто-то компилятору. Что бы вордпресс херачить и делать хттп реквесты, совсем не обязательно учить линейную алгебру, алгоритмы, и вообще знать что такое NP-полные задачи.
Мы с 3х часов дня как белки в колесе. Вот начали немного восстанавливаться. Все вернулось минут на 30, а сейчас опять с перебоями работают. Автоскейлинга нет. Джобы бегут когда им вздумается. Или не бегут вообще.
Вот вот. Идея была хорошая потому что руби он рейлс и джанго хорошие… а вышла какашка с магией, конвенциями и мать его глобальными переменными боже спаси и сохрани… я рад что оно умерло.
Я люблю смарт тв потому что подключил к ви фи, установил нетфликс, эпл тв, картина тв ну или что еще, и не надо заказывать отдельные коробки. Удобно.
Но, UI/UX это сущий ад. Причем почти у всех брендов. Убогий браузер, перенасыщение опциями. Мой LG у меня уже год… и мне до сих пор берет 5 минут найти функцию апдейта апликации или кнопку рестарта апликации. Ну и без клавиатуры это то еще удовольствие, если реально хочешь поиском воспользоваться… а ее не так-то просто подключить.
async function fetchDogs(id) {
let result
if (typeof id === 'string') {
result = await api.fetchDogs(id)
} else if (typeof id === 'array') {
result = await Promise.all(id.map((str) => api.fetchDogs(id)))
} else {
throw new TypeError(
'callSomeApi only accepts a string or an array of strings',
)
}
return result
}
const params = { id: 'doggie123' }
let dogs
fetchDogs(params)
.then((dogs) => {
dogs = dogs
})
.catch((err) => {
if (err instanceof TypeError) {
dogs = Promise.resolve(fetchDogs(params.id))
} else {
throw err
}
})
Как я ненавижу функции которые могут принимать различные типы параметров. А тут в придачу оно еще и возвращает разные структуры. Тестировать такое просто одно удовольствие. И баги ловить когда этот код уже заюзали в десятках мест, и рефакторить… Мы такое на ревью не пропускаем. Ну сделай ты общую функцию которая работает с массивами, и оберни ее аккуратно функцией которая принимает один параметр. И чище, и без магии, и тестов меньше писать нужно.
Ну и на бэкенде далеко с этим не уедешь. Почти всегда нужно знать root cause, поэтому либо error chaining, либо копируем нужные данные с оригинальной ошибки. Ну и ошибки хттп клиентов ловим как можно раньше и оборачиваем в доменные ошибки, и обрабатываем их уже как можно позже, по возможности (как там у жавистов, кидай рано, обрабатывай поздно?).
Есть еще фишки с пробрасыванием контекста внутри ошибки, который помогают понять какой реквест был причиной (если говорим о веб сервере) или меседж (если воркер) если вдруг ошибка не обработалась и получили ексепшен.
Ну а в принципе работа с ошибками без тайп скрипта, то еще удовольствие… мы как те йожики с кактусом =)
Давно давно, после 2 лет работа с ангуляром первым, реакт был как глоток свежего воздуха. И не смотря на то что 90% времени я занимаюсь бэкендом уже долгое время, все таки открыть и подправить что то в реакте намного приятнее чем в том же ангуляре (а у нас есть легаси с первым ангуляром).
Но вот когда сам баловался с реактом на пет проджекте, я как-то огорчился при работе с формами, а конкретно чекбоксами, радио… было чувство что слишком много боилерплейта нужно писать вроде бы для простых вещей типа отмечен чекбокс или нет :/
Вот это вот переименование и замена переменных, с точки зрения фп и чистых функций, я правильно понимаю что дерево должно копироваться полностью от функции к функции? И копируется ли?
Ну у вас это жаба… у нас nodejs. Возможных настроек минимум. На пиковых нагрузках GC заметно тормозит когда создается очень много short-lived объектов. Можно конечно расти вертикально пока не упрешься в потолок или бюджет… и все же, просто игнорировать GC и другие накладные расходы в статьях про ФП это как-то не правильно.
Тут же не об этом. Тут о том что браузер не будет ждать так долго и оборвет коннекшен. И в добавок если что-то временно пошло не так, можно делать попробовать позже и захендлить этот кейс а не ждать пока юзер обнаружит что что0то зафейлилось и он должен повторить просьбу.
Решение с топиком под каждого юзера кажется мне избыточным и возможно даже не реализуемым. Вот что пишут в самой кафке
И
Роутинга там как в кролике нет конечно нет, но думаю это можно пережить…
Вместо 4х лет бакалавриата, тут за 2-3 года в зависимости от программы готовят как вы сказали «готовых рабочих для рынка». Менее престижно конечно, чем инженер, но в принципе если мозги есть то работы всем хватает. Там основной упор идет именно на практику. Вот есть язык, есть фреймоворк, делай так и так. А как оно там устроено, что такое машина тьюринга и O(n) мало кого волнует.
И хоть я 80% знаний получивший от инженерного образования вряд-ли смогу где-то применить, мой потолок роста гораздо выше чем у самоучки (кем я был до учебы) и у таких рабочих. Но, как говорится, кто то пишет калькуляторы, а кто-то компилятору. Что бы вордпресс херачить и делать хттп реквесты, совсем не обязательно учить линейную алгебру, алгоритмы, и вообще знать что такое NP-полные задачи.
И до утра еще далеко :(
Но, UI/UX это сущий ад. Причем почти у всех брендов. Убогий браузер, перенасыщение опциями. Мой LG у меня уже год… и мне до сих пор берет 5 минут найти функцию апдейта апликации или кнопку рестарта апликации. Ну и без клавиатуры это то еще удовольствие, если реально хочешь поиском воспользоваться… а ее не так-то просто подключить.
Как я ненавижу функции которые могут принимать различные типы параметров. А тут в придачу оно еще и возвращает разные структуры. Тестировать такое просто одно удовольствие. И баги ловить когда этот код уже заюзали в десятках мест, и рефакторить… Мы такое на ревью не пропускаем. Ну сделай ты общую функцию которая работает с массивами, и оберни ее аккуратно функцией которая принимает один параметр. И чище, и без магии, и тестов меньше писать нужно.
Ну и на бэкенде далеко с этим не уедешь. Почти всегда нужно знать root cause, поэтому либо error chaining, либо копируем нужные данные с оригинальной ошибки. Ну и ошибки хттп клиентов ловим как можно раньше и оборачиваем в доменные ошибки, и обрабатываем их уже как можно позже, по возможности (как там у жавистов, кидай рано, обрабатывай поздно?).
Есть еще фишки с пробрасыванием контекста внутри ошибки, который помогают понять какой реквест был причиной (если говорим о веб сервере) или меседж (если воркер) если вдруг ошибка не обработалась и получили ексепшен.
Ну а в принципе работа с ошибками без тайп скрипта, то еще удовольствие… мы как те йожики с кактусом =)
Но вот когда сам баловался с реактом на пет проджекте, я как-то огорчился при работе с формами, а конкретно чекбоксами, радио… было чувство что слишком много боилерплейта нужно писать вроде бы для простых вещей типа отмечен чекбокс или нет :/