клиентская часть приложения это

Стек технологий для разработки веб-приложений: что важно знать бизнесу

Время чтения: 10 минут

Отправим вам статью на:

Один из наиболее важных шагов, которые нужно предпринять, когда дело доходит до разработки приложения, — это выбрать правильный стек технологий. Этот вопрос значительно влияет на успех проекта, как в краткосрочной, так и долгосрочной перспективе. Почему? Стек технологий для разработки веб-приложений влияет на стоимость проекта, сроки выпуска продукта на рынок, безопасность и масштабируемость приложения. Грамотно подобранный стек позволяет получить стабильный, безопасный и удобный в обслуживании продукт, который не только завоюет сердца ваших клиентов, но и позволит вам масштабировать бизнес.

Веб-приложение: что такое, из чего состоит, виды

С точки зрения архитектуры веб-приложения состоят из двух частей: клиентской и серверной. Клиентская часть также называется фронтэнд. По сути это то, что пользователи видят на экране устройства. Серверная часть, или бэкенд — программно-аппаратная часть сервиса. Это набор средств, которые реализуют логику приложения.

Взаимодействие клиентской и серверной частей веб-приложения

Клиентская часть приложения

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

Рассмотрим основные компоненты стека интерфейсов.

Каскадные таблицы стилей (CSS) — это язык разметки, который определяет оформление и макет элементов HTML. Таким образом, HTML задаёт структуру, а CSS — стиль. С помощью CSS задаются шрифты, цвета, стили, расположение отдельных элементов, а также отображение страниц на разных устройствах.

JavaScript

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

Чтобы эффективнее разрабатывать на JavaScript, разработчики используют фреймворки, которые также являются важной составляющей технологического стека. Фреймворк — это рабочая среда, своего рода каркас, который помогает эффективнее создавать и поддерживать программные продукты. Далее мы перечислим некоторые из фреймворков и библиотек, которые мы обычно используем в проектах.

Популярные фреймворки и библиотеки JavaScript

Одна из ключевых особенностей React — универсальность. Эту библиотеку можно использовать на сервере и на мобильных платформах с помощью React Native.

Ещё одна важная особенность библиотеки — декларативность. С помощью React разработчик описывает, как компоненты интерфейса выглядят в разных состояниях. Декларативный подход сокращает код и делает его понятным.

Angular — это фреймворк от компании Google. Прежде всего он нацелен на разработку SPA-решений.

Эта среда разработки известна прежде всего потому, что она предоставляет разработчикам лучшие условия для объединения JavaScript с HTML и CSS. К веб приложениям на Angular.js относятся Google и Youtube.

Vue — это прогрессивный фреймворк для создания пользовательских интерфейсов. В отличие от фреймворков-монолитов, Vue подходит для постепенного внедрения. Он легко интегрируется с другими библиотеками и существующими проектами. Также Vue пригоден, чтобы создавать сложные одностраничные приложения, если использовать его совместно с современными инструментами и дополнительными библиотеками.

Серверная часть приложения

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

Задача серверной разработки — сделать так, чтобы ответ от сервера доходил до клиента и спроектированные блоки функционировали нужным образом. А также создать для заказчика удобную и безопасную среду для наполнения и обновления контента на сайте.

PHP в основном применяется, чтобы «оживить» статичные HTML страницы. Почти всегда пользователи приходят на сайт за информацией, которая всё время меняется, и нужно отображать её актуальное состояние. Например, показать прогноз погоды. Если использовать только HTML, то решить такие задачи не получится. Здесь может помочь PHP: он принимает входящий запрос от веб-сервера, выполняет сценарий и возвращает результат в виде готового HTML-кода. Сервер отправляет этот результат в браузер пользователю, который, в свою очередь, отображает её пользователю. После этого пользователь видит актуальный прогноз погоды.

Для создания веб-приложений на PHP мы используем фреймворк Laravel. Его особенности: поддерживает функциональное, интеграционное и юнит-тестирование, позволяет легко масштабировать приложения, следует лучшим практикам разработки и предлагает большой выбор шаблонов проектирования. Всё это помогает поддерживать чистую, минималистичную и эффективную кодовую базу, которую легко модифицировать.

Также из PHP фреймворков применяем Yii2 и Symfony.

Для разработки веб-приложений на Java мы используем фреймворк Spring. Он обеспечивает комплексную модель разработки и конфигурации для современных бизнес-приложений: от ecommerce-проектов до крупных порталов, от образовательных платформ до правительственных ресурсов. Ключевой элемент Spring — поддержка инфраструктуры на уровне приложения, поэтому разработчики могут сосредоточиться на бизнес-логике без лишних настроек в зависимости от среды исполнения.

