Веб-приложение: предварительная обработка и отправка всех элементов на одной странице загрузки или разделение элементов на отдельные клиентские запросы? - PullRequest
4 голосов
/ 09 января 2012

Мне было поручено контролировать переписывание / модернизацию древнего (1990-х!) PHP-приложения нашей фирмы. Конечно, я подхожу к этой задаче с волнением и трепетом. Я потратил недели на изучение фреймворков, библиотек, тестов и т. П.

Одной из основных функций этой системы является загрузка элементов данных из базы данных MySQL db и представление их внешним пользователям. Какие элементы отображаются, это сложная проблема, но это может быть любая комбинация или количество элементов. Скажем, например, как каталог. Пользователь может просматривать один элемент, просматривать категории элементов или искать элементы. Кроме того, существует множество ограничений и условий на видимость и другие конкретные данные уровня элемента.

Мой конкретный вопрос:

** Что думают эксперты о загрузке и отображении данных товара? С точки зрения времени загрузки страницы, нагрузки на сервер или любого другого фактора ... Должен ли я (A): сервер вычисляет все выходные данные и затем отправляет их клиенту (браузеру) в запросе начальной страницы?

(B): Или я должен вывести базовый скелет страницы вместе со списком идентификаторов в переменной javascript, а затем попросить клиента запросить каждый элемент отдельно, а затем дать ответчику отправить данные (JSON?) И клиент заполняет страницы? **

Что я ищу здесь, так это мудрость некоторых программистов о том, что сработало лучше всего. Мне не нужен совет, который подсказывает мне перейти с PHP на другой язык или что мне нужно запускать собственные тесты. Я не прошу никого писать код для меня. Мне просто нужна ваша мудрость / совет, какой путь будет лучше и почему, или факторы послужат основанием для одного подхода против другого.

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

Вариант (B) кажется более прохладным и более «современным», но есть ли смысл в этом подходе? Что бы я получил, кроме, возможно, некоторых интерфейсных JavaScript и навыков динамических шаблонов? Кажется, что загрузка каждой страницы может потребовать десятков дополнительных запросов, а также дополнительной обработки на стороне клиента, что, на мой взгляд, противоречит последним советам по оптимизации скорости страниц от больших пушек.

Спасибо за ваше время.

1 Ответ

2 голосов
/ 09 января 2012

С учетом того, как вы сформулировали варианты A и B. Очевидный выбор - A. Вот почему:

... вместе со списком идентификаторов в переменной javascript, и затем клиент запрашивает каждый элемент отдельно , а затем имеет ...

Это приведет к очень низкой производительности, так как теперь вы делаете много SELECT * FROM items WHERE id=x, чтобы каждая возвращала 1 запись вместо SELECT * FROM items WHERE something_else, поэтому у вас нет накладных расходов на каждый из этих запросов MySQL плюс каждый запрос HTTP , плохая эффективность.

Итак, как у вас есть, вариант А точно.

Но, давайте вернемся к сути того, что я думаю, что вы получаете с опцией B ...

Допустим, у вас есть интерфейс поиска HTML / веб, все это подается по первому запросу, без результатов. Теперь я ввожу параметры поиска и нажимаю «идти». В фоновом режиме (js / ajax) мои критерии могут быть отправлены на сервер и обработаны, и вы отправляете обратно объект JSON первой страницы элементов (только данные, item_name, item_id, item_desc и т. Д., Без html, без стилей), тогда браузер выводит его на страницу, используя javascript.

Почему это может быть лучше? Теперь вы можете думать о своей серверной / серверной части как о API, принимающем запросы и возвращающем данные, что довольно чисто в плане разработки кода. Он не должен циклически проходить через элементы, добавляющие HTML, без графических ресурсов и т. Д. Это очень гибко, потому что теперь давайте скажем, что вы получаете заказ, чтобы сделать эту систему элементов доступной через приложение iPhone! Проблема? Не совсем, у вас уже есть JSON API, поэтому ваше iPhone-приложение может использовать этот API-интерфейс таким же образом и соответствующим образом представлять данные внутри приложения.

Обратно на сторону веб-браузера: вероятно, это также приведет к более быстрому взаимодействию с пользователем, поскольку данные, которые вы отправляете обратно, 1) проще / быстрее для сервера отображать 2) меньший объем данных, поскольку он ТОЛЬКО данные элемента, а не его HTML-форматирование или окружающие элементы страницы.

Надеюсь, это поможет лучше понять ваше решение. Удачи!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...