Hacker News Digest

FastAPI Voyager - это интерактивный инструмент визуализации для API, созданный на базе FastAPI. Позволяет наглядно представлять структуру API с возможностью масштабирования через прокрутку и детального изучения узлов двойным кликом. Особенность инструмента - режим просмотра зависимостей схемы (активируется через Shift+клик), который фильтрует несвязанные узлы, упрощая анализ сложных систем.

Проект поддерживает импорт данных JSON из ядра системы, что обеспечивает гибкость интеграции. Инструмент ориентирован на разработчиков, работающих с FastAPI, и помогает лучше понимать архитектуру API, выявлять связи между компонентами и оптимизировать структуру. Код проекта доступен на GitHub, что позволяет сообществу вносить вклад в развитие и адаптацию инструмента под конкретные нужды.

• Пользователи жалуются на неудобство визуализации сложных связей между эндпоинтами и моделями ответов в fastapi-voyager; требуется более интерактивный и «чистый» способ исследовать схему.
• Предложение: добавить взаимодействие при наведении курсора на узел, чтобы подсвечивать связанные с ним линии и скрывать остальные, а также дать возможность «проваливаться» внутрь подграфа.
• Пользователи просят улучшить UX: убрать «клубок» линий, дать возможность масштабировать и фильтровать отображаемое, а также предоставить обзорный режим, в котором детали раскрываются по мере необходимости.
• Проект вдохновлен GraphQL-voyager, но не реализует его фичи вроде подсветки связей при наведении мыши; автор отвечает, что проект на ранней стадии и приветствует PR-ы.

Автор создал высокопроизводительную систему продажи билетов TigerFans с использованием TigerBeetle, финансовой базы данных для транзакций. Система достигла показателя в 977 бронирований билетов в секунду, что в 15 раз быстрее, чем базовый показатель продажи билетов на концерт Oasis (65 билетов в секунду). Этот образовательный проект превратился в 19-дневный оптимизационный марафон, демонстрирующий потенциал TigerBeetle для решения задач с экстремальной нагрузкой.

В основе системы лежит модель двойной бухгалтерии, где билеты представлены как финансовые транзакции. Для каждого типа билетов создаются три счета: Operator (весь инвентарь), Budget (доступные к продаже) и Spent (проданные). Ключевая особенность — использование флага DEBITS_MUST_NOT_EXCEED_CREDITS, который архитектурно предотвращает перепродажу билетов. Реализация на Python с FastAPI, SQLite и симулированным платежным провайдером позволила создать рабочую демо-версию с двухфазным процессом оформления и автоматическим аннулированием просроченных резервирований.

Идея родилась из твита основателя TigerBeetle Joran Dirk Greef, который назвал создание такой системы "слишком простым". После демонстрации команды TigerBeetle, автор получил вызов — превзойти показатели продажи билетов Oasis. Это вдохновило на глубокую оптимизацию, доказав, что даже на Python можно достичь выдающейся производительности при правильной архитектурной основе.

• Продажа билетов на концерты часто создаёт иллюзию быстрой распродажи, но на деле билеты просто резервируются ботами и перепродажниками, а не покупаются.
• Tigerbeetle достигает высокой пропускной способности за счёт пакетной обработки транзакций, но при этом неясно, насколько это влияет на надёжность и устойчивость системы.
• Пользователи отмечают, что при использовании Tigerbeetle важно понимать, что применение его в системе продажи билетов не обязательно приведёт к улучшению UX, так как узким местом остаётся не транзакционная пропускная способность, а управление очередями и процессом покупки.

Python 3.14 представляет значительный прорыв для многопоточного Python, так как его "free-threaded" вариант достиг фазы II и больше не считается экспериментальным. Производительность улучшилась с 35% штрафом до всего 5-10%, а реализация теперь использует адаптивный интерпретатор без обходных решений из Python 3.13. Автор, разработчик веб-фреймворка и веб-сервера, провел сравнительное тестирование для веб-приложений, так как большинство существующих сервисов являются I/O-bound, а многопоточность критически важна.

