У першій частині статті пояснювалося, як працює веб-сторінка на стороні клієнта.
Тепер давайте подивимося, що відбувається на стороні сервера.
Частина ІІ
Сторона сервера: форми та бази даних
1. Форми
Поки що ми говорили лише про відновлення даних сервера. А як щодо надсилання даних? Форми — це інша сторона HTML: вони дозволяють нам надсилати інформацію на сервер. Ми можемо використовувати форми для оновлення наявної інформації або для додавання нової інформації.
Найпоширенішими методами у формах HTML є GET et POST.

Подивіться на код вище :
У нас є два поля введення (вхід), де користувач може ввести дані та кнопку надіслати (представляти).
Після того, як користувач натисне цю кнопку, браузер надсилає значення даних, введені в два поля, до сценарію PHP під назвою createproduct.php.
У нашому прикладі це PHP, але це може бути JSP, Python або будь-яка інша серверна мова сценаріїв. Скрипт на стороні сервера може прочитати значення, надіслані браузером за допомогою методу POST, потім обробити їх або зберегти у файлі чи базі даних. Коротше кажучи, це спосіб надсилання даних на сервер перед збереженням.
Що таке PHP?
PHP для Препроцесор гіпертексту, — це мова сценаріїв на стороні сервера для створення динамічних веб-сайтів і програм. Іншими словами: це мова, яка дає можливість отримати доступ до бази даних і читати її, а потім транскрибувати її інформацію на сторінці HTML.
Примітка: Скажімо, ми хочемо додати перевірки перед надсиланням даних — наприклад, назва продукту має містити щонайменше 5 символів або поле «SKU» не повинно бути порожнім. Ми можемо використовувати JavaScript для цих перевірок. Потім нам доведеться відреагувати на подію натискання кнопки відправки та перевірити, чи є у веб-елементах потрібні дані. Якщо чогось не вистачає, ми можемо відобразити повідомлення про помилку та припинити надсилання даних на сервер.
2. Бази даних
Як тільки кількість інформації починає зростати, отримання її з файлів може стати дуже складним і дуже повільним. Наприклад, візьмемо файл прайс-листа, припустимо, що компанія має тисячі продуктів, і ми хочемо знати інформацію про останній продукт у списку — це означає, що нам потрібно прочитати всі продукти до того, що ми знаходимо. шукаю. Це не оптимальний спосіб отримання інформації. Саме для вирішення цієї проблеми були створені бази даних.
У базі даних (БД) ми зберігаємо дані в таблицях (структурований набір даних). Таким чином, ми можемо легко виконувати пошук, сортувати дані або виконувати будь-які інші операції.
3. Серверні мови сценаріїв і фреймворки
Для цього нам потрібні серверні мови сценаріїв :
- зберігати та читати інформацію з бази даних або файлу;
- отримати (GET) інформація від сервера шляхом виконання певних операцій;
- прочитати інформацію, надіслану клієнтом (POST) і зберігати або поширювати їх, виконуючи певні операції з обробки.
Типові мови програмування, такі як C і Java, можуть читати та записувати в бази даних, але їх не можна запускати безпосередньо у веб-браузері (клієнті). Це породило серверні мови сценаріїв.
Мови сценаріїв на стороні сервера можуть виконувати всю звичайну обробку даних, взаємодіяти з базами даних і працювати на веб-сервері. Найпоширенішими мовами сценаріїв на стороні сервера є PHP, Perl, JSP, Ruby on Rails тощо.
Розробники почали використовувати ці мови, і незабаром вони зрозуміли, що пишуть один і той же шаблонний код для всіх проектів, що призвело до розробки каркаси які полегшують і прискорюють розробку веб-додатків.
Деякі відомі фреймворки :
- PHP: Zend, YII, Symfony, CakePHP, Laravel;
- CMS PHP (також використовується як фреймворки): Drupal, Joomla, SugarCRM, WordPress;
- Java : J2EE, Hibernate, Struts, Spring;
- JavaScript : Node.js.
4. Архітектура та сеанси MVC
Архітектура MVC допомагає нам розділити код на кілька файлів і дозволяє відокремити бізнес-логіку від презентації, щоб полегшити їх зміну пізніше.
На прикладі платформи для ведення блогів ми повернемося до всіх описаних раніше тем, щоб побачити, як ми можемо кодувати за допомогою архітектури MVC.
Платформа для блогів керує динамічним вмістом і може містити кілька модулів, наприклад :
- Користувачі (користувачі);
- Предмети (блогах);
- Ключові слова / теги (теги);
- Категорії (категорії).
Перш ніж говорити про інші функції, давайте уявімо дизайн бази даних для таблиці Матеріали (tbl_blog_post). Важливі поля були б :

