Постобработка данных: фронтент или бэкэнд. За и Против

#http #архитектура #frontend #backend #highload

По сети передаются данные, которые представляют собой полигоны  (для простоты можно
считать, что это массивы float). В таком случае возникает вопрос, где лучше формировать
окончательный вид этих данных в виде json: на сервере и передавать json или на фронте.
Важное замечание. На фронте нужны именно json.

Кажется, что это лучше делать на фронте, чтобы не таскать по сети строки, а передавать
массивы float. Но я не уверен в производительности JS. Насколько эффективно раскладывать
всё по строкам?



Участники, которые собираются участвовать в конкурсе, обратите внимание, конкурс
объявлен для того, чтобы люди поделились своим опытом решения подобного рода задач.
Описание конкурса:

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

Я, в частности, подразумеваю, что речь идёт о High Load, т.е. о системах, которые
обеспечивают безотказную работоспособность для не менее чем Q запросов и отвечают не
более чем за указанный интервал времени T

Меня интересуют решения T == 1 sek. Q >= 50. Лучше, больше 100
    

Ответы

Ответ 1

Вопрос, на самом деле, весьма сложный. Есть плюсы и минусы обоих решений.


Если делать всё на серваке, то все клиенты будут однородные данные получать и не
будет дополнительно обработки. Следовательно, шанс, что на клиенте накосячат, меньше.
Лишняя нагрузка на сервак. Порой переложить дополнительную обработку на клиент -
вполне валидное решение, чтоб снизить нагрузку.


Как пример, на текущем месте работы у нас используются карты. Необходима кластеризация
точек. И проблема с тем, где это делать (на сервере или клиенте), стоит весьма остро.
В базе миллионы пользователей, у каждого свои атрибуты (координаты, город, страна,
пол и т.п). Нужно кластеризовать всё это дело с учётом атрибутов.

Раньше на серваке захардкожено было, что больше определённого числа юзеров не выдаётся.



Встал вопрос о кластеризации. Варианта два:


Сервер отдаёт кучу пользователей. А клиентские приложения сами кластеризуют как-то
(iOS, Android и т.д. реализуют это на клиенте).
Кластеризовать на сервере. Клиентам только зум передавать.


Сервак, в принципе, неплохо масштабируется. Решили делать там. У нас бэк на ноде.
Используем supercluster, который подтягивает данные из базы и кластеризует всё. В риалтайме
вполне справляется с этим делом. Для того, чтоб не проседало ничего, используем Worker
Threads.

Из нашего проекта не могу скринов отсыпать, но выглядит как-то так:



P.S. у нас всё API гоняется в json. Если у вас не слишком частые запросы, то лучше
уж json использовать, оверхедом по размеру можно принебречь.


Ответ 2

Лучше фронту всегда отдавать готовые, потребительские данные. Всю остальную логику
с данными делать на сервере. Фронт у тебя должен быть "тупой". Получил данные и отобразил.

Лучше это в том числе потому что средний пользователь сегодня смотрит сайт не с десктопа,
а с телефона. Часто это не топовый iPhone, а какой-то слабый и дешевый андроид. На
нём всё медленно. Значит, чем меньше вы делаете ненужной работы на клиенте, тем быстрее
работает сайт у пользователей, и тем более удовлетворены работой вашего сайта его гости.
Это особенно важно если говорить не о сайтах уровня домашней страницы, а о настоящем
Highload: потеря одного процента пользователей из-за того что ваш сайт недостаточно
отзывчив может иметь очень ощутимые финансовые последствия.


Ответ 3

Тут вопрос не до конца поставлен...

Я считаю что в этом случае решения по архитектуре нужно принимать исходя из количества
передаваемых(обновляемых во времени) данных

Т.к. не понятно можно все сразу загрузить, сложить в Indexeddb и потом её кошмарить,
что весьма простое решение. 

Или же надо постоянно слать гео запросы на сервер, типа покажи мне что сейчас попало
в такой-то bbox, т.к. фич терабайты или они меняются постоянно.

И еше не понятно, вы решаете задачу оптимизации, или просто пока рисуете на карте ?

Я по работе в основном имею дело с компьютерной графикой и гео-информационными системами. 

Проекты ориентированы на realtime отображение на глобусе как ракета полетела, куда
упали отделяющиеся части, какие измерительные средства какую траекторию померили и
все в таком духе. 

Сырых данных вагон и маленькая тележка, однако то, что прилетает непосредственно
ко мне можно сказать песчинка. Бэкэнд у нас сложная штука- зоорпарк разного программного
и аппаратного барахла, раскиданного по планете, передачей данных в системе является
amqp брокер, и естественно он помимо моих данных обрабатывает еще кучу других потребителей
и поставщиков сообщений. При таком распределении нагрузки - я сам восстанавливаю пакеты
протобафа в geojson и тому подобные вещи на лету, ибо разным потребителям информация
нужна все-равно в разном виде и гонять по сети/спутнику лишние байты тоже не хочется,
еще нужно учесть что все это еще и дуплицируется по какой-то кучерявой логике детали
которой мне неизвестны =)

Add: похоже, в вашем конкретном случае, с учётом указанных вами критериев, вы не
можете полагаться на скорость клиентского девайса, соответственно, то и работу на нем
лучше не выполнять. 

Что касается кластеризации и геоданных - вы смотрели в сторону postgis? Это посгрес
на стероидах, специально для geospatial данных и запросов


Ответ 4

Успешная практика разработки Unix говорит о том, что для связи компонент системы
 желательно (всюду, где это не является невозможным по тем или иным причинам) использовать
текстовые (с возможностью чтения и редактирования человеком) форматы представления данных.

Думаю, в вашем случае нужно гонять по сети json (т.е. человекочитаемый текст).