Также из фреймворков Java применяем Hibernate. Он упрощает разработку Java приложения для взаимодействия с базой данных.

Node.js

Node.js — кроссплатформенная среда, которая выполняет код JavaScript вне браузера. Node.js позволяет разработчикам использовать JavaScript, чтобы получить инструменты командной строки. На стороне сервера с его помощью можно запускать сценарии для обработки динамического содержимого веб-страницы, перед тем как она будет доступна в веб-браузере пользователя.

Базы данных в разработке веб-приложений

Также веб-приложению требуется место для хранения данных, и для этого используется база данных. Существует два типа баз данных: реляционные и нереляционные. Различия между ними заключаются в том, как они спроектированы, какие типы данных поддерживают, как хранят информацию.

Реляционные БД хранят структурированные данные, которые обычно представляют объекты реального мира. Например, это могут быть сведения о человеке или о содержимом корзины для товаров в магазине, сгруппированные в таблицах, формат которых задан на этапе проектирования хранилища.

Нереляционные БД устроены иначе. Например, документо-ориентированные базы хранят информацию в виде иерархических структур данных. Речь может идти об объектах с произвольным набором атрибутов. То, что в реляционной БД будет разбито на несколько взаимосвязанных таблиц, в нереляционной может храниться в виде целостной сущности.

Внутреннее устройство различных систем управления базами данных влияет на особенности работы с ними. Например, нереляционные базы лучше поддаются масштабированию.

В инфографике ниже мы собрали основные технологии разработки веб-приложений, которые мы используем.

Заключение

Подпишитесь

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

Источник

Термины «фронтенд», «клиентская сторона» и «интерфейс» — как употреблять и не облажаться

До работы редактором и контент-маркетологом в компании Лайв Тайпинг я два года занимался гуманитарными текстами: редактировал и писал статьи про моду, музыку, кино, изобразительное искусство, социологию и тому подобное. От меня требовалось не столько корректно донести смысл, сколько добиться яркого образа, создать настроение и подарить читателю эмоцию. Это развязывает руки в отношениях со словами: прежде имевшие точный смысл, они становятся сырьём для аллегорий, метафор и других литературных приёмов.

Попав в техническую среду, я понял, что словесные украшательства мешают функции. Вместе с трендом инфостиля это заставило меня пересмотреть подход к работе с текстами. В том числе пришло время вспомнить, что у каждого термина есть своё значение.

При работе над кейсом проекта Designet я поймал себя на том, что считаю термины «фронтенд», «клиентская сторона» и «интерфейс» синонимами. Чтобы расставить все точки над i и больше их не путать, я написал эту памятку. Надеюсь, что она поможет не только мне, но и коллегам — редакторам, копирайтерам, техническим журналистам, маркетологам, менеджерам проектов и всем, кто не имеет прямого отношения к программированию.

Интерфейс

Всё, что помогает человеку управлять инструментом, будь то программа, компьютер, бытовой прибор или панель заводского станка — это интерфейс. Элементами интерфейса являются меню, кнопки, клавиатура, мышь, монитор, переключатели, тумблеры, тулбары, поля для набора текста, экраны с ошибками и прочие способы взаимодействия и ввода/вывода информации. Применительно к интерфейсу программ и приложений в английском языке встречается словосочетание user interface (UI).

Интерфейс — это всё, что вы видите и что можете потрогать.

Интерфейс может быть удобным и неудобным. Критерием удобного интерфейса по сегодняшним меркам считается короткая череда действий, которая не бесит, не смущает, не выматывает и в итоге даёт желаемое. Сумма ощущений от пользования интерфейсом называется опытом взаимодействия, пользовательским опытом или user experience (UX). Он тоже может быть плохим или хорошим.

Интерфейс поисковой страницы Google — пример интерфейса с UX уровня «дзен».

Файловый менеджер FileMatrix — пример ужасного интерфейса из обсуждения на Stack Overflow. Не лезь, он тебя сожрёт.

Чем больше в интерфейсе действий, тем дольше пользователю придётся продираться к функциональностям программы, сайта или приложения, и тем быстрее он плюнет на это и пойдёт искать интерфейс с единственной кнопкой, приносящей результат.

Фронтенд

