LINUX.ORG.RU

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

 , , , ,


0

4

Здравствуйте, вопрос к тем кто принимал участие в создании веб приложения / сайтов ,в котором в основном идет работа с api стороннего приложения будь то api твитер/фейсбук/яндекс/ или что еще. Тобишь, достаточно большое колличество людей, работают через это приложение со сторонним по api.

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

Что лучше будет взять, какой-нибудь асинхронный http client для работы с api или синхронный который будет работ в пуле потоков/процессов?

Или для такого будет норм прикрутить брокер задач типо celary?

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

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

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

Siado ★★★★★ ()

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

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

Goury ★★★★★ ()
Ответ на: комментарий от resurtm

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

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

Goury ★★★★★ ()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от NetSurf

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

Goury ★★★★★ ()
Ответ на: комментарий от Goury

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

resurtm ★★★ ()
Ответ на: комментарий от resurtm

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

Goury ★★★★★ ()
Ответ на: комментарий от NetSurf

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

Goury ★★★★★ ()
Ответ на: комментарий от Goury

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

NetSurf ()

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

menangen ★★★★★ ()

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

Lancelot ()
Ответ на: комментарий от NetSurf

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

Goury ★★★★★ ()
Ответ на: комментарий от Goury

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

NetSurf ()

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

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

anonymous ()

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

NetSurf ()
Ответ на: комментарий от resurtm

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

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

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

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

resurtm ★★★ ()
Последнее исправление: resurtm (всего исправлений: 1)
Ответ на: комментарий от Lancelot

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

Lancelot ()
Ответ на: комментарий от resurtm

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

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

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

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

NetSurf ()
Ответ на: комментарий от Goury

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

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

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

k0valenk0_igor ★★★ ()
Ответ на: комментарий от k0valenk0_igor

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

Goury ★★★★★ ()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от Goury

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

NetSurf ()
Ответ на: комментарий от k0valenk0_igor

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

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

resurtm ★★★ ()
Последнее исправление: resurtm (всего исправлений: 1)
Ответ на: комментарий от NetSurf

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

Goury ★★★★★ ()
Последнее исправление: Goury (всего исправлений: 1)

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

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

th3m3 ★★★★★ ()
Ответ на: комментарий от th3m3

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

NetSurf ()
Ответ на: комментарий от Goury

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

NetSurf ()
Ответ на: комментарий от NetSurf

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

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

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

Goury ★★★★★ ()
Ответ на: комментарий от Goury

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

У нас десятки тысяч реквестов в секунду убегали
Как оно вообще было? Я как-то пробовал делать бенчи и ощущение, что эти нативные питоновские реквест модули, не шибко быстрые

NetSurf ()
Ответ на: комментарий от NetSurf

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

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

Goury ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.