Артём Шумейко

Новый HTTP-метод. 0_о ЧТоОоО?? Все уже давно привыкли к GET, POST, PUT, DELETE и прочим ребятам, как вдруг решили добавить новый метод QUERY! Это не шутка если что. Вот официальный RFC двухнедельной давности. Кому лень читать, кратенько объясню проблематику и почему это классный метод стоит юзать в будущем. Очень часто в GET запросах хочется передать туеву хучу параметров, например, для фильтров, сортировки, поискового запроса и прочих параметров. Но! Во-первых, длина URL часто ограничена веб-серверами и браузерами. Во-вторых, это просто тупо неудобно для разработчиков и тестировщиков. Поэтому многие разработчики для запросов, которые должны просто отдавать данные (то есть по семантике должен был быть GET) делали POST, так как в нем можно напихать бо́льшее количество параметров в удобном джейсончике. Что теперь? Новый метод QUERY совместил часть семантики GET: кэшируемость, идемпотентность, и то что данные не изменяются на сервере, но разрешил прикреплять тело запроса как в POST. Ура! Спустя 30 лет решили пофиксить баг)) Минусы: - параметры реже будут логироваться большинством систем (тяжелее расследовать инциденты) Плюсы: - параметры реже будут логироваться большинством систем (логи будут весить меньше) Большинство фреймворков, прокси и браузеров еще не адаптировали этот метод, но зато можно пойти похвастаться знакомому разработчику, что он знает не все методы, а ты — все)

ПОСЛЕДНИЙ ДЕНЬ НАБОРА НА КУРС Сегодня в 23:59 по МСК закрываю набор учеников на курс по параллелизму и конкурентности в Python. Курс для тебя, если ты: — Уже работаешь Python-разработчиком, но чувствуешь, что знания по async заканчиваются на async/await и gather — Хочешь увереннее проходить собеседования на Middle/Senior позиции, где спрашивают event loop, GIL, потоки, процессы, очереди и продакшен-кейсы — Работаешь с FastAPI, aiohttp или другими асинхронными технологиями и хочешь понимать, что происходит под капотом — Хочешь разобраться, как строить высоконагруженные распределенные приложения, которые не тормозят и не падают  На курсе мы будем разбирать и чинить полноценный продакшен-проект сервиса доставки продуктов. Проблемы, которые ты научишься решать: 1️⃣ Как обрабатывать timeout, retry, rate limit и нестабильные внешние сервисы 2️⃣ Как бороться с cache stampede и координировать несколько воркеров через Redis 3️⃣ Как безопасно обновлять токены и синхронизировать состояние между инстансами приложения 4️⃣ Как встраивать синхронный код и сторонние SDK в async-приложение через to_thread 5️⃣ Как строить фоновые процессы через TaskIQ/Celery и не терять данные 6️⃣ Как организовать batching через asyncio.Queue и снижать нагрузку на БД 7️⃣ Как обрабатывать большие потоки событий через Kafka, FastStream и WebSocket 8️⃣ Как реализовывать backpressure и не утонуть под нагрузкой 9️⃣ Как искать event loop lag, slow callbacks и другие проблемы производительности 🔟 Как строить нормальное логирование через contextvars и отслеживать запросы в асинхронном приложении 🔢… и еще многое другое Главный принцип курса — максимум практики, приближенной к продакшену. Я специально собирал программу вокруг реальных задач, которые встречаются в современных Python-проектах, чтобы после курса ты открывал вакансию и понимал что знаешь о чём там написано, не плыл на собесе когда спрашивают про корутины или батчинг аналитики, и мог куски кода утащить прямо в свой рабочий проект. ➡️ Последний день, чтобы ПОПАСТЬ НА КУРС

Похоже, места на курсе по параллелизму постепенно заканчиваются И уже в понедельник, 29 июня в 19:00 МСК, мы проводим первую онлайн-встречу с участниками курса. Познакомимся, обсудим программу, проект, домашки, формат обучения и вообще поймём, кто все эти люди, которые добровольно решили разбираться с конкурентностью, дедлоками и Kafka 😇 Кстати, на картинке почти реальный состав созвона) Если ты всё ещё в раздумьях, стоит ли идти на курс, сейчас самое время задать все вопросы. Напиши в @artem_shumeiko_support, расскажем про программу, формат, домашки, нагрузку и поможем понять, подойдёт ли курс именно тебе

