Comments 7
И что, где же заявленные истории «преодоления сложностей»? Или цель была просто заявить «смотрите, какие мы крутые»?
Кому и зачем нужен ваш пост на Хабре?
Кому и зачем нужен ваш пост на Хабре?
Ребята из Realweb, спасибо за пост и освещение проблемы. Сами постоянно сталкиваемся с проблемами совместимости, документации и имён данных. Понимаю, что размещать код ваших сущностей и «подпорок» вам невыгодно, но ход решения проблем совершенно ясен, взяли на вооружение идею с псевдопеременными. Что касается унификации, то да, она протекает очень медленно и это требует немыслимых сил на поддержку API.
А в какую БД складываются данные от всех API? Какой объем данных в ней хранится и какой поток операций она обрабатывает?
Складываем в MySQL, причём в два. Один MySQL (MyISAM с партицированием по месяцам) используется для хранения статистики по ROLAP. Второй MySQL (InnoDB) для хранения нестатистических данных, таких как имена рекламных кампаний и т. п. На данный момент обе базы занимают около 1ТБ на жёстком диске. Данные от API обрабатываем в пакетном режиме, при обработке пакета пишем где-то 100 записей в секунду, но так как пакеты маленькие (100000 записей), то нагрузка на базу непостоянная. Пакеты маленькие, потому что, в основном, это статистика за прошедший или текущий день.
Вам предстоит создать архитектуру вида Фабрика адаптеров. Для каждого адаптера будут определены стандартные действия, в виде классов. Объём кода при подключении очередного адаптера существенно сократится при использовании абстрактных классов адаптеров и действий с выделением общих методов взаимодействия с API.
Я не работаю в AdHands, но как человек, работавший с API Директа v4, Google AdWords 2013+, ВКонтакте, Begun могу сказать, что они настолько разные, что у вас либо будет выбираться слишком много данных из БД, чтобы сохранить интерфейсы простыми и будут проблемы с потерей remote id добавленых объектов, либо запросы к api будут неэффективными.
Поясню детально: в апи Директа до v5 добавлять и редактировать объявления можно только сразу передавая все параметры объявления, все ключевые слова, ставки и настроки по ним — просто адское кол-во данных (https://tech.yandex.ru/direct/doc/dg-v4/reference/CreateOrUpdateBanners-docpage/). Слава богу они в v5 это поправили и сделали более менее как в гугле. Доходило до того, что чтобы не затереть автопроставленные минус слова на фразах нам приходилось скачивать обявление из api, менять то, что нам нужно и отправлять обратно.
Что касается гугла, то тут наоборот — на каждый пук, извините, вызов метода. Например — добавить объявление, добавить допссылку, связать допссылку с объявлением. Хотя стоит отметить, что это лучший api, с которым мне пришлось работать по уровню свободы действий и в целом эффективности запросов к нему. Он на soap (xml), но работает раз в 5 быстрее чем json у api директа v4.
Ну и прикиньте еще, что будет у вас в «общих» методах. Еще вспомните о том, что программы падают, сеть пропадает и происходит много чего, что может вызвать добавление объектов во внешних сиетемах, но при этом упадет до сохранения полученных remote id объектов у вас в системе.
А еще в разных внешних системах не всегда совпадает иерархия объектов и вообще их наличие, настройки, иерархия настроек.
В общем-то я не против общих методов, они полезны, но иногда их поддержка стоит дороже, чем отдельная реализация.
Поясню детально: в апи Директа до v5 добавлять и редактировать объявления можно только сразу передавая все параметры объявления, все ключевые слова, ставки и настроки по ним — просто адское кол-во данных (https://tech.yandex.ru/direct/doc/dg-v4/reference/CreateOrUpdateBanners-docpage/). Слава богу они в v5 это поправили и сделали более менее как в гугле. Доходило до того, что чтобы не затереть автопроставленные минус слова на фразах нам приходилось скачивать обявление из api, менять то, что нам нужно и отправлять обратно.
Что касается гугла, то тут наоборот — на каждый пук, извините, вызов метода. Например — добавить объявление, добавить допссылку, связать допссылку с объявлением. Хотя стоит отметить, что это лучший api, с которым мне пришлось работать по уровню свободы действий и в целом эффективности запросов к нему. Он на soap (xml), но работает раз в 5 быстрее чем json у api директа v4.
Ну и прикиньте еще, что будет у вас в «общих» методах. Еще вспомните о том, что программы падают, сеть пропадает и происходит много чего, что может вызвать добавление объектов во внешних сиетемах, но при этом упадет до сохранения полученных remote id объектов у вас в системе.
А еще в разных внешних системах не всегда совпадает иерархия объектов и вообще их наличие, настройки, иерархия настроек.
В общем-то я не против общих методов, они полезны, но иногда их поддержка стоит дороже, чем отдельная реализация.
Sign up to leave a comment.
Мечты об идеальном API или как преодолевались сложности в проекте AdHands