Если интерфейс — это прослойка между пользователем и кодом, запускающая последний в работу, то фронтенд — это тот самый код и есть. Возьмём, например, какую-нибудь страницу «Википедии». Чтобы открыть её, мы даём команду браузеру: «А покажи». Браузер запрашивает у внешнего сервера строительный материал страницы — код. Этот код исполняется на странице и рисует то, что вы попросили у браузера.

Стоит заметить, что часто под фронтендом понимают веб-разработку. Из-за двойственности в определении существует спор, как писать этот термин по-английски: раздельно или через дефис. Свет на проблему проливает эта публикация.

Фронтенд складывается из взаимодействия трёх технологий:

Одно нажатие F12, и страница показывает всё, что под ней спрятано.

Клиентская сторона

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

Этих клиентов уже никто не обслужит.

Понятие о клиентской стороне вышло из парадигмы клиент-серверной архитектуры. Она появилась вместе с первыми компьютерными сетями: разработчики решили, что часть общих ресурсов можно хранить за пределами устройства. Устройство в таком случае — это клиент: он получает данные от внешнего сервиса, отрисовывает их в себе и отправляет вносимые изменения обратно на сервис.

Закрепление

Клиент — это устройство для оперирования удалёнными данными.
Интерфейс — это набор элементов для управления программой или устройством
Фронтенд — это код, принятый клиентом, запущенный на нём и ставший интерфейсом, или веб-разработка на клиентской стороне как таковая.

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

Источник

Архитектура взаимодействия клиентской и серверной частей Web приложения

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

Клиентская структура

Даже устаревшие браузеры предлагают нам набор возможностей для создания полнофункциональных интерактивных Web-приложений. А благодаря таким библиотекам как jQuery, которые предлагают не скромные кроссбраузерные и мультиплатформенные решения, разработка клиентских частей ускоряется во много раз. Чем веб-мастера и пользуются на полную катушку, используя при этом самые разнообразные интерфейсы для взаимодействия серверной и клиентской частей.

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

Со временем размер кода вырос: в проекте появилось множество обработчиков ответов от серверной части. Где-то запрашивается целая страница и из нее вырывается кусок контента, где-то идет запрос на различные файлы, где-то ожидается JSON, а кое-где XML. Все это надо прибирать, чтобы и кода было меньше, и работал он быстрее, и работать с ним было проще.

Во-вторых, надо сократить количество точек входа для 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 приложения.

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

Источник

Как работают веб-приложения

1. Чем веб-приложения отличаются от сайтов

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

Сайты содержат различную статику, которая как и HTML-файл не генерируется на лету. Чаще всего это картинки, CSS-файлы, JS-скрипты, но могут быть и любые другие файлы: mp3, mov, csv, pdf.

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

А веб-приложение — это что-то технически более сложное. Тут HTML-страницы генерируются на лету в зависимости от запроса пользователя. Почтовые клиенты, соцсети, поисковики, интернет-магазины, онлайн-программы для бизнеса, это все веб-приложения.

2. Какие бывают веб-приложения

Веб-приложения можно разделить на несколько типов, в зависимости от разных сочетаний его основных составляющих:

3. Pyhon-фреймворк Django aka бэкенд

В разработке фреймворк — это набор готовых библиотек и инструментов, которые помогают создавать веб-приложения. Для примера опишу принцип работы фреймворка Django, написанного на языке программирования Python.

Первым этапом запрос от пользователя попадает в роутер (URL dispatcher), который решает какую функцию для обработки запроса надо вызвать. Решение принимается на основе списка правил, состоящих из регулярного выражения и названия функции: если такой-то урл, то вот такая функция.

Функция, которая вызывается роутером, называется вью (view). Внутри может содержаться любая бизнес-логика, но чаще всего это одно из двух: либо из базы берутся данные, подготавливаются и возвращаются на фронт; либо пришел запрос с данными из какой-то формы, эти данные проверяются и сохраняются в базу.

Данные приложения хранятся в базе данных (БД). Чаще всего используются реляционные БД. Это когда есть таблицы с заранее заданными колонками и эти таблицы связаны между собой через одну из колонок.

Данные в БД можно создавать, читать, изменять и удалять. Иногда для обозначения этих действий можно встретить аббревиатуру CRUD (Create Read Update Delete). Для запроса к данным в БД используется специальный язык SQL (structured query language).

В Джанго для работы с БД используются модели (model). Они позволяют описывать таблицы и делать запросы на привычном разработчику питоне, что гораздо удобнее. За это удобство приходится платить: такие запросы медленнее и ограничены в возможностях по сравнению с использованием чистого SQL.