Разбираем тестовое задание для Junior Python Backend разработчика 👉 Новое видео: YouTube | VK | Rutube В новом видео вместе спроектируем API и структуру базы данных, обсудим, как правильно хранить секретные данные, чем отличаются хеширование, шифрование и кодирование, а затем реализуем решение на Python с использованием асинхронности и PostgreSQL. Также поговорим о типичных ошибках, которые допускают начинающие разработчики, разберем производительность хеширования паролей, особенности работы с базой данных и в конце я дам рекомендации, как можно доработать проект

А хватит ли мне скилов на курс? Периодически получаю вопросы по типу "блин, а точно ли мне хватит текущих навыков? может сначала ещё подтянуть что-то?" Давай нормально разложу) Для старта тебе нужно иметь минимальный опыт работы с FastAPI, PostgeSQL и Git. Все это осваивается достаточно быстро и это единственные минимальные знания, которые нужны для курса Не нужно заранее идеально знать async, потоки, процессы или Kafka, как раз это ты и будешь изучать на курсе. Если у тебя уже есть опыт в разработке, на курсе будешь чувствовать себя комфортно. HTTP, базы данных, очереди, API, кэш, скорее всего ты уже с этим сталкивался, а на курсе начнёшь глубже понимать как всё это работает под нагрузкой и в проде. Если с Redis, Kafka, TaskIQ, вебсокетами или мультипроцессингом раньше не работал, вообще не проблема. Мы всё это разбираем постепенно на одном большом проекте. Самое тяжёлое на курсе — объём и интенсивность. Информации и практики будет много, так как придётся писать код, думать, разбираться, задавать вопросы, но это и даёт быстрый рост. Плюс у тебя будет чат, Q&A созвоны, фидбек по домашкам от меня, разборы решений и поддержка по любым вопросам. В общем, если у тебя есть минимальный опыт использования асинхронности и написания REST API, тебе точно можно присоединяться к обучению. Не жди идеальной готовности, её не бывает) ПРИСОЕДИНИТЬСЯ К КУРСУ Какие еще вопросы волнуют? Пиши в комменты)

Куда деть CPU код: костылить в текущем проекте или пилить отдельный микросервис Этим вопросом часто задаются разработчики, когда на работе прилетает таска по типу "создать код по обработке файла/созданию отчета". Сразу скажу: однозначного ответа нет, всё зависит от количества и частоты CPU нагрузки, специфики проекта, и готова ли команда потянуть еще один микросервис) Давайте рассмотрим реалистичную ситуацию, когда у нас ограничены ресурсы, и мы не хотим клепать микросервисы просто ради красоты. Часто бывает такое, что ты пилишь сервис, который в основном ходит в базу/кэш, читает из брокера и делает сетевые запросы, а продакт просит запилить новую фичу с генерацией отчетов для клиентов. Первая логичная мысль: так, это CPU нагрузка, а мое приложение асинхронное, значит вынесу в отдельный сервис. Но это может быть сильно поспешное решение, которое будет тяжелее поддерживать. Если: — тяжелая операция запускается редко, например, пару раз в минуту — CPU нагрузка короткая, например, 3-5 секунд и отчет готов — у вас и так небольшая нагрузка на сервис (до 10 RPS) ... то можно вынести такой код в поток (если он отпускает GIL), процесс (если GIL не отпускается), очередь Celery/TaskIQ (особенно если генерацию отчета можно чуть отложить) И для этого совсем не нужно костылить или придумывать велосипед. За нас давно все сделали. В библиотеке asyncio уже есть встроенные способы запуска кода во внешнем потоке или процессе. Вынесение в поток: import asyncio async def generate_report(report_id: int) -> str: file_path = await asyncio.to_thread( sync_make_report, report_id, ) return file_path Вынесение в процесс: import asyncio from concurrent.futures import ProcessPoolExecutor process_pool = ProcessPoolExecutor(max_workers=4) async def generate_report(report_id: int) -> str: loop = asyncio.get_running_loop() file_path = await loop.run_in_executor( process_pool, sync_make_report, report_id, ) return file_path На открытом уроке кстати рассказывал, в чем разница встроенных модулей threading, multiprocessing и concurrent.futures и что лучше использовать. Если хочешь принимать верные архитектурные решения в своих проектах, то приходи на мой авторский курс по конкурентности и параллелизму в Python. На нем разберем реальные проблемы, которые не каждый разработчик сможет заметить и решить. Начинаем уже 30 июня! Если возникают вопросы по курсу, пиши в @artem_shumeiko_support