Для тестирования были созданы ASGI-приложение на FastAPI и WSGI-приложение на Flask, каждый с двумя конечными точками: генератором JSON и имитацией I/O-операции с задержкой 10мс. Использовался сервер Granian, который работает с потоками вместо процессов, и инструмент rewrk для нагрузки. Цель - определить, можно ли наконец отказаться от гигабайтов памяти, тратимых на multiprocessing для параллельной обработки запросов в веб-сервисах.

• Появление free-threading в 3.13-3.14 сделало C-расширения, не обновлённые под free-threading, небезопасными и требует их обновления.
• Сообщество обсуждает, что отсутствие GIL в 3.14 может привести к тому, что старые библиотеки будут вести себя непредсказуемо, и предлагает, чтобы CPython поставлял инструмент для сканирования и обновления кода.
• Участники обсуждают, что влияние free-threading на производительность варьируется от «ничего не изменилось» до «значительно лучше» в зависимости от IO vs CPU bound кода, и что влияние на реальные приложения будет варьироваться от «ничего» до «значительно лучше».

Разработчики представили Hyperflask — новый фреймворк для Python, который объединяет множество инструментов в единую экосистему для ускорения разработки веб-приложений. Основная идея в том, чтобы избавить разработчиков от необходимости самостоятельно подбирать и настраивать различные технологии, которые часто требуются в проектах.

Hyperflask включает в себя множество готовых решений: от серверной логики на Flask до фронтенд-компонентов, маршрутизации, работы с формами и данными, а также инструментов для развертывания. Все компоненты тщательно подобраны для бесшовной совместной работы. Например, вместо самостоятельной настройки Flask с десятками расширений, разработчики получают единую среду, где всё "просто работает".

Ключевые возможности включают:

• Единая структура проекта: стандартизированная организация кода, что ускоряет onboarding новых разработчиков и упрощает поддержку.
• Готовые решения для типовых задач: аутентификация, отправка email, обработка файлов, фоновые задачи — всё доступно "из коробки".
• Гибридный рендеринг: статические страницы генерируются на сервере для скорости, но при необходимости могут динамически обновляться через HTMX.
• Оптимизация под SEO: серверный рендеринг гарантирует, что контент индексируется поисковыми системами.

Разработчики подчеркивают, что Hyperflask не просто набор инструментов, а целостная экосистема, где все части глубоко интегрированы. Это позволяет избежать типичных проблем, когда отдельные библиотеки, будучи собранными вручную, конфликтуют друг с другом.

Проект пока находится в стадии бета-тестирования, но уже доступен для использования. Основная команда состоит из разработчиков, ранее стоявших за популярными проектами в экосистеме Python, что говорит о серьезности намерений.

Для сообщества это может быть значимым, поскольку экосистема Python долгое время не имела полноценного аналога популярным JavaScript-фреймворкам вроде Next.js. Hyperflask, хоть и молодой проект, показывает важный шаг в этом направлении.

• Обсуждение в основном вращается вокруг сравнения Flask/HTMX-стека с альтернативами (FastAPI, Django, Litestar, FastHTML), где критика касается производительности, архитектуры и "state of the art" в 2025 году.
• Участники спорят о целесообразности смешивания шаблонов и логики в одном файле, о том, насколько это упрощает или усложняет разработку, и о том, как это сказывается на тестируемости и сопровождении кода.
• Ряд комментаторов поднимает вопрос о том, что выбор Flask в 2025 году может быть устарел, особенно если учесть отсутствие встроенной поддержки async/await, и сравнивает его с FastAPI или Litestar.
• Некоторые участники высказывают мнение, что вместо того, чтобы изобретать еще один каркас, было бы лучше взять существующий и внедрить в него улучшенную документацию, инструменты и лучшие практики.