Як бачите, ми зберігаємо повторювані дані користувача: ім’я (Ім'я) та прізвище (Прізвище) повторити вміст поля Створений. Якщо у нас є 10 000 дописів у блозі, ми будемо зберігати цю повторювану інформацію про користувача в кожній із 10 000 публікацій. Також може бути інша інформація про користувача для збереження, наприклад, його роль, дата останнього входу тощо.
Альтернативою, як ви вже здогадалися, є збереження цієї інформації користувача в іншій таблиці Користувач (tbl_user) і зв’язати це зі статтями (tbl_blog_post) за ідентифікатором, як показано нижче :

Це поділ даних на кілька таблиць є одним із багатьох принципів нормалізація даних.
Наступна важлива частина — дозволити користувачеві вставляти дані в ці таблиці за допомогою HTML-форми. Пам’ятайте, що ми докладно описуємо ці кроки, щоб зрозуміти концепції — це аж ніяк не повний посібник із програмування.
Створення нової публікації в блозі автентифікованим користувачем
Для цього нам знадобиться форма HTML з двома полями введення (Назва, зміст), за допомогою якого користувач може створити статтю.
Після того, як користувач введе інформацію та натисне кнопку відправки «Створити статтю», значення форми надсилаються на веб-сервер за допомогою методу POST. Цінності надіслані POST може бути прочитаний будь-якою мовою сценаріїв на стороні сервера. Серверний скрипт (PHP, Ruby on Rails, Python тощо) зчитує значення з форми та передає його в базу даних.
Сценарій також може обробляти інформацію, яка може бути для отримання дати і часу з сервера або для виконання певних обчислень на основі значень, витягнутих з іншої таблиці в базі даних або з іншого сервісу.web.
Ще один момент, на який варто звернути увагу: сценарій також може виконувати перевірки, які також називають перевірками на стороні сервера, щоб переконатися, що дані є дійсними. Тільки якщо дані дійсні, вони зберігаються в таблиці tbl_blog_post. В іншому випадку клієнту надсилається повідомлення про помилку для введення відсутньої інформації.
Візуально форма для отримання даних з нашої таблиці tbl_blog_post може виглядати як інтерфейс створення публікацій WordPress :

Є поле для введення назви (назва), потім поле введення вмісту (зміст).
Дата створення (Створено в), зі свого боку, динамічно витягується мовою сценаріїв (тут PHP) і відповідатиме точному моменту створення статті (ріку, місяці, дню, годині, хвилині і навіть секунді).
Інші дані, які вводити не потрібно: ідентифікатор статті (ID). Він генерується автоматично базою даних, що гарантує, що він є унікальним у тій самій таблиці.
В нашій таблиці tbl_blog_post, окрім назви та вмісту, у нас також є поле під назвою створений.
Як отримати значення для заповнення цього поля?
Підключений / автентифікований користувач
Як правило, більшість веб-програм мають функцію входу. Кожного разу, коли користувач успішно аутентифікується, інформація цього користувача зберігається в сеансах, щоб потім інформацію можна було використовувати повторно.
Що таке сесія?
HTTP є протоколом без стану, що означає відсутність запиту GET ou POST надіслані клієнтом на веб-сервер не відстежується. Якщо клієнт (браузер) робить два запити, веб-сервер не знає, чи надходять вони від одного користувача. Це також означає, що, наприклад, якщо ви підключені до сайту електронної комерції та додаєте продукти до свого кошика, сервер не знає, що вони призначені для того самого користувача.
Щоб подолати цю відсутність громадянства, клієнти повинні надсилати додаткову інформацію в кожному своєму запиті, щоб зберегти інформацію про сеанс протягом кількох запитів. Ця додаткова інформація зберігається на стороні клієнта в файлах cookie, а на стороні сервера — у сеансах.
Сесія — це масив змінних, в якому зберігається інформація для використання на кількох сторінках. Сеанси ідентифікуються за допомогою унікального ідентифікатора, назва якого залежить від мови — у PHP це називається «Ідентифікатор сесії PHP”. Цей самий ідентифікатор сеансу має бути збережений у файлі cookie у браузері, щоб бути пов’язаним із користувачем.
Показати один елемент
Наступним кроком є відображення дописів блогу окремо. Нам потрібно прочитати дані з бази даних на основі ідентифікатора публікації (ID) запитаної статті, потім відобразіть значення полів заголовка (назва) і вміст (зміст).
Ось псевдокод для відображення однієї публікації :
- Прочитайте дані бази даних, пов’язані з ідентифікатором елемента.
- Вставте ці дані на сторінку HTML, що містить CSS і JS.
Весь наведений вище код можна записати в один файл. Насправді так це було зроблено спочатку, але спільнота розробників зрозуміла, що це не оптимально. Справді, для додавання кожної нової функції весь код доводилося змінювати, а працювати в середовищі кількох розробників було непросто.
Це змусило веб-розробників прийняти архітектуру MVC, яка по суті розбиває код на три компоненти :
- Le Modele : Це бізнес-логіка, яка не залежить від інтерфейсу користувача. У нашому прикладі це код, який витягує статті з бази даних.
- Переглянути : Перегляд візуального представлення даних. У нашому прикладі статті відображаються HTML-кодом. Отже, дані надходять з моделі, а HTML – це представлення.
- Контролер : Викликається при натисканні на посилання «Подивитися статтю». Контролер отримує дані з бази даних за допомогою моделі та відображає їх у поданні.
Давайте подивимося на типову URL-адресу для програми, що використовує архітектуру MVC.
http://www.abc.com/blogpost/id/1
тут блогпост - ім'я контролера, а представлення - дія (метод) цього контролера. id є ідентифікатором елемента. Якщо ми введемо цю URL-адресу в браузері, запит перейде до дії «Перегляд» контролера «BlogPost» і викличе туди модель, щоб отримати вміст статті з ідентифікатором «1» у вигляді « об'єкт. Потім цей об’єкт передається до «Перегляд», який буде відображатися.
Точніше: наступна URL-адреса https://www.ux-republic.com/blog/page/2 відображає другу сторінку списку всіх публікацій блогу UX-Republic.
Розбив URL-адресу, ми маємо :
- блозі, контролер
- сторінка, ідентифікатор, що позначає номер сторінки
- 2, номер сторінки

Кожен раз, коли натискається сторінка, це той самий метод контролера блозі який виконується і відповідає за отримання вмісту, що відповідає сторінка selectionnée.
Ajax і односторінкові програми (SPA)
Якщо ви народилися в минулому тисячолітті, ви повинні пам’ятати про постачальників веб-пошти Hotmail і Yahoo!, які були дуже популярні в 1990-х і 2000-х роках. Коли ви натискали на папку «Вхідні» або на електронний лист, вся сторінка оновлювалася. Приблизно у 2004 році Gmail з’явився з важливою функцією: Ajax. У Ajax не оновлюється вся сторінка — оновлюються лише ті частини, які цього потребують. Отже, якщо ви отримаєте новий електронний лист, ви просто побачите його вгорі сторінки, не перезавантажуючи його. Це допомогло надати користувачам кращий досвід перегляду, і Ajax став дуже популярним способом створення програм.
Що таке Ajax?
Термін Ajax являє собою велику групу веб-технологій, які можуть бути реалізовані в програмі, яка взаємодіє з сервером у фоновому режимі, не заважаючи поточному стану сторінки.
За допомогою Ajax ви надсилаєте запит за допомогою GET на сервер, і сервер надсилає свою відповідь без блокування веб-сторінки, що означає, що користувач може продовжувати перегляд без будь-яких перерв. Відповідь сервера вставляється або додається до поточної веб-сторінки.
На сайтах, які не використовують Ajax, кожна дія користувача вимагає повного перезавантаження сторінки з сервера. Цей процес неефективний і створює поганий досвід користувача, оскільки весь вміст на сторінці зникає, перш ніж знову з’являтися.
Ajax є одним із методів, що використовуються для створення односторінкових програм (Односторінкові програми ou СПА). Як випливає з назви, весь додаток розміщується на одній сторінці, а весь його вміст завантажується динамічно. Для цього можна використовувати такі фреймворки JavaScript, як Angular, React і Backbone.js СПА.
Сервери та веб-браузери
Браузери є інтерпретаторами Інтернету. Вони запитують дані від веб-серверів, які обробляють запит і надсилають відповідь браузеру в HTML (з CSS, JS, зображеннями тощо), і ця відповідь потім відображається.
Запит до веб-сервера можна зробити одним із трьох важливих методів :
- GET : отримати запитуваний ресурс як відповідь;
- ГОЛОВА : такий же, як GET, але ресурс витягується в заголовку відповіді;
- POST : відправити дані на сервер.
Наприклад, коли ви вводите «google.com» у браузері, браузер надсилає цю команду на сервер google.com у фоновому режимі:
ОТРИМАТИ: http://google.com
Потім веб-сервер Google перегляне свій основний файл (індекс) і поверне відповідь клієнту. Зазвичай він надсилає вміст HTML і файли CSS разом з будь-якими іншими медіа-файлами.
# Переклад статті Зрозумійте веб-розробку менше ніж за 1 годинуЗа Шейк Ісмаїл
Одрі Гене, DEV-FRONT @UX-Republic

