Pull to refresh
24
0
Саенко Дарья @dssaenko

Frontend

Send message
Не пробовали. Посмотрим в сторону тепловых карт, если решим делать на карте что-то подобное.
Если я правильно поняла, это библиотека, которая управляет визуализацией данных, и для нее можно подключать любые слои. Тут проблема в том, что слои Яндекс-карт нельзя использовать вне их API. Мы используем Яндекс-карты, поскольку у них лучшее покрытие гео-объектов по России, это важный момент для нас.

Глубоко не изучала API deck.gl, но кажется, что для них требуется загружать все данные сразу, а они сами будут кластеризовать их. Это так?
Ну вот да, тут бы приходилось балансировать между тем, что при сдвиге карты нам не хватает данных, и мы ждем ответ от бэкенда и тем, что мы изначально запрашиваем много данных и долго ждем. Поэтому выбрали решение через бэк — где запрашиваем в самом запросе за маркерами ровно столько, сколько нужно для видимой области (ровно для того, чтобы сделать просмотренность и ховер), а каждый тайл запрашивается отдельно по требованию. При этом запрос по тайлу выполняется существенно быстрее запроса по данным.
Нет. Возможно, в дальнейшем оптимизируем, если поймем, что это является проблемой.
Рассматривали такой вариант на этапе прототипа. Тут дело в том, что на клиенте живут не все данные, а только данные по видимой области.

Решал похожим образом, но без участия бекенда. На фронте был написан свой рендерер, который на canvas отрисовывает пины.

А данные на фронт отдавались только для видимой области? Т е например, при сдвиге был новый запрос за данными?
Ховер по точке происходит с ощутимой задержкой

На уровне города да, на уровнях ближе ощутимой задержки не наблюдаю.
Мы отдаем на фронт не все точки, а только точки из видимой области. Если мы будем отдавать сразу много точек (большую область) — запрос за данными будет выполняться долго, а юзер может никогда и не сдвинуть карту. Тогда зачем он столько времени ждал?

Если мы будем рисовать тайлы по данным из видимой области, мы теряем преимущество скорости отрисовки при сдвиге — нужно сначала отправить запрос за данными на бэкенд, дождаться их, а потом только отрисовать по ним canvas.

На метриках видим, что в среднем запрос за тайлами выполняется примерно в три раза быстрее запроса за маркерами. Загрузка квадратами не выглядит красивой, согласна, но приходится чем-то жертвовать =)
вы просто убрали кластеры, а стандартные маркеры сделали кружками и уменьшили их размер

Точки — это не совсем маркеры. При клике на точку отображаются объявления в доме. А кластер — это объединение по сетке с достаточно большим радиусом, поэтому клики по кластерам зумят карту вместо того, чтобы сразу отобразить объявления.
вы просто убрали кластеры, а стандартные маркеры сделали кружками и уменьшили их размер

Точки — это не совсем маркеры. При клике на точку отображаются объявления в доме. А кластер — это объединение по сетке с достаточно большим радиусом, поэтому клики по кластерам зумят карту вместо того, чтобы сразу отобразить объявления.
Нет, будет одна точка. Кластеризуются до дома на бэкенде. Если хотя бы одно объявление просмотрено, точка рисуется просмотренной (это было продуктовым решением).
Не отказались, фронт использует тайлы, по объектам рисует пины. Решение выкачено на всех.

Массив rash в ответе /map/marker нужен для того, чтобы сделать ховер и просмотренные точки. Если отфильтровать запросы по картинкам и /map/tiles — можно увидеть svg, которые отдаются с бэкенда.
Спасибо за вопрос. Точных чисел у меня, к сожалению, нет. Могу сказать так — путь от идеи до раскатки фичи занял около полугода, работала над задачей одна команда (но мы работали не только над этой фичей, конечно, у нас были и другие затратные задачи). Одна команда — все функции в количестве 1 человека.

Стоит отметить, что достаточно много времени занимали ресерчи и прототипы: мы смотрели, подойдет ли нам решение через тайлы, писали прототип на NodeJS, писали и переделывали кликабельность и ховер. Ну, и еще большой кусок ушел на оптимизацию бэкенда. Кроме того, мы делали не только веб-реализацию, но и мобилки.

Information

Rating
Does not participate
Works in
Registered
Activity