Как выглядит продакшен-проект на курсе Я записал отдельный видеообзор проекта и показал всю архитектуру целиком. На курсе мы будем исследовать и чинить систему доставки продуктов, внутри которой собраны реальные сценарии возможных проблем при большой нагрузке. Что будет внутри проекта: - Параллельные запросы во внешние API через gather и TaskGroup - Работа с aiohttp, таймаутами, retry и ограничением нагрузки на внешние сервисы - Redis-кэш, distributed lock и защита от cache stampede - Координация нескольких FastAPI-инстансов через Redis - TaskIQ и Celery для фоновой обработки заказов - Интеграция синхронного кода в async-приложение через to_thread - Kafka, WebSockets и поток геопозиций курьеров в реальном времени - Батчинг через asyncio.Queue и снижение нагрузки на базу - ProcessPoolExecutor для CPU-bound задач - Поиск блокировок event loop, profiling и диагностика проблем производительности - Логирование с contextvars и request_id При этом ты будешь изучать инструменты не по отдельности, а в контексте проблем, которые возникают в продакшене: почему растёт память, откуда берётся event loop lag, как не положить внешний API, зачем нужны distributed lock'и и что происходит, когда приложение работает в нескольких воркерах одновременно. Через 5 дней набор на курс закрывается и мы начинаем учёбу, поэтому не упускай возможность выбирай тариф на сайте По всем вопросам пиши в @artem_shumeiko_support, мы поможем

5 мифов про асинхронность, в которые верят разработчики 👉 Новое видео: YouTube | VK | Rutube В этом видео разбираю популярные мифы об асинхронности в Python и показываю на примерах, почему async/await не является панацеей. Поговорим о том: 🟢Почему await сам по себе не ускоряет выполнение функции 🟢Где на самом деле могут находиться узкие места приложения 🟢Почему последовательный await часто убивает производительность 🟢Как синхронный код незаметно блокирует event loop 🟢В каких случаях await может запускать код в отдельном потоке

Как перестать откладывать развитие и расти параллельно с работой? Один из самых частых вопросов по новому курсу — реально ли совмещать его с работой. Отвечаю: да, вполне) По нагрузке я бы ориентировался примерно на 10–12 часов в неделю, которые будут уходить на уроки + домашки + Q&A-созвоны. Но тут всё зависит от твоего опыта. Если ты уже работал с FastAPI, Redis, или async — часть тем пройдёшь быстрее. Если какие-то инструменты видишь впервые, времени понадобится чуть больше. Поэтому у всех темп будет разный: кому-то хватит 8 часов, кому-то понадобится 15. Все материалы остаются в записи, поэтому учиться можно в удобное время: вечером после работы, утром, по выходным, как комфортно именно тебе. Домашки потребуют времени и нормального погружения, потому что курс построен вокруг production-like задач, но зато после практики рабочие задачи будут решаться быстро. Самое главное это регулярность. Даже 1–2 часа в день лучше, чем редкие попытки "сесть на 10 часов в воскресенье", плюс так выработается привычка и курс пойдет гораздо легче. При этом курс не привязан к жёсткому темпу. Доступ к материалам остаётся на год, а на тарифе с проверкой на 2 года, плюс есть возможность сдавать домашки в течение месяца после окончания курса, поэтому можно спокойно возвращаться к сложным темам, пересматривать уроки и добивать домашки в своём ритме.  Так что в плане нагрузки совмещение с работой реально. Да, нужно выделить время и возможно какие-то занятия сдвинуть на задний план на пару месяцев, но от этого еще никто умирал) Если ты ищешь ссылку на курс, оставляю ее ниже 👇 ЗАПИСАТЬСЯ НА КУРС Если есть вопросы по курсу, пиши в @artem_shumeiko_support

Видео специально для тех, кто спрашивал, что такое мьютексы) Параллелизм в Python