ну вообще, чисто теоретически можно прям в репозиторий закинуть мьютекс с транзакцией, единственное что придется каждый раз в юзкейсах делать по 2 дополнительных вызова открытия / закрытия транзакции. но на Go возможно есть более изящный способ с этим выкрутится, сам на нем почти не писал
если затянуть redux для "общей информации" на весь сайт, то уже на этом моменте вы занесли огромную простыню JS на каждой странице и получили медленную загрузку. Context API прекрасно справляется с задачей Стейт менеджера для небольшого объема данных
Использовать стейт менеджер в Next для небольших объёмов данных не то чтобы профитно. Часто для таких задач хватает контекстного менеджера с каким-нибудь браузерным хранилищем. Так же часто используются query параметры.
ИМХО использовать стейт менджер можно в случаях когда на странице много динамичных данных либо данные используется по всему приложению и их так же много и они динамичны
Мне пока не довелось встретить кейс, в котором для решения задачи нужно было бы тащить стейт менеджер. С грамотной декомпозицией и архитектурой можно обходиться и без него.
Так же рекомендую ознакомится с новой документацией Next, которая включает в себя использование папки app. Код выглядит немного красивее и очевиднее. Это теперь не бета функционал. В качестве легковестной современной альтернативы Redux сущевствует Zustand.
Я не знаю сюда ли я пишу, но на сколько я смог понять из документации aio-pika, когда мы используем channel.set_qos(prefetch_count=<int>) то мы задаём количество операций, которое за раз может взять на себя consumer. Но я нашел у вас в коде это (propan/brokers/rabbit/rabbit_broker.py:69):
max_consumers, это переменная которая отвечает за количество инстансов consumer'ов которые будут крутиться (судя по названию). В таком случае получается что каждый из них будет брать столько задач, сколько всего instance'ов. Просто я например ставлю это значение на 50-100, зная что у меня все задачи IO-bound, и в таком случае всё ок работает. Поправьте если я ошибаюсь.
Я понимаю что версионность каждый ведёт как хочет. Но у меня был неприятный опыт использования подобной библиотеки. Дважды наступать на грабли я не хочу. Такие библиотеки (непопулярные) генерируют намного меньше issues оттого багов в ней может быть потенциально больше. Не поймите меня не правильно, но писать на главной странице что мы готовы в продакшену когда проект только-только появляется это тоже перебор. Я хочу чтобы библиотека жила и развивалась. Я чуть было не взял AMQ, который тут тоже любят рекомендовать. Только вот уже более полугода без релизов. И да, останусь при своём, звёзды в большинстве случаев отражают приблизительную реальность. И если бы я смотрел только на звёзды - тогда бы я остался использовать Celery, ведь там их в 20 раз больше, не так ли?)
С разделением кода для celery звучит конечно не очень) пожалуй напишу больше кода для aio-pika
На счёт сравнения с Celery. Во первых, если прочитать статью что заголовок означает то, что я выкинул из проекта Celery заменив на aio-pika и стало лучше. Во вторых это отчасти уместно сравнивать т.к. в большинстве мест где используется Celery можно было бы обойтись именно такими быстрыми и лёгкими вариантами вокруг AMPQ. Celery старый и надёжный ящик. О котором все знают и берут его для работы с очередями и для отложенных задач. Цель статьи - распространять далее идею о том что celery это не единственное что можно для этого взять.
На счёт RPC, да, к сожалению обратил на него внимание слишком поздно. Можно было бы и через него. Но в целом даже смотря сейчас на свой результат, мне он понравился, и не так много кода я написал, чтобы этого достичь.
Смотрел, но как было сказано в статье для меня было важным критерием 500+ звёзд. Версия библиотеки 0.5, но на главной странице заявлено что она production ready. Что тоже вызвало некоторые сомнения. Хочу и могу назвать библиотеку сырой, хотя выглядит она вполне себе неплохо. Возможно позже она заменит всех вышеперечисленных, но пока что я предпочту подождать
В самом начале статьи было сказано о чем пойдет речь далее. Под конец написания я и сам задумался о названии, но пока мне сложно переименовать и перенести в ветку reverse-инженеринга, т.к. это сложно таковым назвать. Статью решил оставить, так как придумал хорошее оправдание, о котором написано в конце статьи. Уж извините, если не оправдал ваших надежд.
Очень вам рекомендую с ней разобраться. Это на данный момент лучшая библиотека для работы с БД. Хоть у нее и нету никаких скрытых удобных плюшек как у многих ORM. Я и сам когда первый раз столкнулся, то испугался документацию, ее сложность и запутанность. Но на деле вы будете пользоваться лишь частью всей этой функциональности. В целом с уверенными знаниями SQL ее освоить не так уж сложно. Если не она, то Django-ORM может стать неплохой альтернативой. Потому что в ней можно неплохо так оптимизировать все запросы, если вдруг возникнет необходимость. Другие библиотеки рекомендовать не буду. Т.к. я в свое время пробовал некоторые и выделять особо нечего. Возможно что-то новенькое и появилось, давно не проверял. Рекомендую выбирать библиотеку под свой уровень и по кол-ву звёздочек на Гите, с большего не ошибётесь, но SqlAlchemy определенно маст хэв.
хм, а на 4pda подобных инструкций случайно не предостаточно? Выглядит и звучит как инструкция, а не как личный опыт, либо личные проблемы с которыми вы столкнулись. Совершенно бесполезная статья, информация по данной теме гуглится за 5 минут и не разбросана по разным уголкам интернетов...
Опять же, я не говорил что GIL это главная проблема в скорости Python. В данной статье и в области этих комментариев речь шла про асинхронность в Python. С остальным соглашусь. И возможно добавлю с этот список "некомпилируемость", интерпретация на лету тоже раскладывает свои грабли.
Я тут имел ввиду отсутствие нативной поддержки асинхронности языка. Питон имеет библиотеки для того чтобы это работало, но под капотом все равно имеем дело с синхронным GIL. Взять то же GO, который имеет встроенные в язык горутины, который был создан уже после того как в мире появился компьютер с двумя ядрами. И да, питон хорош в определенном спектре задач, но не на столько хорош по скорости. Имея такой подход к асинхронности у нас появляется множество проблем касаемо того, как управлять этим сторонним, не присущим ядру языку потоку.
Я долго ломал себя на то чтобы браться за Celery, но и на aiopika в сожалению ранее нигде не натыкался. Сейчас глянул доку мельком, очень понравилось. Спасибо за ваши комментарии, пойду тыкать). Для контроля ресурсов вешал на воркера Cgroups и в случае чего он килял процесс, а докер его снова заводил. Касаемо запуска тасок внутри тасок: всяким образом старался обходить такие вещи, потому что я всегда работаю с Celery как с чем-то, что может в какой-то момент повести себя непредсказуемо и делаю так, чтобы он выполнял не более одной задачи.
ну вообще, чисто теоретически можно прям в репозиторий закинуть мьютекс с транзакцией, единственное что придется каждый раз в юзкейсах делать по 2 дополнительных вызова открытия / закрытия транзакции. но на Go возможно есть более изящный способ с этим выкрутится, сам на нем почти не писал
если затянуть redux для "общей информации" на весь сайт, то уже на этом моменте вы занесли огромную простыню JS на каждой странице и получили медленную загрузку. Context API прекрасно справляется с задачей Стейт менеджера для небольшого объема данных
папка app уже отмечена стабильной и перенесена в основной раздел документации.
Использовать стейт менеджер в Next для небольших объёмов данных не то чтобы профитно. Часто для таких задач хватает контекстного менеджера с каким-нибудь браузерным хранилищем. Так же часто используются query параметры.
ИМХО использовать стейт менджер можно в случаях когда на странице много динамичных данных либо данные используется по всему приложению и их так же много и они динамичны
Мне пока не довелось встретить кейс, в котором для решения задачи нужно было бы тащить стейт менеджер. С грамотной декомпозицией и архитектурой можно обходиться и без него.
Так же рекомендую ознакомится с новой документацией Next, которая включает в себя использование папки app. Код выглядит немного красивее и очевиднее. Это теперь не бета функционал. В качестве легковестной современной альтернативы Redux сущевствует Zustand.
Я не знаю сюда ли я пишу, но на сколько я смог понять из документации aio-pika, когда мы используем
channel.set_qos(prefetch_count=<int>)то мы задаём количество операций, которое за раз может взять на себя consumer. Но я нашел у вас в коде это (propan/brokers/rabbit/rabbit_broker.py:69):max_consumers, это переменная которая отвечает за количество инстансов consumer'ов которые будут крутиться (судя по названию). В таком случае получается что каждый из них будет брать столько задач, сколько всего instance'ов. Просто я например ставлю это значение на 50-100, зная что у меня все задачи IO-bound, и в таком случае всё ок работает. Поправьте если я ошибаюсь.
Я понимаю что версионность каждый ведёт как хочет. Но у меня был неприятный опыт использования подобной библиотеки. Дважды наступать на грабли я не хочу. Такие библиотеки (непопулярные) генерируют намного меньше issues оттого багов в ней может быть потенциально больше. Не поймите меня не правильно, но писать на главной странице что мы готовы в продакшену когда проект только-только появляется это тоже перебор. Я хочу чтобы библиотека жила и развивалась. Я чуть было не взял AMQ, который тут тоже любят рекомендовать. Только вот уже более полугода без релизов. И да, останусь при своём, звёзды в большинстве случаев отражают приблизительную реальность. И если бы я смотрел только на звёзды - тогда бы я остался использовать Celery, ведь там их в 20 раз больше, не так ли?)
С разделением кода для celery звучит конечно не очень) пожалуй напишу больше кода для aio-pika
На счёт сравнения с Celery. Во первых, если прочитать статью что заголовок означает то, что я выкинул из проекта Celery заменив на aio-pika и стало лучше. Во вторых это отчасти уместно сравнивать т.к. в большинстве мест где используется Celery можно было бы обойтись именно такими быстрыми и лёгкими вариантами вокруг AMPQ. Celery старый и надёжный ящик. О котором все знают и берут его для работы с очередями и для отложенных задач. Цель статьи - распространять далее идею о том что celery это не единственное что можно для этого взять.
На счёт RPC, да, к сожалению обратил на него внимание слишком поздно. Можно было бы и через него. Но в целом даже смотря сейчас на свой результат, мне он понравился, и не так много кода я написал, чтобы этого достичь.
Смотрел, но как было сказано в статье для меня было важным критерием 500+ звёзд. Версия библиотеки 0.5, но на главной странице заявлено что она production ready. Что тоже вызвало некоторые сомнения. Хочу и могу назвать библиотеку сырой, хотя выглядит она вполне себе неплохо. Возможно позже она заменит всех вышеперечисленных, но пока что я предпочту подождать
вообще, то что у вас такие схемы валидны уже само по себе является ошибкой. При хорошей архитектуре такого просто не должно быть.
В самом начале статьи было сказано о чем пойдет речь далее. Под конец написания я и сам задумался о названии, но пока мне сложно переименовать и перенести в ветку reverse-инженеринга, т.к. это сложно таковым назвать. Статью решил оставить, так как придумал хорошее оправдание, о котором написано в конце статьи. Уж извините, если не оправдал ваших надежд.
Очень вам рекомендую с ней разобраться. Это на данный момент лучшая библиотека для работы с БД. Хоть у нее и нету никаких скрытых удобных плюшек как у многих ORM. Я и сам когда первый раз столкнулся, то испугался документацию, ее сложность и запутанность. Но на деле вы будете пользоваться лишь частью всей этой функциональности. В целом с уверенными знаниями SQL ее освоить не так уж сложно. Если не она, то Django-ORM может стать неплохой альтернативой. Потому что в ней можно неплохо так оптимизировать все запросы, если вдруг возникнет необходимость. Другие библиотеки рекомендовать не буду. Т.к. я в свое время пробовал некоторые и выделять особо нечего. Возможно что-то новенькое и появилось, давно не проверял. Рекомендую выбирать библиотеку под свой уровень и по кол-ву звёздочек на Гите, с большего не ошибётесь, но SqlAlchemy определенно маст хэв.
хм, а на 4pda подобных инструкций случайно не предостаточно? Выглядит и звучит как инструкция, а не как личный опыт, либо личные проблемы с которыми вы столкнулись. Совершенно бесполезная статья, информация по данной теме гуглится за 5 минут и не разбросана по разным уголкам интернетов...
Опять же, я не говорил что GIL это главная проблема в скорости Python. В данной статье и в области этих комментариев речь шла про асинхронность в Python. С остальным соглашусь. И возможно добавлю с этот список "некомпилируемость", интерпретация на лету тоже раскладывает свои грабли.
Я тут имел ввиду отсутствие нативной поддержки асинхронности языка. Питон имеет библиотеки для того чтобы это работало, но под капотом все равно имеем дело с синхронным GIL. Взять то же GO, который имеет встроенные в язык горутины, который был создан уже после того как в мире появился компьютер с двумя ядрами. И да, питон хорош в определенном спектре задач, но не на столько хорош по скорости. Имея такой подход к асинхронности у нас появляется множество проблем касаемо того, как управлять этим сторонним, не присущим ядру языку потоку.
Я долго ломал себя на то чтобы браться за Celery, но и на aiopika в сожалению ранее нигде не натыкался. Сейчас глянул доку мельком, очень понравилось. Спасибо за ваши комментарии, пойду тыкать). Для контроля ресурсов вешал на воркера Cgroups и в случае чего он килял процесс, а докер его снова заводил. Касаемо запуска тасок внутри тасок: всяким образом старался обходить такие вещи, потому что я всегда работаю с Celery как с чем-то, что может в какой-то момент повести себя непредсказуемо и делаю так, чтобы он выполнял не более одной задачи.