Ограничения количества запросов в twitter и instagramm

Когда мы таки решились предоставить новый сайт  visitmurom.ru общественности, никто не ожидал, что посещаемость за считанные часы возрастет на 900 с лишним посетителей. Как результат — отвалился twitter и instagram. Оказалось, был превышен лимит запросов api с одного Access token. Правда в этом признался только instagram, twitter пытался уличить меня в подсовывании неправильного токина о_О. Кстати instagram еще и показал сколько же запросов было отправлено за прошедший час. Их оказалось 5040, при ограничении в 5000, пичалька — совсем чуть-чуть не уложились. 

 

Мной был предложен следующий вариант решения проблемы:

 

Так как ограничение — 5000 запросов в час, получается 83 с хвостиком запросов в минуту (piece of cake). Создаем несколько баз данных во избежание уж совсем большой избыточности. По-моему, для instagram достаточно таблицы с медиа данными (данными о картинке), таблицы с комментариями и таблицы с лайками. У twitter проще: достаточно, на мой взгляд, одной таблицы с данными о твите и пользователе. И «общей таблицы», в которой будут храниться тип и время добавления. 

 

Суть метода в том, что при загрузке страницы с данными социальных сетей, проверяем общую таблицу. Если с момента последней загрузки прошло больше, например, пяти минут, то очищаем таблицы twitter или instagram, в зависимости от типа хранящегося в общей таблице и записываем туда новые данные, а в общую таблицу записываем текущее время и тип записи (instagram или twitter). Таким образом в базе храниться минимальное количество, только актуальной информации.

 

Конечно, если хочется хранить более старые записи, можно обновлять данные в таблице и хранить определенное количество записей. Вот такое решение на скорую руку. Если есть комментарии, исправления или предложения, внизу ↓ форма комментариев! 

API Instagram — Origin is not allowed by Access-Control-Allow-Origin.

Недавно столкнулся с неведомой проблемой. Разбирал API Instagram и по опыту работы с API Foursquare использовал функцию JQuery — getJSON.

 

 

С 4square проблем не было — регистрируешь сайт как приложение -> он тебе выдает client id -> этот id используем во всех API запросах для авторизации (https://api.foursquare.com/v2/venues/search?near=муром&query=дизайн-студия-sawtech&client_id=CLIENT_ID&client_secret=CLIENT_SECRET). Все просто! Хотя я до этого дошел не сразу)) всё-таки документация только на вражеском…

 

 

С Instagram появились проблемы! По началу все казалось так-же как и в Foursquare:  регистрируешь сайт как приложение -> он тебе выдает client id -> этот id используем во всех API запросах для авторизации. Но консоль выдавала ошибку — Origin [МОЙ_САЙТ] is not allowed by Access-Control-Allow-Origin. Поначалу (с моим знанием английского) было выдвинуто предположение что это из-за того, что я делаю на локальном хостинге (использую danwer). Ан нет, почитал в интернете (опять же все на вражеском), оказалось у API Instagram необходимо в адрес еще добавить callback! И вобщем-то получилось так — https://api.instagram.com/v1/tags/murom/media/recent?client_id=CLIENT_ID&count=40&callback=?

 

 

Зато как видно для авторизации приложения (или сайта) в Instagram необязательно указывать client_secret )).

Bitrix для разработчика

Bitrix для сложных разработок — самая оптимальная CMS из всех, с которыми я сталкивался. 

 

 

Конечно, многие могут сказать, что он тяжеловесный, медленный, у него раздутая база, он слишком дорогой. На это я вам скажу, что если у вас руки растут из правильного места, то сайт получится и легкий, и быстрый. Но, конечно, от цены и большой базы это не спасет. Хотя и здесь может пригодиться опыт, знания, и правильно растущие руки. Ведь если с умом использовать стандартные модули, а еще лучше API, сайт не только «ускорится», но и , возможно, отпадет необходимость покупки более дорогой версии и в базу попадет меньше информации.

 

 

Дополнительный плюс — это он-лайн тех поддержка. Она, конечно, не всегда помогает: там часто сидят капитаны очевидности, у которых спрашиваешь, как сделать, чтобы работало, а они тебе отвечают: надо сделать так, чтобы работало (и это я привел практически дословный пример :)) . Однако тех поддержка очень часто направляет собственные мысли в правильное русло.

 

 

И самая главная няшка — это, конечно, API. API Bitrix дает эпические возможности для создания сайтов любой сложности! Причем использование «чистого» (без использования модулей) API позволяет, как я уже говорил, ускорить и облегчить сайт. Благо, что по API, Bitrix предоставляет подробные мануалы, причем в режиме online и offline. Да и по использованию API поддержка отвечает точнее, то есть дает более полезную информацию.

 

 

В любом случае, какую CMS выбрать — решать вам. Для сложных сайтов я бы предпочел Bitrix, да и для маленьких тоже, хотя для простых сайтов отдавать деньги за CMS иногда не позволяет жаба, сидящая внутри.