Кто прав кто не прав
 

Доброго времени суток!

Возник конфликт с одним разработчиком по поводу связи фронта и бэка.
Хочу узнать ваше мнение.

Отпустим подробности)

На бэке висит парсер сайта, а клиент - мобильное приложение, которое получает данные с парсера и удобненько их выводит.

Естественно данных много и на клиенте есть возможность создания "фильтров". Пользователь создает новый фильтр, (удаляет, редактирует) и любое действие отправляется в облако. где и сохраняется.

Когда приложение запрашивает данные бэк отдает распарсенные данные, которые соотвествуют выбранному фильтру.




Короче обычный клиент сайта с облачной синхронизаций фильтров поиска.

Но если пользователь заходит с другого телефона под своим аккаунтом, то мы отдаем ему все его настройки!

Следовательно фильтры - это данные для парсера + модели для ui

А мне очень удобно использовать статику такого вида (по ней гененрируется шаблон)

(есть не только такие)
 $scope.metroStation = {
    'Арбатско-Покровская линия': {
      color: '#072889'
      arr: [
        'Пятницкое шоссе'
        'Митино'
        'Волоколамская'
        'Мякинино'
        'Строгино'
        'Крылатское'
        'Молодежная'
        'Кунцевская'
        'Славянски бульвар'
        'Парк победы'
        'Киевская'
        'Смоленская'
        'Арбатская'
        'Площадь революции'
        'Курская'
        'Бауманская'
        'Электрозаводская'
        'Семеновская'
        'Партизанская'
        'Измайловская'
        'Первомайская'
        'Щелковская'
      ]
    }, ...

А модели в таком виде:

'Арбатско-Покровская линия': [ 'Электрозаводская',   'Семеновская',  'Щелковская']

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


Все удобно читаемо и тд, но бэкенедер настаивает чтобы я отправлял ему не такую модель

['Электрозаводская',   'Семеновская',  'Щелковская']
// а такую
[2, 4, 3]

Только я не понимаю почему!
Мне приводят в аргумент что это все фреймворки так делают и вообще это знаменитый паттерн программирования, и никто не шлет юникодовые строчки на серв и тд
При этом ему нужны еще были два файлика чтобы не наебаться с этими числовыми индексами (поменял строчку на фронте и все, пзд)
А мне бы пришлось делать декораторы для правильной выборки


Еще был аргумент с локализацией, но тут мой способ опять лучше. Я создам просто две статики, из одной буду генерировать шаблон а из другой модель. ПРОФИТ!

Я не понимаю почему он не может связать юникодовую ссылку с методом парсера вернуть то что нужно.

Короче странно, обьясните если чего то не понимаю.

Его плюсы:
цифорки, меньше трафика

Мои плюсы:
Меньше кода, он читабельнее
Никаких декораторв, я ему отправил, он связал, все, работает!
Если он мне вернул, то я в модель пихаю, все, работает
Опять же локализация удобнее
Не нужно хранить 2 статичных файла чтобы делать выборку (и дай бох не наепаца с циферкой)



Может показаться что дело тут в экономии трафика (строки заметно больше), но фильтры пользователь делает крайне редко, но пуш уведомления, уведомления по вебсокетам и огромное кол-во трафика будет сжираться картинками и прешедшими обьявами (тут без 4г или вифи никак)

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

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

Возможно, но тут скорее нагрузка должна быть равная (телефончики плохо справляются с такими задачами и подлагивание пусть даже на 200мс, оочень заметно. А сервер в случае с филтром сохраняет их 1 раз, а дальше все общаются через id, Тоесть он сохранил, сделал карту и все. Потом только отправляет эти фильтры (если новая сессия) Нагрузка минимум)
А заказы на удаление изменение и выдачу данных по фильтру толкьо по id

мне кажется, тут речь скорее не сколько о трафике,сколько об разделении идентификаторов (циферок) от представлений (строки)

оки. китаец зашел к тебе на сайт\приложение. ты будешь гонять китайские символы туды сюды ?)

а айдишники и для китайца айдишники. и для чукчи тоже будут циферки )

мне казалось, затупы у смартов из-за CPU, а не памяти

Надуманная проблема какая-то. Естественно лучше айдишники отдавать, чем сами значения.

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


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

Ну да) Хотя если сделать моим способом, но только гененрировать модель из статики (которая собрана из айдишников).. так можно, но файлики сравнения хранить придется

l-liava-l, сервер должен обрабатывать цифры. Символы помимо цифровых очень затратны. Если будет наплыв, то с цифирками сервер еще справиться, а вот с юникодом уже вряд ли.

Конечно это зависит от реализации, но лично я никогда не отправляю на сервер под нагрузкой ничего кроме цифирок.

Если предполагается нагрузка, то только цифры. И потом, а если

'Электрозаводская'

Внезапно! кто-то решит изменить на:

'м. Электрозаводская'

?

Что и серверную часть придется переписывать?

Ни, ни, ни. Если я конечно правильно понял проблему.

Я вас понял, вот он и аргумент)
Благодарю)

бэк прав

Если коротко, то элемент твоего справочника это

{
    id: {Number},
    title: {String}
}

просто потому, что только id однозначно идентифицирует запись, а title может меняться/локализоваться

а сам справочник?

имхо, пусть уж так:

// руске файл
LOCALIZE['RU'] = {
    '0': 'Э-Э-ЭЙ'
};

// онглицк файл
LOCALIZE['EN'] = {
  '0': 'YOOOO'
};

зависит от ситуации :)