Асинхронные web-фреймворки питона: aiohttp vs. sanic

А где дисклаймер про владение терминологией?

По теме, в гугле полно сравнений производительности. В остальном, вкусовщина, надо не сравнение, а голосование делать, кто что использует.

Юзаю саник, просто так сложилось, где нужна скорость. aiohttp пока только как клиент. А вообще джанго самое быстрое для проекта в начале.

голоса хотят чтобы я переписал все свои недопроекты с aiohttp на sanic

глупость говорят твои голоса

По теме, в гугле полно сравнений производительности.

Эм, производительность меня слабо волнует.

Ну, ты серьёзно думаешь, что есть такой человек, который одинаково глубоко (чтобы сделать качественное сравнение и соответствующий вывод) использовал несколько фреймворков?

Наверное, таких нет, поэтому много тестов производительности, с ними проще.

Есть вот такое мнение:

Conclusion

Aiohttp: a performance leader in early 2019. If your task requires the ultimate performance – then you should turn your attention to it. In addition, you can experiment with the launch parameters aiohttp, to get most out of it . It has a client version that allows you to make asynchronous requests without additional libraries. Therefore, to implement our new high-load service, we chose it.

Sanic: the popularity of the framework goes ahead of its performance. The miracle did not happen and it was not possible to outrun the leader. In conjunction with the thread on Reddit about security issues – we would not use Sanic right now and would wait for actions from the developers.

fastapi же 😀

aiohttp, конечно, ссаник — ни рыба, ни мясо, и заброшен практически. Но прежде чем делать выбор, посмотри ещё на fastapi. Или вообще на Go.

uvloop не пробовал?

Он в санике по умолчанию, а в чистом виде он мне не был нужен пока.

Так с aiohttp можно использовать.

aiohttp я только как клиент пока юзал, и скорости мне и так хватало.

aiohttp, конечно, ссаник — ни рыба, ни мясо, и заброшен практически

Эм, у меня сложилось противоположное впечатление о заброшенности. Последний релиз у aiohttp - Oct 9, 2019, у sanic - Jun 29, 2020.

Полистал доки саника - АПИ очень похожее на aiohttp, только побольше всяких небольших удобств. Например - наличие live reload искаробки, у aiohttp - идёт отдельной либой. Ещё там есть @app.route фласк-стайл декораторы, которых в aiohttp нету.

(Но обе эти фичи немного спорные. Девтулзам возможно и следует быть в отдельном модуле, а немножк «неявную» регистрацию роутов/хендлеров декораторами я недолюбливаю.)

посмотри ещё на fastapi

Я хочу во-первых асинхронный во-вторых микро- фреймворк.

Второе - потому что считаю что так лучше для обучения. Когда фреймворк «тонкий» - приходиться изучать не только предоставленную абстракцию, но и то что под нею.

Первое - из-за того что я пытаюсь заюзать в проекте очереди сообщений и/или pubsub, мне нужно на фоне запустить таск, который будет эти сообщения слушать. Могу ошибаться, но это вроде как проще с асинхронщиной реализовать. Ну и я просто хочу освоить asyncio.

fastapi - насколько я знаю не асинхронный (ну или с асинхронщиной построенной не на asyncio) и достаточно хай-лвл, заточенный под написание REST API.

Без проблем можешь юзать fastapi с asyncio, и там ничего такого помимо встроенно валидации жирного нет, на мой взгляд.

fastapi - насколько я знаю не асинхронный (ну или с асинхронщиной построенной не на asyncio)

Упс, я сильно ошибался, async там есть. И можно запускать async-функции как фоновые таски.

В случае с aiohttp, кстати, точно так же фоновые таски запускаются коллбеком на старте, если по-феншую.

aiohttp фризит. например, клиент, когда пытаешься, используя одну сессию посетить пару десятков сайтов. кусок говна, короче. что касается серверного использования, то хз вроде в проде было и не отваливалось. настороженно.

Фоновые таски запускаются очень просто без всяких костылей:

tasks: List[asyncio.Task] = [asyncio.create_task(process(i)) for i in data]

выбрать, щоб раз и навсегда

Что удобнее, фичастее и вообще моднее

JS.

Нет, ну правда, чего ты ожидал? %)

функционал

за это слово, в этом контексте - тут по лицу бьют.[br] в т.ч. мне два раза.[br] и правильно делают.

это так, к слову о «владении терминологией»

На Starlette ещё можно глянуть.

Ещё там есть @app.route фласк-стайл декораторы, которых в aiohttp нету.

есть

Async код на пистоне? Забудьте. Лучше возьмите Julia

Я бы выбрал, наверное, Fastapi. Но, если язык не сильно важен, то я б лучше в сторону Go посмотрел. Если говорить о количестве кода, который надо руками писать в случае с микрофреймворками, то не сильно принципиально, какой язык выбирать. И в таком случае у Питона особых преимуществ нет. Только субъективные типа более удобного синтаксиса и т.п.

Там же дефолтный лимит по количеству коннектов - 100. Может быть, в этом дело? Коннекты заканчиваются - и фризит, пока коннект не освободится в пуле.

aiohttp скорее библиотека для построения фреймворков, но её обычно рассматривают именно как готовый фреймворк.

Если честно, я до сих пор не понимаю зачем нужно было создавать саник с нуля, а не на основе aiohttp. Пишут что якобы для ультимативной скорости, у них там до сих пор слоган про скорость. И анонс был с бенчмарками хелловорлдов, где конечно же саник победил всех с отрывом. Но как-то выбирать питон для скорости уже само по себе звучит противоречиво. Но если уж на то пошло, есть ещё более быстрый фреймворк vibora, который рвёт, по заявлениям авторов, даже саник. Но я бы не выпендривался и пошёл бы писать на го, если уж действительно припекло со скоростью.

Насчёт fastapi/starlette и прочих подобных, наверное единственный смысл морочиться с ASGI это возможная поддержка HTTP2. Но сложно сказать насколько он нужен за проксирующим nginx.

В aiohttp хотя и нет HTTP2, и скорее всего не будет, зато есть клиентская часть, в том числе вебсокетная. Ну и его выстрадали уже достаточно хорошо, для продакшена точно годится. Саник выглядит как поле для экспериментов, понаприкручено вообще всё что существует, даже trio, это здорово конечно, но выглядит как попытка объять необъятное.

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

vibora? Его разве не забросили?

По моим сугубо субъективным ощущениям сейчас все асинхронные фреймворки питона так или иначе заброшены. Хайп прошёл и люди куда-то поуходили. Так-то ещё apistar был. И ещё штук 5-10 других.

Причём здесь хайп? Что вы конкретно хотите сейчас от aiohttp чего там уже нет?

Поддержку HTTP2 например. Или sans-io реализацию. Я на самом деле ничего не хочу, просто использую его в своих проектах и мне норм. Но количество коммитов и активности вокруг aio заметно поубавилось по сравнению например с 2017-18.