031.2 Урок 1

Існують мобільні застосунки та програми для настільних ПК, інтерфейс яких відтворюється з HTML і, на зразок браузерів, можуть використовувати JavaScript як мову програмування. Однак на відміну від клієнта, завантаженого в браузері, HTML і необхідні компоненти для роботи нативного (рідного) клієнта присутні локально з моменту встановлення програми. Насправді, застосунок, який працює таким чином, є практично ідентичним HTML-сторінці (обидва, швидше за все, будуть відтворені одним і тим самим двигуном). Існують також прогресівні вебзастосунки (PWA, Progressive Web Apps), механізм, який дає змогу упаковувати клієнта вебзастосунка для використання в автономному режимі, обмежені функціями, які не вимагають негайного зв’язку із сервером. Щодо можливостей застосунку, то немає різниці між запуском у браузері чи запакованим у PWA, за винятком того, що в останньому варіанті розробник має більше контролю над тим, що зберігається локально.

Відтворення інтерфейсів із HTML є такою періодичною діяльністю, що двигун зазвичай є окремим програмним компонентом, присутнім в операційній системі. Його наявність як окремого компонента дає змогу різним програмам включати його без необхідності вбудовування до пакунку застосунку. Ця модель також делегує підтримку двигуна візуалізації операційній системі, полегшуючи його оновлення. Дуже важливо підтримувати настільки важливий компонент в актуальному стані для уникнення можливих збоїв.

Незалежно від способу доставки, застосунки, написані на HTML, працюють на рівні абстракції, створеному двигуном, який функціонує як ізольоване середовище виконання. Зокрема, у випадку з клієнтом, який працює у браузері, застосунок має у своєму розпорядженні лише ті ресурси, які пропонує браузер. Основні функції, такі як взаємодія з елементами сторінки та запит файлів через HTTP, завжди доступні. Ресурси, які можуть містити конфіденційну інформацію, наприклад доступ до локальних файлів, географічне розташування, камера та мікрофон, вимагають явної авторизації користувача, перш ніж застосунок зможе їх використовувати.

Центральним елементом клієнта вебзастосунку, який працює на сервері, є HTML-документ. На додаток до представлення елементів інтерфейсу, які браузер відображає в структурованому вигляді, HTML-документ містить адреси всіх файлів, необхідних для правильного представлення та роботи клієнта.

Сам по собі HTML не має великої універсальності для створення більш складних інтерфейсів і не має функцій програмування загального призначення. Із цієї причини HTML-документ, який повинен функціонувати як клієнтська програма, завжди супроводжується одним або кількома наборами CSS і JavaScript.

CSS може бути в окремому файлі або безпосередньо в самому файлі HTML. Основне призначення CSS – налаштувати зовнішній вигляд і розташування елементів інтерфейсу HTML. Хоча це не є суворою необхідністю, більш складні інтерфейси зазвичай вимагають модифікації CSS-властивостей елементів відповідно до їхніх потреб.

JavaScript є практично обов’язковим компонентом. Процедури, написані на JavaScript, відповідають на події в браузері. Ці події викликаються користувачем або можуть бути неінтерактивними. Без JavaScript документ HTML практично обмежений текстом і зображеннями. Використання JavaScript в HTML-документах дає змогу розширити інтерактивність за межі гіперпосилань і форм, що робить сторінку, яка відображається браузером, схожою на інтерфейс звичайного застосунку.

JavaScript — це мова програмування загального призначення, але основне її використання — у вебзастосунках. Функції середовища виконання браузера доступні за допомогою ключових слів JavaScript, які використовуються у сценарії для виконання потрібної операції. Наприклад, термін document використовується в коді JavaScript для звернення до HTML-документа, пов’язаного з кодом JavaScript. У контексті мови JavaScript document - це глобальний об’єкт із властивостями та методами, які можна використовувати для отримання інформації з будь-якого елемента HTML-документа. Що ще важливіше, ви можете використовувати об’єкт document, щоб змінити його елементи та зв’язати їх із користувацькими діями, написаними на JavaScript.

Клієнтський застосунок, що базується на вебтехнологіях, є багатоплатформним, оскільки може працювати на будь-якому пристрої, який має сумісний браузер.

Однак прив’язка до браузера накладає обмеження на вебпрограми порівняно з нативними застосунками. Посередництво, яке виконує браузер, дає змогу використовувати програмування більш високого рівня і підвищує безпеку, але також збільшує використання процесорного часу та пам’яті.

Розробники постійно працюють над браузерами, щоб надати більше можливостей і покращити продуктивність JavaScript-застосунків, але є внутрішні аспекти виконання сценаріїв, таких як JavaScript, які привносять недоліки порівняно з нативними програмами для того ж обладнання.

Функцією, яка значно покращує продуктивність програм JavaScript, запущених у браузері, є WebAssembly. WebAssembly – це свого роду скомпільований JavaScript, який створює вихідний код, написаний більш ефективною мовою нижнього рівня, як-от мова C. WebAssembly може прискорити переважно дії, до яких інтенсивно залучений процесор, оскільки уникає значної частини перекладу, який виконує браузер під час виконання програми, написаної на звичайному JavaScript.

Незалежно від деталей реалізації застосунку, весь HTML-код, CSS, JavaScript та мультимедійні файли необхідно спочатку отримати із сервера. Браузер отримує ці файли так само, як Інтернет-сторінку, тобто за адресою, до якої звертається браузер.

Вебсторінка, яка діє як інтерфейс до вебпрограми, схожа на звичайний HTML-документ, але з додатковою поведінкою. На звичайних сторінках користувач після натискання посилання переходить на іншу сторінку. Вебзастосунки можуть представляти свій інтерфейс і реагувати на події користувача, не завантажуючи нові сторінки у вікні браузера. Модифікація цієї стандартної поведінки на HTML-сторінках здійснюється за допомогою програмування на JavaScript.

