раскрыть ветку (45)
раскрыть ветку (8)
раскрыть ветку (6)
А если на ней на Сахалине работать? Там год за 2. Программа 1,5 года существует, а опыта, считай, уже 3
раскрыть ветку (1)
Там больше букв и три капсом. Есть слово API в названии. С этим словом пиздатость технологии возрастает в 2 раза
раскрыть ветку (11)
раскрыть ветку (8)
раскрыть ветку (2)
А если писать заглавные и прописные буквы последовательно, то можно сказать что технология работает с 2007г.
раскрыть ветку (1)
Нашел блог-пост:
https://towardsdatascience.com/why-we-switched-from-flask-to...
FastAPI более минималистичен, ставит меньше условий для архитектуры кода, имеет встроенную асинхронность.
раскрыть ветку (4)
Из моего небольшого опыта, FastAPI позволяет создавать схемы запросов и проверять входящие запросы на соответствие. Также очень удобно формируется автоматическая документация а сваггер формате.
раскрыть ветку (3)
раскрыть ветку (10)
Не очевидно вот совсем. Асинхронные решения чаще всего медленнее, если используют тот же уровень абстракций.
раскрыть ветку (9)
раскрыть ветку (8)
раскрыть ветку (7)
раскрыть ветку (5)
В большинстве случаев вполне себе подходит, т.к. ввода-вывода там предостаточно. Начиная от обработки запросов через сеть, запросов в БД, заканчивая всякими кэшами, логами и пр.
раскрыть ветку (3)
Это значит лишь что инструмент гранично пригоден, но стоит сравнивать с синхронным аналогом. И синхронные аналоги как правило выигрывают, например при наличии бизнес-логики. Которую, внезапно, иногда (а, точнее, практически всегда) приходится отлаживать.
раскрыть ветку (2)
По-первых, слово "подходит" как раз содержит смысл применимости инструмента.
Во-вторых, уточните, пожалуйста, в каких таких условиях и под какой нагрузкой плодить потоки дешевле, чем распределять задачи по существующим?
Пруфани бенчмарками, где асинхронный хттп сервер, который просто хотя-бы plain текст выдаёт проигрывает синхронному, я уже промолчу про "бизнес логику".
Что ты щас написал? Асинхрон не для http сервера? Т.е. условные пару десятков тысяч запросов, и все твои нативные потоки замирают? Или 1 поток 99%, а остальные идлят?
Единственное что я нашел за пару часов с технологией - uvicorn vs gunicorn, то бишь asgi vs wsgi. А так, лучше уж про старой методике пока, не хочу хаками пользоваться
раскрыть ветку (7)
И все? Асинхронность? Ну и нахуй она нужна с балансировкой и прочим? Ну хотя в домашних проектах полезно достаточно.
раскрыть ветку (6)
Из разных источников данные тянуть асинхронно всяко быстрее, чем последовательно. Она поможет, например, если тебе нужно из пяти микросервисов забрать данные, которые друг от друга не зависят.
раскрыть ветку (5)
раскрыть ветку (4)
А с сервера вы не ходите в БД? В кэш? Етц? В таких местах основной выигрыш и достигается. Более того, ради этого всё это дерьмо и придумали.
раскрыть ветку (2)
так никто тебе не мешает в хэндлере запроса асинхронные вещи писать, здесь главное – обработка запроса не блочит процесс сервера.
раскрыть ветку (1)
IT-юмор
7.6K поста53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору