Хотел рассказать, как я вижу устройство архитектуры взаимодействия серверной и клиентской частей. И хотел бы узнать спросить хабровчан, чем плоха или хорошо такая архитектура.
Даже устаревшие браузеры предлагают нам набор возможностей для создания полнофункциональных интерактивных Web-приложений. А благодаря таким библиотекам как jQuery, которые предлагают не скромные кроссбраузерные и мультиплатформенные решения, разработка клиентских частей ускоряется во много раз. Чем веб-мастера и пользуются на полную катушку, используя при этом самые разнообразные интерфейсы для взаимодействия серверной и клиентской частей.
Почему jQuery? В данной статье я использую её просто для примера. Для взаимодействия клиентской и серверной частей приложений не важно, что вы используете: какую-либо библиотеку, собственную разработку или голый javascript. Главное – добиваться цели: чтобы все работало и работало правильно.
Конечно, многие из нас начинали изучение jquery с циклов статей для новичков, внедряя на свои сайты и динамическую подгрузку содержимого, и проверку форм на серверной части, и многое другое.
Со временем размер кода вырос: в проекте появилось множество обработчиков ответов от серверной части. Где-то запрашивается целая страница и из нее вырывается кусок контента, где-то идет запрос на различные файлы, где-то ожидается JSON, а кое-где XML. Все это надо прибирать, чтобы и кода было меньше, и работал он быстрее, и работать с ним было проще.
Во-первых. Создадим единый интерфейс отправки запросов.
Для этого обернем $.ajax в собственную сахарную функцию.
Конечно, $.ajax можно настроить через $.ajaxSetup. И это удобнее и практичнее. Но тогда возникает несколько проблем.
Я предпочитаю обернуть все в другую функцию. Пусть это не так практично, и порождает больше кода, но безопаснее при использовании. Другой программист, увидев незнакомую функцию, сразу обратит на нее внимание. И, возможно, посмотрев, как отправляется другой запрос, сделает также. А если не поймет, то ничто не помешает воспользоваться стандартной функцией $.ajax.
Во-вторых, надо сократить количество точек входа для AJAX запросов. Если запросы отправлялись и на index.php, и на request.pl, и на upload.xml, то это огромный объем работы, и нередко бывает, что сделать это невозможно не переписав заново всю серверную часть. Хотя это надо сделать, если хочется быстро и просто расширять клиентскую часть. Как и у всех правил, у этого есть исключения. О них чуть ниже.
В третьих, самое главное: необходимо унифицировать обработчик ответа.
Например, у нас в проекте все ajax-запросы идут только на файл ajax.php. Он всегда возвращает некоторые данные в виде XML, довольно просто структурированные.
Единый обработчик ответа парсит XML и раскладывает по полочкам:
• Список js-файлов, которые необходимы для обработки ответа.
• Сallback-функции, которые необходимо запустить, и какие аргументы в эти функции надо передать.
• Куски HTML-кода, которые будут применены в вышеуказанных функциях.
• Список css файлов, которые нужны для украшения html кода.
Когда все разложено, загружаем недостающие js-файлы. Возможно, один или несколько запрошенных скриптов уже были загружены ранее загружены, поэтому сначала проверяем это. Методы проверки зависят от общей архитектуры javascript кода.
Потом загружаем стили. Механизмы загрузки скриптов и стилей практически идентичны. Конечно, стили нужны только в момент отображения данных пользователю, но к этому моменту они должны быть уже загружены.
Когда все скрипты загружены, запускаем callback-функции.
Надо обратить внимание, что для ускорения загрузки все js файлы загружаются асинхронно, и соответственно здесь может возникнуть проблема с запуском callback-функций. Ведь они могут быть в этих файлах.
Решением этой проблемы может стать создание зависимостей функций от js файлов. Это, в свою очередь, порождает проблемы контроля этих зависимостей программистом и передаче их вместе с ответом клиентской стороне.
Второе решение — это дождаться загрузки абсолютно всех запрошенных файлов и уже потом начать выполнения функций.
Как сделать это красиво, можно послушать в этом чудесном подкасте habrahabr.ru/blogs/hpodcasts/138522
Я для своих проектов выбрал самое простое решение — второе. Я исходил и того, что подгрузка необходимых js файлов нужна крайне редко, потому что все скрипты объединяются на серверной стороне в пакеты. И обычно пакет заранее содержит все необходимые callback`и. А если подгрузка файлов и будет нужна, то потребует максимум один-два файла, что не сильно задержит обработку ответа.
Напомню, что пользователь к этому моменту все еще не видит изменений на экране. Что ж, покажем ему их — начнем выполнять функции. Главное, что стоит учитывать — все функции-обработчики ответа должны быть независимыми друг от друга. Они могут зависеть от одного крупного компонента (например, функций ядра проекта), но не должны друг от друга. Это позволит перемещать и интегрировать callback`и в другие части проекта без каких-либо особых заморочек. Например, выводить всплывающие окна с сообщениями об ошибках может потребоваться на всех страницах.
Функции выполнены, пользователь работает дальше.
Теперь я бы хотел разобрать ситуацию, когда был послан запрос, который сервер не смог разобрать по какой-то причине.
У нас все запросы не только посылаются на один файл, но и все данные в нем посылаются методом POST. На серверной стороне ожидается некоторый POST-параметр «action». Значение этого параметра определяет то, какой модуль сайта должен отработать. Сами пары с ожидаемыми значениями и именами модулей записаны в конфигурационном файле. Если в конфигурации есть соответствующий модуль – он запускается, если нет — запускается дефолтный модуль, который настроен на возврат сообщения об ошибке.
Также, мы можем записать в серверный лог все параметры запроса. Анализ лога потом позволит быстро отследить и исправить ошибку. Или во время выполнения скрипта забанить IP пользователя на минут 15 за перебор значений, если есть уверенность, что ошибок в нашем приложении нет. Но это уже крайность.
Нельзя забывать про обработку сорвавшихся запросов, например по таймауту или внезапному отключению пользователя от сети.
Вернемся к вопросу про точки входа. C точки зрения написания красивого кода, указывание только одного адреса для точки входа не совсем правильное решение. Это ни в коем случае не противоречит моему второму совету. Попробую разобрать все стороны данного вопроса.
Как можно было бы сделать все красиво? — Отправлять запросы на определенные адреса. Например, ajax.php?action=feedback или ajax.example.com/feedback. Это избавило бы запрос от лишнего мусора. Когда определен модуль, который будет обрабатывать данные, эта информация ему уже не нужна. Мухи отдельно, котлеты отдельно. Красиво? Красиво.
Если POST параметров в запросе вообще нет, то это хорошая возможность использовать возможности кэширования на промежуточных проксях или кэш браузера.
В рекомендациях от Google для Web-мастеров сказано, что отсутствие GET-параметров в http-запросе провоцирует прокси-сервера использовать кэш. Поэтому запрос без POST и GET параметров, например ajax.mysite.com/footer, будет идеальным для добавления его в кэш прокси сервером. Из дополнительных плюсов отмечу, что если ответ будет от прокси сервера, то это немного разгрузит и наш сервер.
Когда это вообще может понадобится? Когда мы подгружаем части страницы через ajax. При этом они являются неизменными в течение долгого времени.
Но использовать ajax-запрос без GET или POST параметров не стоит, раз существует вероятность получения не актуальных данных.
Предположим, что у нас чат и мы не используем веб-сокеты. Каждую секунду долбимся на сервер, чтобы посмотреть новые сообщения. Пользователь попался за каким-то прокси сервером. Первый запрос пройдет удачно и вернет, что сообщений нет. На все последующие запросы, прокси сервер будет возвращать первоначальный ответ. А это нарушит всю работу чата. Проблем поможет избежать добавление параметра в запрос. Что, в свою очередь, создаст тот самый мусор, которого мы так старались избежать.
В вопросах кэширования каждый раз нужно подходить индивидуально и использовать то, что необходимо для проекта.
В нашем проекте данные в запросе отправляется только методом POST, потому что механизм кэширования у нас заложен в том самом едином интерфейсе отправки ajax-запросов. По умолчанию абсолютно каждый запрос и ответ на него запоминается на 3600 секунд. При последующем аналогичном запросе отработает кэш, возьмет из коробочки ответ и запустит сразу все механизмы по его анализу, без отправки непосредственно запроса на сервер. Ведь мы уже уверены, что все стили и скрипты уже на месте.
Если запоминать пару запрос-ответ не нужно или надо просто уменьшить время жизни кэша, то серверная сторона сообщает об этом в первоначальном ответе, изменяя время кэша на 0 или другое количество секунд.
Почему только POST, а не совмещенный вариант? Так проще сравнивать запросы.
Данные отправляемые через функцию ajax в jQuery, это js-объект.
Запрошенные данные довольно быстро сравниваются перебором с объектами в кэше, конечно, если у клиента современный браузер. Если браузер старый, приходится принудительно отключать кэш.
В итоге мы получаем устойчиво работающую связку клиентской и серверной частей. И эта связка позволяет нам создавать безопасные и простые для дальнейшего расширения Web приложения.
Пост написан во имя спасения наносекунд и множества нервных клеток программистов, создающих свои прекрасные творения.
Клиентская структура
Даже устаревшие браузеры предлагают нам набор возможностей для создания полнофункциональных интерактивных Web-приложений. А благодаря таким библиотекам как jQuery, которые предлагают не скромные кроссбраузерные и мультиплатформенные решения, разработка клиентских частей ускоряется во много раз. Чем веб-мастера и пользуются на полную катушку, используя при этом самые разнообразные интерфейсы для взаимодействия серверной и клиентской частей.
Почему jQuery? В данной статье я использую её просто для примера. Для взаимодействия клиентской и серверной частей приложений не важно, что вы используете: какую-либо библиотеку, собственную разработку или голый javascript. Главное – добиваться цели: чтобы все работало и работало правильно.
Конечно, многие из нас начинали изучение jquery с циклов статей для новичков, внедряя на свои сайты и динамическую подгрузку содержимого, и проверку форм на серверной части, и многое другое.
Со временем размер кода вырос: в проекте появилось множество обработчиков ответов от серверной части. Где-то запрашивается целая страница и из нее вырывается кусок контента, где-то идет запрос на различные файлы, где-то ожидается JSON, а кое-где XML. Все это надо прибирать, чтобы и кода было меньше, и работал он быстрее, и работать с ним было проще.
Во-первых. Создадим единый интерфейс отправки запросов.
Для этого обернем $.ajax в собственную сахарную функцию.
Конечно, $.ajax можно настроить через $.ajaxSetup. И это удобнее и практичнее. Но тогда возникает несколько проблем.
- Внезапно может понадобиться отправить запрос, который бы являлся исключением из общих правил. Эту проблему легко решить, сбросив установленные настройки используя опцию «global» в значении «false».
Например так:
// где-то определяем глобальные настройки
$.ajaxSetup({
url: 'mysite.ru/ajax.php',
dataType: 'xml'
});
/* ...спустя много кода вызываем */
$.ajax({
url: 'ajax.mysite.ru',
data: {
action: 'do_something'
username: 'my_username'
},
global:false // сбрасываем настройки
});
- Вторая проблема может возникнуть при использовании ajaxSetup, когда доработка функционала будет отдана стороннему разработчику. Посмотрев код он увидит привычные для него функции $.ajax и не будет вникать, что где-то что-то глобальное переопределяется. А если и заметит, то нет никакой гарантии, что он не попытается что-то в нем поменять, и в результате, не сломает какой-нибудь старый кусок кода.
Я предпочитаю обернуть все в другую функцию. Пусть это не так практично, и порождает больше кода, но безопаснее при использовании. Другой программист, увидев незнакомую функцию, сразу обратит на нее внимание. И, возможно, посмотрев, как отправляется другой запрос, сделает также. А если не поймет, то ничто не помешает воспользоваться стандартной функцией $.ajax.
// расширяем
$.extend({
gajax: function(s) {
// наши настройки здесь
var options = {
url: "ajax.mysite.ru",
};
// объединяем настройки
$.extend( options, s, { action:s.action } );
$.ajax( options );
}
});
// вызываем
$.gajax({
data: {
username: 'my_username'
},
action: 'do_something'
});
Во-вторых, надо сократить количество точек входа для AJAX запросов. Если запросы отправлялись и на index.php, и на request.pl, и на upload.xml, то это огромный объем работы, и нередко бывает, что сделать это невозможно не переписав заново всю серверную часть. Хотя это надо сделать, если хочется быстро и просто расширять клиентскую часть. Как и у всех правил, у этого есть исключения. О них чуть ниже.
В третьих, самое главное: необходимо унифицировать обработчик ответа.
Например, у нас в проекте все ajax-запросы идут только на файл ajax.php. Он всегда возвращает некоторые данные в виде XML, довольно просто структурированные.
Единый обработчик ответа парсит XML и раскладывает по полочкам:
• Список js-файлов, которые необходимы для обработки ответа.
• Сallback-функции, которые необходимо запустить, и какие аргументы в эти функции надо передать.
• Куски HTML-кода, которые будут применены в вышеуказанных функциях.
• Список css файлов, которые нужны для украшения html кода.
// расширяем
$.extend({
gajax: function(s) {
var recognize = function( xml, s ) {
/* я сознательно описал только комментариями, потому что иначе получилось бы целое полотно */
// парсим xml (вообще jQuery сам парсит XML, так что этот пункт можно пропустить)
// смотрим есть ли в нем js-файлы, которые надо погрузить и начинаем их загружать
// смотрим есть ли стили, которые надо погрузить
// смотрим есть ли в нем callback`и
// ищем html
};
// наши настройки здесь
var options = {
url: "ajax.mysite.ru",
success: function(xml){
recognize( xml, s );
}
};
$.extend( options, s, { action:s.action } );
$.ajax( options );
}
});
Когда все разложено, загружаем недостающие js-файлы. Возможно, один или несколько запрошенных скриптов уже были загружены ранее загружены, поэтому сначала проверяем это. Методы проверки зависят от общей архитектуры javascript кода.
Потом загружаем стили. Механизмы загрузки скриптов и стилей практически идентичны. Конечно, стили нужны только в момент отображения данных пользователю, но к этому моменту они должны быть уже загружены.
Когда все скрипты загружены, запускаем callback-функции.
Надо обратить внимание, что для ускорения загрузки все js файлы загружаются асинхронно, и соответственно здесь может возникнуть проблема с запуском callback-функций. Ведь они могут быть в этих файлах.
Решением этой проблемы может стать создание зависимостей функций от js файлов. Это, в свою очередь, порождает проблемы контроля этих зависимостей программистом и передаче их вместе с ответом клиентской стороне.
Второе решение — это дождаться загрузки абсолютно всех запрошенных файлов и уже потом начать выполнения функций.
Как сделать это красиво, можно послушать в этом чудесном подкасте habrahabr.ru/blogs/hpodcasts/138522
Я для своих проектов выбрал самое простое решение — второе. Я исходил и того, что подгрузка необходимых js файлов нужна крайне редко, потому что все скрипты объединяются на серверной стороне в пакеты. И обычно пакет заранее содержит все необходимые callback`и. А если подгрузка файлов и будет нужна, то потребует максимум один-два файла, что не сильно задержит обработку ответа.
Напомню, что пользователь к этому моменту все еще не видит изменений на экране. Что ж, покажем ему их — начнем выполнять функции. Главное, что стоит учитывать — все функции-обработчики ответа должны быть независимыми друг от друга. Они могут зависеть от одного крупного компонента (например, функций ядра проекта), но не должны друг от друга. Это позволит перемещать и интегрировать callback`и в другие части проекта без каких-либо особых заморочек. Например, выводить всплывающие окна с сообщениями об ошибках может потребоваться на всех страницах.
Функции выполнены, пользователь работает дальше.
Обработка запросов сервером
Теперь я бы хотел разобрать ситуацию, когда был послан запрос, который сервер не смог разобрать по какой-то причине.
У нас все запросы не только посылаются на один файл, но и все данные в нем посылаются методом POST. На серверной стороне ожидается некоторый POST-параметр «action». Значение этого параметра определяет то, какой модуль сайта должен отработать. Сами пары с ожидаемыми значениями и именами модулей записаны в конфигурационном файле. Если в конфигурации есть соответствующий модуль – он запускается, если нет — запускается дефолтный модуль, который настроен на возврат сообщения об ошибке.
Также, мы можем записать в серверный лог все параметры запроса. Анализ лога потом позволит быстро отследить и исправить ошибку. Или во время выполнения скрипта забанить IP пользователя на минут 15 за перебор значений, если есть уверенность, что ошибок в нашем приложении нет. Но это уже крайность.
Обработка ошибочных запросов на клиентской стороне
Нельзя забывать про обработку сорвавшихся запросов, например по таймауту или внезапному отключению пользователя от сети.
// наши настройки здесь
var options = {
url: "ajax.mysite.ru",
success: function(xml){
recognize( xml, s );
},
error: function( s,err ){
// серверная ошибка
if ( s.status == 200 && err == 'parsererror' ) {
alert( s.responseText );
}
// Обрабатываем срыв запроса по таймауту
else if ( err == 'timeout' ) {
alert('Connection to the server was reset on timeout.');
}
// или из-за отсутствия подключения к сети.
else if ( s.status == 12029 || s.status == 0 ) {
alert('No connection with network.');
}
};
Кэширование
Вернемся к вопросу про точки входа. C точки зрения написания красивого кода, указывание только одного адреса для точки входа не совсем правильное решение. Это ни в коем случае не противоречит моему второму совету. Попробую разобрать все стороны данного вопроса.
Как можно было бы сделать все красиво? — Отправлять запросы на определенные адреса. Например, ajax.php?action=feedback или ajax.example.com/feedback. Это избавило бы запрос от лишнего мусора. Когда определен модуль, который будет обрабатывать данные, эта информация ему уже не нужна. Мухи отдельно, котлеты отдельно. Красиво? Красиво.
Если POST параметров в запросе вообще нет, то это хорошая возможность использовать возможности кэширования на промежуточных проксях или кэш браузера.
В рекомендациях от Google для Web-мастеров сказано, что отсутствие GET-параметров в http-запросе провоцирует прокси-сервера использовать кэш. Поэтому запрос без POST и GET параметров, например ajax.mysite.com/footer, будет идеальным для добавления его в кэш прокси сервером. Из дополнительных плюсов отмечу, что если ответ будет от прокси сервера, то это немного разгрузит и наш сервер.
Когда это вообще может понадобится? Когда мы подгружаем части страницы через ajax. При этом они являются неизменными в течение долгого времени.
Но использовать ajax-запрос без GET или POST параметров не стоит, раз существует вероятность получения не актуальных данных.
Предположим, что у нас чат и мы не используем веб-сокеты. Каждую секунду долбимся на сервер, чтобы посмотреть новые сообщения. Пользователь попался за каким-то прокси сервером. Первый запрос пройдет удачно и вернет, что сообщений нет. На все последующие запросы, прокси сервер будет возвращать первоначальный ответ. А это нарушит всю работу чата. Проблем поможет избежать добавление параметра в запрос. Что, в свою очередь, создаст тот самый мусор, которого мы так старались избежать.
В вопросах кэширования каждый раз нужно подходить индивидуально и использовать то, что необходимо для проекта.
Изобретая велосипед
В нашем проекте данные в запросе отправляется только методом POST, потому что механизм кэширования у нас заложен в том самом едином интерфейсе отправки ajax-запросов. По умолчанию абсолютно каждый запрос и ответ на него запоминается на 3600 секунд. При последующем аналогичном запросе отработает кэш, возьмет из коробочки ответ и запустит сразу все механизмы по его анализу, без отправки непосредственно запроса на сервер. Ведь мы уже уверены, что все стили и скрипты уже на месте.
Если запоминать пару запрос-ответ не нужно или надо просто уменьшить время жизни кэша, то серверная сторона сообщает об этом в первоначальном ответе, изменяя время кэша на 0 или другое количество секунд.
Почему только POST, а не совмещенный вариант? Так проще сравнивать запросы.
Данные отправляемые через функцию ajax в jQuery, это js-объект.
Запрошенные данные довольно быстро сравниваются перебором с объектами в кэше, конечно, если у клиента современный браузер. Если браузер старый, приходится принудительно отключать кэш.
В итоге
В итоге мы получаем устойчиво работающую связку клиентской и серверной частей. И эта связка позволяет нам создавать безопасные и простые для дальнейшего расширения Web приложения.
Пост написан во имя спасения наносекунд и множества нервных клеток программистов, создающих свои прекрасные творения.
