Серия «Библиотке Питона»

Зачем это ебашить?

✅ Для прототипов — накидал роутов за 5 минут и уже что-то работает.
✅ Для мелких сервисов — если твой API проще, чем калькулятор.
✅ Чтобы почувствовать себя богом бэкенда (пока не поймёшь, что без доп.либ это говно, а не фреймворк).

Где Flask сосёт?

1. Роутинг — если у тебя больше 10 эндпоинтов, это уже ад из декораторов.

2. ORM — SQLAlchemy? Peewee? Да хуй знает, подключай сам, Flask похуй.

3. Асинхронность — её нет. Хочешь async/await? Иди нахуй, это же «микро» фреймворк.

Пример кода (чтобы ты понял, насколько это убого):

Что не так?
— Нет валидации (прилетело ?id=undefined? Похуй).
— Нет асинхронности (10 запросов одновременно? Лагает).
— Нормальной документации нет (RTFM? Это же Flask, тут всё «очевидно»).

Когда Flask — это пиздец?

❌ Если твой API больше, чем «привет-мир».
❌ Если нужна встроенная безопасность (Flask скажет: «Ну сам допиши»).
❌ Если хочешь modern features (типа GraphQL или gRPC).

Вывод

Flask — это велосипед без колёс.
Хочешь быстро? Берёшь.
Хочешь scalable? Иди на FastAPI или Djangо

ЕБАШИМ КОД ЗДЕСЬ!!!

FastAPI это как тип который говорт "Да не ссы ты,ща нормально всё будет..", а потом кидает 500-страничную документацию с примерами на async/await.

Зачем это нужно?

1. Чтобы не ебаться с Flask
— Встроенная валидация (но если ваш JSON сложнее «name: str», готовьтесь к схемам-монстрам).
— Автодокументация (Swagger, который фронтендеры всё равно игнорят).
— Асинхронность (но если вы не знаете, чем async def отличается от def — вам пиздец).

2. Чтобы бот не падал от первого же запроса
— Валидация на входе (но если заказчик пришлёт "price": "две сотни", вы всё равно получите 422 Unprocessable Entity).
— Логирование (чтобы видеть, как ваш сервер агонизирует в реальном времени).

3. Чтобы выглядеть круто на собеседовании
— «Да, я работал с FastAPI» → «О, вы знаете Pydantic?» → паника.

Когда использовать?

✅ Если ваш API сложнее «привет, мир» (но проще, чем нейросеть для распознавания котиков).
✅ Если хотите автоматическую документацию (на которую всем похуй).
✅ Если готовы к тому, что async/await — это не просто модные слова.

Когда НЕ использовать?

❌ Если ваш API — это одна ручка GET /hello.
❌ Если вы думаете, что «быстро» значит «не надо разбираться».
❌ Если боитесь слова «Dependency Injection».

Пример кода (чтобы вы почувствовали разрыв шаблона):

Что здесь может пойти не так?
— price: float, а вам пришлют "price": "десять рублей" → 422.
— Забудете async → ошибка, но не сразу (спасибо, Python).
— Решите подключить SQLAlchemy → привет, асинхронный ад.

Вывод

FastAPI — это мощно, но:
— Гуглить придётся много.
— Ошибки будут обидные.
— Мысль «нафиг это надо» посетит вас минимум раз.

Разработка без цензуры у меня в тг-канале

Это асинхронный ад

Библиотека для асинхронных HTTP-запросов, написанная для мазохистов, которые считают, что requests — это слишком просто. Если requests — это велосипед, то aiohttp — это велосипед с квадратными колёсами, который едет только в гору.

Зачем это нужно?
— Чтобы делать 100500 запросов одновременно (и получить 100500 ошибок одновременно).
— Чтобы гордо сказать: «Я пишу на асинхронном коде!» (а потом три дня дебажить RuntimeError: Event loop is closed).
— Чтобы понять, что asyncio — это не библиотека, а образ жизни (и боли).

Когда использовать?
✅ Если вам действительно нужно 10к RPS (но ваш сервер сдохнет на 500).
✅ Если вы любите разбираться в async/await (и ненавидите свою жизнь).
✅ Если requests кажется вам слишком стабильным и предсказуемым.

Когда НЕ использовать?
❌ Если вы думаете, что асинхронность — это «просто добавить async перед функцией».
❌ Если ваш код уже работает (и вам незачем его ломать).
❌ Если у вас аллергия на ошибки типа «aiohttp.client_exceptions.ServerDisconnectedError».