Команда Wasmer анонсировала бета-поддержку Python в своей edge-платформе на базе WebAssembly. Это позволяет запускать популярные фреймворки вроде FastAPI, Django и Streamlit, а также библиотеки типа numpy и pandas — всё в песочнице с почти нативной производительностью. Ключевые улучшения включают динамическую линковку, поддержку сокетов, потоков и собственный индекс пакетов.

Производительность впечатляет: тесты показывают, что Python на Wasmer работает всего на 5% медленнее нативного, при этом обеспечивая изоляцию и портативность. Платформа уже обгоняет Cloudflare по поддержке мультитрединга и нативных модулей, а вскоре добавит полную поддержку PyTorch и других тяжёлых библиотек.

• Запуск Python в WebAssembly через Wasmer предлагает производительность, близкую к нативной, и обеспечивает надежную песочницу для выполнения кода.
• Обсуждаются практические применения: встраивание скриптов в приложения, серверные API (FastAPI, Django) и выполнение пользовательского кода в изоляции.
• Поднимаются вопросы о поддержке ключевых библиотек (numpy), асинхронности (asyncio) и межъязыкового взаимодействия (Python-JS).
• Отмечаются существующие альтернативы (Pyodide, контейнеры) и сложности с зависимостями, имеющими нативные расширения.
• WASM рассматривается как более простая и легковесная альтернатива виртуальным машинам и контейнерам для развертывания.

spaCy — промышленная библиотека NLP на Python.
Быстрая, точная, поддерживает 70+ языков.

Основное

• Установка

  pip install -U spacy
  python -m spacy download en_core_web_sm
  

• Быстрый старт

  import spacy
  nlp = spacy.load("en_core_web_sm")
  doc = nlp("Apple is looking at buying U.K. startup for $1 billion")
  for ent in doc.ents:
      print(ent.text, ent.label_)
  

Возможности

• токенизация, POS-теги, синтаксис, NER
• готовые модели CNN/Transformer
• обучение и дообучение
• интеграция с PyTorch, Transformers, FastAPI
• GPU/Apple Metal

Примеры

• NER: выделение имён, дат, денег
• Matcher: поиск паттернов
• Projects: end-to-end пайплайны
• spaCy LLM: LLM-интеграция без кода

Ресурсы

• Документация
• Интерактивный курс
• Демо
• Discord

• В эпоху LLM традиционный NLP (SpaCy) всё ещё нужен: дешевле, быстрее, работает на обычном железе и не требует постоянной оплаты провайдеру.
• Участники хвалят SpaCy за отличный API, скорость, надёжность NER и удобство пайплайнов; активно используют в enterprise, RAG-метриках и даже на Raspberry Pi.
• Некоторые задачи (классификация, сентимент) LLM решают хуже и дороже, поэтому возвращаются к дискриминативным моделям.
• Сообщество отмечает, что проект немного сократился (v4 задерживается), но библиотека по-прежнему поддерживается и считается недооценённой.

Whispering — микросервис в репозитории epicenter-so/epicenter, каталог apps/whispering.
Предназначен для быстрого распознавания речи через OpenAI Whisper: принимает аудио-файл, возвращает текст.

Ключевые файлы

• main.py — FastAPI-endpoint /transcribe (POST, multipart/form-data).
• requirements.txt — fastapi, uvicorn, openai-whisper.
• Dockerfile — лёгкий образ на python:3.11-slim, порт 8000.

Запуск

docker build -t whispering .
docker run -p 8000:8000 whispering

или

pip install -r requirements.txt
uvicorn main:app --host 0.0.0.0 --port 8000

Использование

curl -F "file=@audio.mp3" http://localhost:8000/transcribe

Ответ: {"text": "распознанный текст"}.