Полученные из БД данные подготавливаются во вью к отправке на фронт. Они могут быть подставлены в шаблон (template) и отправлены в виде HTML-файла. Но в случае одностраничного приложения это происходит всего один раз, когда генерируется HTML-страница, на который подключаются все JS-скрипты. В остальных случаях данные сериализуются и отправляются в JSON-формате.

4. Javascript-фреймворки aka фронтенд

Клиентская часть приложения — это скрипты, написанные на языке программирования Javascript (JS) и исполняемые в браузере пользователя. Раньше вся клиентская логика основывалась на использовании библиотеки JQuery, которая позволяет работать с DOM, анимацией на странице и делать AJAX запросы.

DOM (document object model) — это структура HTML-страницы. Работа с DOM — это поиск, добавление, изменение, перемещеие и удаление HTML-тегов.

AJAX (asynchronous javascript and XML) — это общее название для технологий, которые позволяют делать асинхронные (без перезагрузки страницы) запросы к серверу и обмениваться данными. Так как клиентская и серверная части веб-приложения написаны на разных языках программирования, то для обмена информацией необходимо преобразовывать структуры данных (например, списки и словари), в которых она хранится, в JSON-формат.

JSON (JavaScript Object Notation) — это универсальный формат для обмена данными между клиентом и сервером. Он представляет собой простую строку, которая может быть использована в любом языке программирования.

Сериализация — это преобразование списка или словаря в JSON-строку. Для примера:

Десериализация — это обратное преобразование строки в список или словарь.

С помощью манипуляций с DOM можно полностью управлять содержимым страниц. С помощью AJAX можно обмениваться данными между клиентом и сервером. С этими технологиями уже можно создать SPA. Но при создании сложного приложения код фронтенда, основанного на JQuery, быстро становится запутанным и трудно поддерживаемым.

К счастью, на смену JQuery пришли Javascript-фреймворки: Backbone Marionette, Angular, React, Vue и другие. У них разная философия и синтаксис, но все они позволяют с гораздо большим удобством управлять данными на фронтенде, имеют шаблонизаторы и инструменты для создания навигации между страницами.

HTML-шаблон — это «умная» HTML-страница, в которой вместо конкретных значений используются переменные и доступны различные операторы: if, цикл for и другие. Процесс получения HTML-страницы из шаблона, когда подставляются переменные и применяются операторы, называется рендерингом шаблона.

Полученная в результате рендеринга страница показывается пользователю. Переход в другой раздел в SPA это применение другого шаблона. Если необходимо использовать в шаблоне другие данные, то они запрашиваются у сервера. Все отправки форм с данными это AJAX запросы на сервер.

5. Как клиент и сервер общаются между собой

Общение клиента с сервером происходит по протоколу HTTP. Основа этого протокола — это запрос от клиента к серверу и ответ сервера клиенту.

Для запросов обычно используют методы GET, если мы хотим получить данные, и POST, если мы хотим изменить данные. Еще в запросе указывается Host (домен сайта), тело запроса (если это POST-запрос) и много дополнительной технической информации.

Современные веб-приложения используют протокол HTTPS, расширенную версию HTTP с поддержкой шифрования SSL/TLS. Использование шифрованного канала передачи данных, независимо от важности этих данных, стало хорошим тоном в интернете.

Есть еще один запрос, который делается перед HTTP. Это DNS (domain name system) запроc. Он нужен для получения ip-адреса, к которому привязан запрашиваемый домен. Эта информация сохраняется в браузере и мы больше не тратим на это время.

Когда запрос от браузера доходит до сервера, он не сразу попадает в Джанго. Сначала его обрабатывает веб-сервер Nginx. Если запрашивается статический файл (например, картинка), то сам Nginx его отправляет в ответ клиенту. Если запрос не к статике, то Nginx должен проксировать (передать) его в Джанго.

К сожалению, он этого не умеет. Поэтому используется еще одна программа-прослойка — сервер приложений. Например для приложений на питоне, это могут быть uWSGI или Gunicorn. И вот уже они передают запрос в Джанго.

После того как Джанго обработал запрос, он возвращает ответ c HTML-страницей или данными, и код ответа. Если все хорошо, то код ответа — 200; если страница не найдена, то — 404; если произошла ошибка и сервер не смог обработать запрос, то — 500. Это самые часто встречающиеся коды.

6. Кэширование в веб-приложениях

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

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

Источник