Проектирование веб приложения для работы с api стороннего сервиса

Tornado, asyncio, aiohttp

Думаешь для этого лучше будет взять асинхронный веб-сервер? Та же Джанга уже не шибко хороша будет?

Джанга будет стоять и ждать ответов от сторонних асинхронных сервисов. Ты серверами не напасёшься с ней.

Так же будет круто, если php, ruby экперты расскажут , как у них там подобное реализуется.

Что крутого в глумлении над обезьянками?

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

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

Про асинхронные дела в питоне не слышал, но осуждаешь.

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

Что-то мешает в той же Джанге асинхронно таски гонять?
Пять лет назад вроде ничего не мешало.

Лол, каждый день работаю с aiohttp и Tornado. Джанга — это говно. Я уже натрахался с ней. Какой-то идиот до меня написал сервис с кучей сторонних API. В итоге 100 500 воркеров стоят и ждут сторонние сервисы. Переписал на aiohttp и теперь жить стало легко и просто. Джанга просто не нужна.

А какой http клиент берете ?

Говнокодерам, не способным осилить асинхронные таски, конечно не нужна.
Их вообще к нормальным инструментам подпускать нельзя.

Тогда брали urllib(2), сейчас берём requests, разницы большой нет, всё-равно они через одно и то же работают.
Главное — не экономить на архитекторе и админе и писать код прямыми руками.

Такс, получается на бекенде, в основном используете Джанго а реквесты делаете с requests , и выжимаете >10000? Это на скольких серверах все это дело работает?

Мы делали неоднократно на Python + zeromq + docker. Плюс хорошие датацентры поближе к /api сервакам.

Там вроде zeromq использует gevent, http client из Geventa брали?

Два раза работал с проектами (крупными) завязанными на стороннем API и в обоих случаях вся работа с API происходила через Java/C# а Ruby/PHP выступали как «веб морды»

Десятки тысяч с каждого сервера

У php, ruby не нашли подходяших инструментов или медленно работает?

А ассиихронные таски, на celery?

Нет, для начала школьный курс информатики освой.
Городить планировщик ради асинхронного ожидания ответа — удел рукожопых некомпетентных индусов.

Учебники почитаются обязательно. Но вопрос остаются открытым. Каким образом, будучи сихронная библиотека urllib или на ней производные могут по несколько десятков тысяч реквестов в секунду. Плиз, скопипасть кусок кода для примера

Так же будет круто, если php, ruby экперты расскажут , как у них там подобное реализуется.

Да без разницы на чём и даже не важно, компьютерная проблема ли это. У тебя есть куча клиентов и несколько объектов, способных их обслужить. Следовательно, все встают в очередь, под конец делится между объектами, а спец. надсмотрщик за ними присматривает, чтоб хорошо двигались. Конечно, есть тут детали реализации самой очереди, починки дефектов, «встать сюда, забрать отсюда» и прочие мелочи, но на то они и мелочи.

Друзья, активнее комментим в этот репозиторий

Потому что эти языки совсем о другом, можно конечно использовать JRuby, но это не то.

Джанга будет стоять и ждать ответов

Что мешает подвесить задачу опроса стороннего сервиса на таску целеры? Или (как вариант) использовать асинхронный requests? Вариантов-то всегда больше чем один, знаете ли.

Ничего не мешает. Просто с aiohttp или Tornado мне никуда ничего вешать в таски не надо. Просто хреначь корутины в основном коде приложения и всё будет работать как надо и эффективно. Удобнее в разы.

Нужно было чтобы всё это работало асихронно и самое главное надёжно со своей сложной логикой обработки получаемых данных, и соответсвующих специалистов проще найти в мире Java или C#

Я бы сказал что это вопрос вкуса.

Впрочем, я бы тоже предпочел торнадо. Однако не сам по себе, а в составе приложения джанги (запускается через джанговские management commands). Я иной раз так делаю когда мне веб-сокеты нужны. Профит в этом случае достаточно очевиден: появляется возможность прикрутить к торнадо джанговские вкусняшки.

А в торнадо для http клиента pycurl берешь?

Нет. У торнадо есть и свои возможности на этот счет.

Note that if you are using curl_httpclient, it is highly recommended that you use a recent version of libcurl and pycurl. Currently the minimum supported version of libcurl is 7.22.0, and the minimum version of pycurl is 7.18.2. It is highly recommended that your libcurl installation is built with asynchronous DNS resolver (threaded or c-ares), otherwise you may encounter various problems with request timeouts (for more information, see http://curl.haxx.se/libcurl

Что-то принципиально мешает отспавнить сколько угодно тредов с урллибом и ловить коллбеки?

https://bitbucket.org/mlug/ninamori/src/nightly/accounts/utils_gravatar.py

Нахера ради одного сраного ожидания городить целый планировщик?

Без вариантов, если только не хотите что бы ваши клиенты отваливались, только потому что сторонний ресурс вовремя не ответил. Или ответил что количество запросов превысило лимит с одного ip.

Кроме того, этот «целый планировщик» умещается в приблизительно в 50-60 строк, так что, честное слово, можно и написать.

Больше мусолим.

Ну и какая нахер разница, не ответит ли сторонний ресурс запросу из треда отспавненнгого джангой или запросу из треда отспавненного сельдереем?
И какая нахер разница от чего загнётся бизнес, который не может даже договориться о лимитах на запросы? От безграмотных ли менеджеров или от безграмотных говнокодеров, один хер — он загнётся.

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

Кроме того, этот «целый планировщик» умещается в приблизительно в 50-60 строк, так что, честное слово, можно и написать.

С asyncio оно умещается в два слова: async и await. При этом ещё и не надо будет городить дополнительных сущностей в виде планировщика. А это уже дополнительная инфраструктура. А это дополнительная поддержка, развёртывание, дополнительные деньги.

Нет, я против забивания гвоздей точильными станками. Вот когда и где надо точить — там и тогда и применяй по назначению.

Так же будет круто, если php, ruby экперты расскажут , как у них там подобное реализуется.

Только через костыли. Бери node.js и не парься.

Nodejs - это что ли та перделка , у которой при установки пакета, еще доустанавливается черт пойми сколько дополнительных. Лучше уж тогда голанг обмазаться. И какое шибко большое преимущество nodejs перед тем же Python?

Дак лучше в таком случае делать на тредах и ловить калбеки, чем ассихроно? Делать пул тредов == количеством активных в данный момент юзеров?

А асинхронно это что такое если не спавн тредов с коллбеками?
Какая-то особая волшебная магия что ли?

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

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

Хорошо, понятно. Можешь поподробнее поведать про:

У нас десятки тысяч реквестов в секунду убегали

Повторяю для детей:
Не надо ждать завершения процедуры для того чтобы отспавнить ещё один тред.

На безграмотные комментарии более не отвечаю. Учись писать без ошибок или меняй профессию.