Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
ByteDance выпустила Seedream 5.0 pro
ByteDance выпустила Seedream 5.0 pro — генератор изображений с послойным редактированием прямо внутри интерфейса.
Ключевая фича: выделяешь объект — он уходит на отдельный слой, двигаешь и масштабируешь независимо. Пустую зону можно дозаполнить промтом. Текст на изображениях без глитчей — нативно.
Для арбитражников это может быть удобным инструме…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-vypustila-seedream-5-0-pro
🧠 Ещё больше инсайтов → в канале AFF.top
ByteDance выпустила Seedream 5.0 pro — генератор изображений с послойным редактированием прямо внутри интерфейса.
Ключевая фича: выделяешь объект — он уходит на отдельный слой, двигаешь и масштабируешь независимо. Пустую зону можно дозаполнить промтом. Текст на изображениях без глитчей — нативно.
Для арбитражников это может быть удобным инструме…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-vypustila-seedream-5-0-pro
🧠 Ещё больше инсайтов → в канале AFF.top
Starlette: почему быстрый ASGI-фреймворк ломается не на коде, а на обвязке
Starlette часто берут ради скорости и простоты, но в проде проблемы обычно не в роутинге. Ломается всё вокруг: middleware, фоновые задачи, обработка ошибок, проксирование и то, как вы собираете ответы.
Есть наблюдение которое стоит проверить: если проект на Starlette «вдруг стал сложным», значит вы уже нарастили поверх него мини-Django без дисциплины. Чтобы не утонуть:
• держите бизнес-логику вне эндпоинтов
• не прячьте ошибки в middleware
• явно разделяйте sync и async границы
• не передавайте сырые request/response глубоко в сервисы
Отдельно следите за жизненным циклом приложения. Инициализация клиентов, пулов и кэшей должна быть в startup/lifespan, а не в первом запросе. Иначе вы получаете странные задержки, гонки и «магические» падения под нагрузкой. Для фоновки лучше использовать очередь или отдельный воркер, а не надеяться, что request уже ушёл и всё само доедет.
Если нужен тонкий HTTP-сервис, Starlette хорош как каркас. Но как только появляются авторизация, схемы, валидация и админка — заранее решите, где заканчивается фреймворк и начинается ваш слой приложения. Иначе экономия на старте превращается в дорогую переделку позже.
Starlette часто берут ради скорости и простоты, но в проде проблемы обычно не в роутинге. Ломается всё вокруг: middleware, фоновые задачи, обработка ошибок, проксирование и то, как вы собираете ответы.
Есть наблюдение которое стоит проверить: если проект на Starlette «вдруг стал сложным», значит вы уже нарастили поверх него мини-Django без дисциплины. Чтобы не утонуть:
• держите бизнес-логику вне эндпоинтов
• не прячьте ошибки в middleware
• явно разделяйте sync и async границы
• не передавайте сырые request/response глубоко в сервисы
Отдельно следите за жизненным циклом приложения. Инициализация клиентов, пулов и кэшей должна быть в startup/lifespan, а не в первом запросе. Иначе вы получаете странные задержки, гонки и «магические» падения под нагрузкой. Для фоновки лучше использовать очередь или отдельный воркер, а не надеяться, что request уже ушёл и всё само доедет.
Если нужен тонкий HTTP-сервис, Starlette хорош как каркас. Но как только появляются авторизация, схемы, валидация и админка — заранее решите, где заканчивается фреймворк и начинается ваш слой приложения. Иначе экономия на старте превращается в дорогую переделку позже.