Пример кода (который сломается при первом же запуске)

Что может пойти не так?

🔹 Сервер не отвечает? Получай TimeoutError и сиди гадай, то ли сервер сдох, то ли DNS сломался.
🔹 Сессия закрылась раньше времени? Наслаждайся ClientSession is closed.
🔹 Слишком много запросов? Добро пожаловать в мир aiohttp.client_exceptions.TooManyRedirects.
🔹 SSL-сертификат кривой? Привет, aiohttp.client_exceptions.ClientConnectorCertificateError.

Вывод

aiohttp — это мощно, быстро и… очень больно. Если requests — это «пострелял из пистолета», то aiohttp — это «запустил ракету с заднего двора и надеешься, что она не упадёт тебе на голову».

Совет: Прежде чем лезть в aiohttp, выучи asyncio настолько, чтобы объяснить его пьяному другу в 3 часа ночи. Иначе будет очень грустно.

Хочешь разбор реальных кейсов? Залетай в канал, там мы пилим всяких ботов...

Зачем это нужно?
— Чтобы не писать urllib.request.urlopen(url).read().decode('utf-8') и не чувствовать себя археологом.
— Чтобы отправлять GET/POST запросы одной строкой (а ошибки разбирать десятью).
— Чтобы работать с API и верить, что документация не врет (спойлер: врет).

Когда использовать?
✅ Нужно быстро что-то запросить с API (и надеяться, что оно ответит).
✅ Парсите сайт (пока он не начал парсить вас).
✅ Хотите человеческий интерфейс (но смиритесь, что интернет — место нечеловеческое).

Когда НЕ использовать?
❌ Нужна асинхронность (aiohttp или httpx вам в помощь).
❌ High-load (блокирующие запросы = тормоза).
❌ Если боитесь внезапных ConnectionError, Timeout и "а где мой JSON?".

Пример кода (работает... обычно):

Что может пойти не так?
— API передумало отвечать (404, 429, 500...).
— SSL-сертификат "самопальный" (SSLError).
— В ответе HTML вместо JSON (привет, json.decoder.JSONDecodeError).
— Прокся перестала работать (тишина и ConnectionError).

Вывод
requests — это просто и удобно, пока интернет играет по правилам. А если нет — ну, хотя бы ошибки читаемые.

P.S. Хотите гайд по выживанию с API? Заходите в наш тг-канал — там есть всё: от GET /hello до "почему Cloudflare меня ненавидит".

Что это:
Официальная библиотека для Telegram-ботов на Python. Если бы она была человеком — это был бы ваш старший брат, который постоянно говорит «я же предупреждал», когда вы накосячите.

Зачем это нужно?

1. Чтобы не ебаться с сырым Telegram API
   — Встроенные хендлеры, клавиатуры, FSM (машина состояний, которая всё равно вас запутает).
   — Асинхронность (но если вы не знаете, что это — идите учить asyncio).

2. Чтобы бот не падал от первого же исключения
   — Есть встроенная обработка ошибок (но если вы напишете кривой код — он всё равно сдохнет).
   — Можно настроить логирование (чтобы красиво плакать в консоль).

3. Чтобы заказчик не приставал с дурацкими вопросами
   — «Почему бот не отвечает?» → «Это лимиты Telegram, читайте доку» (но ему всё равно похуй).

Когда использовать?

✅ Если вы делаете бота для денег (а не для «портфолио»).
✅ Если не хотите разбираться в тонкостях Telegram API (но всё равно придётся).
✅ Если готовы к тому, что документация написана для тех, кто уже в теме.

Когда НЕ использовать?

❌ Если ваш бот — это «привет, как дела?» (берите telebot, не усложняйте).
❌ Если вы не умеете в async/await (aiogram вас добьёт).
❌ Если думаете, что бот будет работать «из коробки» (ха-ха, нет).

Пример кода (чтобы вы почувствовали боль):

Что здесь может пойти не так?
— Токен неверный → бот молчит.
— Забыли импортировать Command → ошибка.
— Сервер Telegram упал → бот умер.

Вывод

Aiogram — это мощно, но если вы новичок, приготовьтесь к:

1. Гуглению (очень много гугления).

2. Ошибкам (очень много ошибок).

3. Мысли «нафиг это надо» (но потом вы привыкнете).

Хотите разбор реальных кейсов? Залетайте в канал!))

Если хотите такой же разбор, но про другую технологию — пишите в комменты.