AWeber API - адЪ и безысходность
Один из заказов, оказавшихся для меня роковым - WP-плагин, собирающий статистику с нескольких сервисов рассылки, включая AWeber. Начавшись довольно-таки праздно, тема обросла таким количеством нюансов и подробностей, что без дрожи эту работку не вспоминаю :)
Первая из проблем, с которой я столкнулся, работая с AWeber'ом - нестабильность отдачи результатов. Их родной wrapper через раз сыпал ошибками вроде таймаута соединения. И если поначалу это было относительно терпимо, то с увеличением количества запросов на один просмотр страницы вероятность встретиться с ошибкой стала приближаться к единице.
Дальше - больше: более-менее нормальный список насчитывал несколько тысяч подписчиков. Собрать по ним всем данные было можно, но за значительный промежуток времени. А учитывая, что на хостинге часто бывает ограничено время выполнения скрипта, задачка вдруг оказалась невыполнимой. Причём в ряде случаев (связка Apache + nginx) выполнение не просто сбрасывалось - сайт на некоторое время уходил в HTTP 504.
Добавим к проблемам с выдачей вероятность появления ошибки практически в любом месте - и получим пушного зверя в приближении. Я начал думать над решениями. Ну, допустим, пагинация. Ограничим выдачу n пользователями, и юзер сможет сам управлять количеством выдаваемых результатов, получая приемлемое время работы! Авотхуй - по ТЗ нужна сортировка, для составления которой так или иначе дёргать всех юзеров разом.
Ну ок, оборачиваю каждый запрос в цикл, в котором проверяю, было ли брошено исключение, и если да - то до n раз запрос повторяется. Ошибка №1 пройдена. Делаем своп основных моментов в БД, обновляя её по запросу через AJAX с контролем времени выполнения скрипта и сохранением состояния, чтобы следующий AJAX-запрос начал с нужного места. Вроде, проблема №2 решена. И тут прилетает проблема №3 - оно ещё лимит на количество обращений имеет, 60 в минуту.
В итоге задачка разбита на две части - фронтенд, занимающийся анализом результатов запроса и контролем времени их отправки, и бек-энд, следящий за временем работы своих задач и сохраняющий состояние. Надо это в виде библиотечки оформить, что ли? А то вдруг где ещё с таким вот геморройцем поработать придётся....
Первая из проблем, с которой я столкнулся, работая с AWeber'ом - нестабильность отдачи результатов. Их родной wrapper через раз сыпал ошибками вроде таймаута соединения. И если поначалу это было относительно терпимо, то с увеличением количества запросов на один просмотр страницы вероятность встретиться с ошибкой стала приближаться к единице.
Дальше - больше: более-менее нормальный список насчитывал несколько тысяч подписчиков. Собрать по ним всем данные было можно, но за значительный промежуток времени. А учитывая, что на хостинге часто бывает ограничено время выполнения скрипта, задачка вдруг оказалась невыполнимой. Причём в ряде случаев (связка Apache + nginx) выполнение не просто сбрасывалось - сайт на некоторое время уходил в HTTP 504.
Добавим к проблемам с выдачей вероятность появления ошибки практически в любом месте - и получим пушного зверя в приближении. Я начал думать над решениями. Ну, допустим, пагинация. Ограничим выдачу n пользователями, и юзер сможет сам управлять количеством выдаваемых результатов, получая приемлемое время работы! Авотхуй - по ТЗ нужна сортировка, для составления которой так или иначе дёргать всех юзеров разом.
Ну ок, оборачиваю каждый запрос в цикл, в котором проверяю, было ли брошено исключение, и если да - то до n раз запрос повторяется. Ошибка №1 пройдена. Делаем своп основных моментов в БД, обновляя её по запросу через AJAX с контролем времени выполнения скрипта и сохранением состояния, чтобы следующий AJAX-запрос начал с нужного места. Вроде, проблема №2 решена. И тут прилетает проблема №3 - оно ещё лимит на количество обращений имеет, 60 в минуту.
В итоге задачка разбита на две части - фронтенд, занимающийся анализом результатов запроса и контролем времени их отправки, и бек-энд, следящий за временем работы своих задач и сохраняющий состояние. Надо это в виде библиотечки оформить, что ли? А то вдруг где ещё с таким вот геморройцем поработать придётся....