Конечный клиент api-1 и api-2 - мобильное приложение, у которого список сущностей реализован как бесконечная лента, которую нужно "тянуть пальцем вверх". Т. е. запросы на порции данных идут от клиента последовательно.
api-3 - это предполагаемое посредническое звено между клиентом и api-1 с api-2. Я пока не рашил, стоит ли его писать или нет
База api-1 пополняется записями в среднем в 10 раз чаще, чем база api-2 (хотя для каждого конкретного пользователя соотношение может быть разным)
В варианте с датами мне больше нравится то, что в этом случае необязательно создавать api-3 (минус расходы на написание, поддержку, дополнительные зависимости) - со слиянием результатов запросов мобильное приложение справится само и без дополнительных запросов.
А варинт с бинпоиском без написания api-3 (который будет отправлять запросы не через интернет, а хотя бы по локальной сети), не обойтись. Ну, или можно обойтись, но будут проблемы со временени исполнения запросов.
По поводу опасности вернуть всю базу - да, согласен, тут надо будет придумать какое-то разумное ограничение. Либо вместо варианта "dateFrom + dateTo" использовать вариант "dateFrom + limit". Но тут появляются свои минусы.
В варианте с датами есть еще одна засада: если у обоих api в череде данных есть большой разрыв в датах - например, таблица не пополнялась записями целый месяц (учитывая специфику нашего бизнеса, такое возможно) - то придется делать много пустых запросов подряд, пока приложение не "достучится" до начала разрыва. Но тут можно решить проблему, добавляя в результат запроса метаданные о том, какая дата у следующей по очереди записи в базе
В варианте с датами мне больше нравится то, что в этом случае необязательно создавать api-3 (минус расходы на написание, поддержку, дополнительные зависимости) - со слиянием результатов запросов мобильное приложение справится само и без дополнительных запросов.
А варинт с бинпоиском без написания api-3 (который будет отправлять запросы не через интернет, а хотя бы по локальной сети), не обойтись. Ну, или можно обойтись, но будут проблемы со временени исполнения запросов.
По поводу опасности вернуть всю базу - да, согласен, тут надо будет придумать какое-то разумное ограничение. Либо вместо варианта "dateFrom + dateTo" использовать вариант "dateFrom + limit". Но тут появляются свои минусы.
В варианте с датами есть еще одна засада: если у обоих api в череде данных есть большой разрыв в датах - например, таблица не пополнялась записями целый месяц (учитывая специфику нашего бизнеса, такое возможно) - то придется делать много пустых запросов подряд, пока приложение не "достучится" до начала разрыва. Но тут можно решить проблему, добавляя в результат запроса метаданные о том, какая дата у следующей по очереди записи в базе