• Пользователи делятся «костыльными», но рабочими схемами диктовки на Linux и обсуждают, как локально запускать Whisper/Parakeet без облаков.
• Epicenter продвигает идею «local-first»: plaintext + SQLite, прозрачные данные, открытый код, совместимые инструменты.
• Постоянно сравнивают альтернативы (VoiceInk, Superwhisper, Wispr Flow, Willow, whishper, Vibe) и жалуются на подписки, задержки, качество и отсутствие разметки динамиков.
• Разработчик Epicenter уже добавляет whisper.cpp и планирует Parakeet; просит помощи в PR для ускорения.

Основы

• Определите цель: чётко сформулируйте задачу перед генерацией кода.
• Начинайте с README: описание проекта помогает ИИ и команде.
• Используйте шаблоны: готовые структуры (FastAPI, React) экономят время.

Промпты

• Контекст: указывайте язык, фреймворк, стиль (PEP8, camelCase).
• Мелкие задачи: дробите фичи на куски по 50–100 строк.
• Примеры: прикладывайте JSON-ответы или SQL-запросы.
• Итерации: улучшайте код по одному аспекту за раз.

Рабочий процесс

• Сессии: 30-минутные циклы «запрос-ревью-запуск».
• Git-коммиты после каждого шага для отката.
• Линтеры/тесты сразу: pytest, eslint, mypy.
• Code Review: проверяйте всё, даже «очевидное».

Инструменты

• Copilot Chat в IDE для быстрых правок.
• Cursor / Windsurf для многофайлового рефакторинга.
• Playwright для e2e-спек, сгенерированных из текста.
• Docker для воспроизводимого окружения.

Качество

• Типы: добавляйте аннотации (TypedDict, Pydantic).
• Док-строки: пишите для всех публичных функций.
• Тесты: покрывайте критические пути ≥80 %.
• Логи: структурированные (structlog) для отладки.

Безопасность

• Секреты: проверяйте .env и git history.
• OWASP Top 10: сканируйте зависимости (pip-audit, npm audit).
• RBAC: реализуйте роли и разрешения сразу.

Производительность

• Профилирование: cProfile, py-spy для горячих точек.
• Кеш: Redis для частых запросов.
• CDN для статики фронтенда.

Деплой

• CI/CD: GitHub Actions → Docker → ECS/Fargate.
• Feature flags для постепенного релиза.
• Мониторинг: CloudWatch + Grafana.

Советы

• Не доверяйте 100 %: всегда читайте сгенерированный код.
• Учитесь у ИИ: спрашивайте «почему так» для роста навыков.

• Подавляющее большинство участников считает «vibe-coding» либо вредным, либо вообще не тем, что описано в документе.
• Настоящий vibe-coding — это «не смотреть код, а принимать результат, если визуально работает»; любые советы «тщательно читайте код» противоречат самому термину.
• Многие предпочитают писать чёткие спецификации и использовать LLM как «парного программиста», но подчёркивают, что это уже не «vibe», а обычная работа с AI.
• Частый риск — накопление непонятного, неотрефакторенного кода и «отравление» контекста при изменении требований.
• Итоговый совет большинства: «Don’t go full vibe» — даже при активном использовании LLM нужно понимать и контролировать результат.

• Добавлена поддержка моделей Mistral-Small-3.1-24B-Instruct-2503 и Mistral-Small-24B-Instruct-2501
• Улучшена работа с Mamba-2 и Sliding Window Attention
• Новые правила конвертации: convert-hf-to-gguf.py теперь корректно обрабатывает sliding_window, mamba2, attention_bias, tie_word_embeddings
• Обновлён llama_model_loader и llama_model: добавлены поля mamba2 и sliding_window, упрощена логика KV-cache
• Поддержка mamba2 в llama_context и llama_decode
• Удалены устаревшие llama_model и llama_vocab
• Добавлены тесты test-mistral.py и test-mistral-vision.py

