Александр Новиков

Не вижу особых препятствий:

Eсть URL

POST https://apps.padi.com/scuba-diving/dive-shop-locator/Dsl/GetDiveShops

Принимает json параметры

cLat:33.638802
cLong:-117.603366
courseIds:""
distanceMeters:1000000
eLng:-117.1913786953125
levelIds:"3,2"
mapSize:"smaller"
nLat:33.99591887201719
offeringIds:""
sLat:33.280197932608054
searchString:""
specialtyId:-1
storeNumber:-1
wLng:-118.0153533046875

Нужно провести ревес инженириг (читай, потестить с разными параметрами) на что влияют Lang/Lng/Lat параметры, и написать просто цикл запросов который бы для всех участков карты запросил с сервера результаты.
В тестах поможет ответ - там как раз границы указаны. (массив SearchRecords - результаты поиска, Bounds - границы участка поиска)
По сути задача
1) понять какие входные параметры запроса возвращают какой участок карты в Bounds)
2) подобрать массив входных параметров чтобы перебрать все участки карты последовательно
3) запустить цикл и спарсить ответы из SearchRecords в одно хранилище
4) убрать дубликаты
5) преобразовать в желаемый формат (csv для excel)

Пара кейсов, после которых идея "передать на фронт и фильтровать там" перестает казаться такой хорошей

1) Прилетел массив на 10 000 элементов. Клиент зашел с Samsung galaxy S2 , попробовал загрузить/фильтрануть, посмотрел, как завис браузер, и ушел. Не забывайте, что не все пользователи сидят с десктопов как у разработчиков с 16-32Gb оперативы. Мобилка может поперхнуться банально из-за большого json-а

2) Как только потребуется сделать паджинацию - фильтрация на фронте станет выдавать неожиданно некорректные данные

Пинайте сервер-сайд, пусть разрабы или кэшируют, или расставят индексы в базе правильно, если у них SQL, или перейдут на подходящий поисковый движок с фасетным поиском

Я верю, что можно сделать выдачу и фильтрацию чисто на фронте с любым количеством элементов, если команда состоит из сплошных ниндзя и рокстаров, но практика в 3 подобные ситуации показывает, что в итоге эту фильтрацию придется переписывать как минимум на гибридную (и поддерживать 2 решения, на фронте для малого количества записей, и на бэке для большого), либо полностью на сервер сайд, так как к сожалению команда никогда не состоит из идеальных разработчиков, чаще из обычных живых людей