Наприклад, клієнт вебпошти відображає повідомлення та перемикається між папками повідомлень, не залишаючи сторінки. Це можливо, оскільки клієнт використовує JavaScript, щоб реагувати на дії користувача та робити відповідні запити до сервера. Якщо користувач натискає на тему повідомлення у папці «Вхідні», код JavaScript, пов’язаний із цією подією, запитує вміст цього повідомлення у сервера (за допомогою відповідного виклику API). Щойно клієнт отримує відповідь, браузер відображає повідомлення у відповідній частині тієї ж сторінки. Різні клієнти вебпошти можуть використовувати різні стратегії, але всі вони використовують той самий принцип.

Таким чином, окрім надання браузеру файлів, з яких складається клієнт, сервер також повинен мати можливість обробляти запити, наприклад, клієнта вебпошти, коли він запитує вміст конкретного повідомлення. Кожен запит, який може зробити клієнт, має попередньо визначену процедуру відповіді на сервері, API якого може визначати різні методи, щоб визначити, до якої процедури відноситься запит. Найпоширенішими методами є:

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

Парадигма Передачі репрезентативного стану (REST, Representational State Transfer) широко використовується для взаємодії у вебзастосунках, оскільки вона заснована на основних методах, доступних у HTTP. Заголовок HTTP-запиту починається з ключового слова, що визначає основну операцію, яку потрібно виконати: GET,POST, PUT,DELETE тощо, супроводжується відповідною URL-адресою, до якої буде застосовано дію. Якщо застосунок потребує більш конкретних операцій з більш детальним описом запитуваної операції, протокол GraphQL може бути більш підходящим вибором.

Програми, розроблені з використанням моделі клієнт/сервер, схильні до нестабільності взаємодії. Тому клієнтська програма завжди повинна використовувати ефективні стратегії передачі даних, щоб підтримувати її узгодженість і не шкодити досвіду користувача.

HTTP-сервери, такі як Apache і NGINX, зазвичай вимагають певних змін конфігурації для задоволення потреб застосунку. За замовчуванням традиційні HTTP-сервери безпосередньо прив’язують шлях, зазначений у запиті, до файлу в локальній файловій системі. Якщо HTTP-сервер вебсайту зберігає свої HTML-файли в каталозі /srv/www, то наприклад, запит із шляхом /en/about.html отримає в якості відповіді вміст файла /srv/www/en/ about.html, якщо такий файл існує. Більш складні вебсайти, і особливо вебзастосунки, вимагають індивідуального підходу до різних типів запитів. У цьому сценарії частиною реалізації застосунку є зміна налаштувань HTTP-сервера для відповідності вимогам застосунку.

Крім того, існують фреймворки, які дають змогу інтегрувати керування HTTP-запитами та реалізацію коду застосунка в одному місці, дозволяючи розробнику зосередитися більше на призначенні програми, ніж на деталях платформи. У Node.js Express, наприклад, відображення всіх запитів і відповідне програмування реалізовані за допомогою JavaScript. Оскільки програмування клієнтів зазвичай виконується на JavaScript, багато розробників вважають гарною ідеєю для простоти подальшої підтримки коду використовувати одну мову для клієнта і сервера. Інші мови, які зазвичай використовуються для реалізації серверної сторони, як у фреймворках, так і традиційних HTTP-серверах, це PHP, Python, Ruby, Java і C#.

Як дані, отримані або запитані клієнтом, зберігатимуться на сервері, вирішує команда розробників, але існують загальні рекомендації, які застосовуються в більшості випадків. Зручно зберігати Статичний вміст, як то, зображення, код JavaScript і CSS, які не змінюються в короткостроковій перспективі, зручно зберігати як звичайні файли або у файловій системі сервера, або розподілено в мережі доставки вмісту (CDN, Content Delivery Network). Інші види вмісту, такі як повідомлення електронної пошти в поштовому вебзастосунку, інформація про товари в застосунку онлайн-магазину, а також журнали транзакцій, зручніше зберігати в системі керування базою даних (СКБД, DBMS - Database Management System).

Найбільш традиційним типом систем управління базами даних є реляційна база даних. У таких системах розробник застосунку визначає таблиці даних і формат введення, прийнятний для кожної таблиці. Набір таблиць у базі даних містить усі динамічні дані, які використовує та створює програма. Застосунок для онлайн-покупок, наприклад, може мати таблицю, яка містить записи з інформацією про кожен продукт в магазині, і таблицю, до якої записуються товари, придбані користувачем. Таблиця придбаних товарів містить посилання на записи в таблиці наявних товарів, створюючи зв’язки між таблицями. Такий підхід може оптимізувати зберігання та доступ до даних, а також дозволити запити в об’єднаних таблицях, використовуючи мову, прийняту в системах керування базою даних. Найпопулярнішою мовою реляційних баз даних є Structured Query Language (SQL, вимовляється як “сікуел”), вона прийнята базами даних з відкритим вихідним кодом SQLite, MySQL, MariaDB і PostgreSQL.

Альтернативою реляційним базам даних є форма бази даних, яка не вимагає жорсткої структури даних. Ці бази даних називаються нереляційними базами даних або просто NoSQL. Хоча вони можуть включати деякий функціонал, подібний до того, який є в реляційних базах даних, основна увага зосереджена на забезпеченні більшої гнучкості в збереженні та доступі до збережених даних, передаючи завдання обробки цих даних самій програмі. MongoDB, CouchDB і Redis є поширеними нереляційними системами керування базами даних.