• Mistral предлагает mistral-common как официальный токенизатор, но пока только через Python-библиотеку и временный REST-обвязанный FastAPI.
• Сообщество жалуется: «cpp-бинарь, зависящий от Python-сервера — временное и грустное решение», ждут нативный C++ порт.
• Пользователи расстроены, что Mistral, выпуская веса, не сразу поддерживает llama.cpp, на котором держится большинство «домашних» запусков.
• Некоторые замечают, что llama.cpp и так тянет Python для шаблонов, но это не отменяет желания увидеть полноценную C++ реализацию.
• Сторонники Mistral отвечают: компания маленькая, пока не ясно, какие именно инференс-фреймворки поддерживать, зато открыли собственный mistral-inference.

• Несколько лет назад мне выпал шанс выбрать async‑first, типизированный Python‑фреймворк для веба. Я взял Litestar — без хайпа и ракет в твитах — и не пожалел: уже около 18 месяцев все мои новые рабочие проекты на нём.

• Даже если вы пишете асинхронные веб‑приложения на Python, вы могли пройти мимо Litestar. Хочу это исправить.

• Вкус демо: простой файл

  from litestar import Litestar, get
  
  @get("/greet")
  async def greet(name: str) -> str:
      return f"Hi, {name}!"
  
  app = Litestar([greet])
  

  Запускаете через litestar run или любой ASGI‑сервер. /greet?name=Bob вернёт «Hi, Bob!». Без name — HTTP 400: параметр обязателен. Да, похоже на FastAPI и на знакомые по Spring/ASP.NET MVC подходы с аннотациями — и FastAPI тоже так умеет. Но у Litestar есть свои сильные стороны.

• Про название: раньше проект назывался Starlite, потому что изначально строился на Starlette (как и FastAPI). Позже зависимость убрали, а чтобы не путать со Starlette, в релизе 2.0 (2023) переименовали в Litestar.

• Масштабирование кода, а не трафика:

  • Django плохо «масштабируется вниз»: «правильный» старт быстро разрастается в десяток файлов и папок. Однофайловые трюки работают, но против шерсти.
  • Микрофреймворки — наоборот: стартуют в одном файле, но по мере роста кода расползаются и начинают мешать.
  • В FastAPI маршруты обычно вешаются декораторами на объект приложения. Это удобно в одном файле, но при разбиении на модули ведёт к циклическим импортам. Решение — «вторичные» реестры маршрутов (APIRouter, blueprint): нужны, потому что декораторы привязаны к app. Litestar же позволяет описывать обработчики отдельно и передавать их приложению списком, что естественно масштабируется от одного файла к структуре проекта без костылей.

• Обсуждение сравнивает FastAPI, Litestar, Starlette и Django для построения бекендов: многие отмечают, что FastAPI удобен для простых сервисов, но усложняется в больших кодовых базах, тогда как Litestar воспринимается более продуманным и быстрым для сложных API.
• Несколько участников хвалят Litestar: высокая скорость, асинхронность, first-class msgspec, контроллеры для вложенных роутов, кеширование, плагины (в т.ч. для HTMX), и развивающийся Advanced Alchemy; отмечают, что у него больше одного мейнтейнера.
• Часть разработчиков предпочитает Starlette как легковесную основу без «всей кухни», а Django ценят за ORM; обсуждают плюсы/минусы SQLAlchemy и альтернативы (peewee), а также идею разделять модели API и БД с самого начала.
• Критика FastAPI касается структуры кода, управления зависимостями и разрыва между туториалами и реальными практиками; при этом приводят ссылки на репозитории-референсы, где показано, как масштабировать FastAPI.
• Запросы и сомнения: как обрабатывать ошибки при стриминге, как деплоить (NGINX Unit упоминался как «капризный»), и нужен ли референс-проект Litestar; приводят litestar-fullstack как пример.
• В целом тон дискуссии: многие либо мигрируют с FastAPI на Litestar, либо довольны Starlette; документацию нового поколения фреймворков часто критикуют за недостаток строгого API-референса и переизбыток туториалов.