Архитектура с толстым клиентом: какие есть недостатки?
 

Здравствуйте, коллеги!
Сейчас разрабатываем простенькое веб-приложение для учета заказов производственной компании. Функционал несложный: список заказов, задачи по заказам, история взаимодействия по каждому заказу, статистика.
В силу наличия опыта разработки клиентской части и практически полного отсутствия опыта разработки серверной, была выбрана архитектура с толстым клиентом. То есть вся работа по отображению и обработке данных делается на клиенте через js. На сервере происходит по-сути, только работа с базой и форматирование данных в том виде, чтобы было с ними удобно работать на клиенте. Большая часть обработки данных при взаимодействии с пользователем (сортировка, фильтры и т.п.) тоже реализованы на клиенте.
Почитал про аналогичные приложения, там почему-то все делают на сервере, включая сортировку html таблиц.
Почему это делается на сервере: так удобнее разработчику, или есть какие-то объективные причины?
Напишите, пожалуйста, какие могут быть проблемы при обработке данных на клиенте?

Сервер не может сортировать html таблицы, он ими не оперирует, их у него нет. А вот отсортировать данные запроса, это пожалуйста, этим занимается SQL причем с большими возможностями.

ну я имел в виду, что пользователь тыкает на кнопку сортировки, уходит запрос на сервер, там формируется отсортированная нужным образом хтмл таблица и возвращается пользователю. Вот зачем все это нужно, если можно через js на клиенте это сделать? Это надежнее/быстрее/удобнее ?

Сложно сказать двумя словами о сортировки данных, ибо сортировку не обязательно определяют данные некоего поля таблицы, это могут быть данные сложных вложенных запросов. SQL движки на это заточены. А вы что хотите в этом случае, перетряхивать html таблицу, получать исходное, находить нужное, затем заниматься сортировкой?

Сортировка может быть и по группе данных причем с различными условиями. Хотите маятся на клиенте, ну так сначала создайте нечто по возможностям SQL, и делайте что хотите. Не будете же вы на каждый случай/условие сортировки писать новый сценарий.

А вот готовить серверу html код таблицы действительно не обязательно, представление это уже прерогатива клиента.

И о фильтрах. Ну ладно у вас десяток/сотни записей, можете вывалить их на клиента и фильтровать. А что если их десятки тысяч, тоже все выгружать на клиента?

мы для этого используем готовый js плагин tablesorter - его возможностей более чем достаточно для наших задач


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

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

Вы не сможете переложить на клиента заботы сервера, не справится он с ними так как архитектура данных в базе далеко не одна таблица.

laimas, а если одна?)

Весь вопрос в объёмах, пока быстрее получить по сети всё что есть и остортировать\фильтровать на клиенте - проще и удобнее клиент, когда объёмы начинают вызывать заметные сетевые задержки и тормоза клиента - пора использовать сервер.
Принято делать на вырост, потому обычно сразу начинают с "правильной" серверной логики. Но если вы уверены на 100% что никакого роста не будет - можно не париться.

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

Никто не запрещает сортировать на клиенте табличные данные: списки, html таблицы, по выбору какой либо колонки. Что при этом быстрее будет - иметь данные которые сортируются и по ним строится таблица или сама таблица перетряхивается, это не важно, но от такой задачи вполне уместно освободить сервер.

И вопрос куда глубже, чем просто в объемах.

По поводу объемов данных понятно. А не могли бы Вы подробнее пояснить, какие еще есть недостатки кроме необходимости передавать с сервера несколько бОльший объем данных, чем необходимо?

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

Сначала простой пример. Пусть мы выводим постранично табличные данные, при этом заказывая сортировку по N полям с нужными условиями. Данные при этом, это связанные таблицы имеющие индексы (а как иначе, иначе это плохо), а индексы хранятся на сервере, клиенту их сервер естественно не передает. Если просматривать все данные с этим набором сортировки, то эти условия и определят порядок их получения клиентом. Если изменять условия сортировки на клиенте и сортировать на клиенте, что можно и не возбраняется, то мы будем сортировать только часть данных (текущие, полученные клиентом) не переопределяя их порядок получения во всем наборе.

Случай посложнее. Пусть БД, это клиенты (заказчики), товары и заказы. База данных проектируется исходя из принципов нормализации, и каждая эта сущность может описана в базе N связанными таблицами, при этом заказы могут быть связаны с клиентами и товарами через внешние ключи. Нужно получить определенный список любой сущности по определенным условиям. Для SQL это не является проблемой, это его повседневная задача, если же это решать на клиенте, то данные всех таблиц нужно выгрузить на клиента. У клиента (JS) не было и нет такого инструментария, ибо это не являлось и не является его задачами. Если вы будете писать сами, то нужно углубиться прежде всего в вопросы сортировки, их способы, индексацию (это затрагивает и сортировку, и очень важно для выборки, что в сущности и есть "фильтр") и т.д.

Получится ли у вас написать нечто такое же гибкое как у SQL движка я не знаю, но вряд ли это будет целесообразно. Если ограничится некими условиями, а именно, работать только с браузера имеющего поддержку WebSQL, вот тогда да - вы будете иметь полноценную реляционную базу данных на клиенте, sqlite движок. Работая с ней оперировать вы будете не дикостью в виде объектов и т.п., а обычным SQL языком, что гораздо удобнее. В этом случае база "живет" на клиенте у ее пользователя, а на сервер выгружается ее копия (синхронизация) для потребителей. При этом можно вообще отказаться от браузера и иметь ПО, которое полноценно может использовать COM объекты системы, что есть несомненный плюс в делопроизводстве.

Все бы хорошо, но не всегда такое возможно. Что если БД эта предполагает многопользовательский доступ - N менеджеров работающих с ней, что естественно предполагает изменение данных. Хороший торгаш знает, что информация о заказах, это информация о спросе, а спрос, это не только "достать и привезти", но и стратегия маркетинга. Чтобы получать информацию в реальном времени всем менеджерам запрашивать они ее должны с одной БД, то есть с сервера. Если, к примеру, из этой БД грузить данные им в браузер где они ее могут фильтровать/сортировать и т.п., то это гарантированная предпосылка, что они могут пропустить новые заказы. Или изучая спрос, менеджер может изменять параметры заказа, или обслуживая заказ изменяет его статус, что естественно изменяет общую информацию и другие менеджеры должны быть в курсе. В многопользовательском режиме обязательно возникают вопросы, которые решаются в SQL блокировками, транзакциями.

Эти вопросы также нужно будет учитывать, если они затрагивают проект ваш и перенося некие задачи на клиента решать эти проблемы. А делать выборку, сортировать конечный набор табличных данных, это можно и нужно переносить на клиента. То есть как поступать, это вопрос ну уж точно не из области "JS может отличать А от Б, и процессоры уже не 486-е, значит сделает", все определяется данными, задачами, доступом и т.д.