Корольова. Таблетки для схуднення для Інтернету

Близько року тому Микита Прокопов опублікував статтю-маніфест "Розчарування програмним забезпеченням". Судячи з позитивних відгуків, розробники хочуть піклуватися про якість продукції, яку вони виробляють. Чи пора починати діяти, можливо?

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

Перш ніж читати далі, перейдіть за посиланням. Спробуйте зіграти кілька матчів. Бажано грати з робочого столу.

Трохи історії

Спочатку творці Інтернету розробляли браузер як тонкий клієнт для веб-серверів. Браузер відображав гіпертекстові сторінки, отримані від сервера. Це було просто і елегантно. Як це часто буває, красива ідея зіткнулася з реальністю, і через кілька років виробники браузерів додали підтримку мови сценаріїв. Спочатку він призначався лише для декорування. До середини першого десятиліття вважалося правильним створювати веб-сайти з JS як варіант.

Сучасний підхід до розробки веб-сайтів є результатом зростаючих вимог до інтерактивності користувальницького інтерфейсу. Завдання щодо поліпшення інтерактивності лягли на плечі дизайнерів шаблонів. Часто вони не мають компетенції та повноважень розробляти "наскрізне" рішення. Розробники шаблонів навчились JS і стали інженерами-розробниками. Логіка поступово почала надходити від сервера до клієнта. Фронтенд-хлопцеві зручно писати все на стороні клієнта. Для бекенд-хлопця зручно не думати про користувача. "Я дам вам JSON, і тоді мені все одно", - кажуть вони. Два роки тому архітектура без серверів стала популярною. Припущення полягало в тому, що програми JS працюватимуть безпосередньо з базами даних та чергами повідомлень.

На даний момент звичайний веб-сайт - це складна програма, написана на JS, і простий сервер API. Основна логіка виконується на жировому клієнті, а серверна частина вироджується до проксі-сервера бази даних.

Якщо технічний борг на стороні сервера може не вплинути безпосередньо на вашого користувача, то на стороні клієнта це вплине. Якщо ваш стартап «злетить» і почне заробляти, то далі із зростанням навантаження ситуація буде лише погіршуватися з точки зору продуктивності. Вимоги зміниться. Кодова база розбухне, а коефіцієнт обороту в команді зросте. Сторінка буде жиріти від залежностей. Веб-сайт завантажить застарілий JSON. Фонові завдання будуть множитися в кількості, кожна з них працює протягом декількох мілісекунд щосекунди, що через деякий час призведе до відставання та потепління iPad нещасного користувача, щоб він міг смажити на ньому яйця. Ніхто не наважиться виправити це через страх зламати систему. Це закінчиться тим, що згорілі хлопці, що перегоріли, приїжджають до менеджера з пропозицією кинути старий потворний фреймворк і переписати все з нуля на новий блискучий. Менеджер відмовить, і хлопці, що працюють у фронті, почнуть використовувати обидва разом.

Як працює Корольов

Отже, що, якщо ми повернемося до поворотного пункту? До того моменту, коли хтось придумав оновити вміст без перезавантаження сторінки, а історична неминучість породила AJAX? Що якщо ми залишимо все на сервері і зробимо тонкий клієнт? Найкращі сайти роблять попередній візуалізацію сторінок на сервері, щоб користувач міг бачити інтерфейс перед завантаженням JS. Ми можемо піти далі і залишити лише код на клієнті, який відповідає за обробку вводу-виводу, враховуючи поточні вимоги до інтерактивності. Думки про це привели мене до проекту Корольова.

Як це працює з точки зору клієнта? Користувач заходить на сторінку. Сервер надсилає згенерований HTML і невеликий скрипт (близько шести КБ без стиснення), який підключається до сервера через веб-сокет. Коли користувач робить подію (наприклад, клацання), сценарій надсилає її на сервер. Сервер обробляє подію, генерує та надсилає список команд типу "додати нову

Що відбувається на сервері? Коли запит на сторінку надходить із браузера, Корольов створює новий сеанс. Початковий стан створюється та зберігається в кеші. Візуалізація HTML із цього стану, а надсилання клієнту у відповідь на запит - також сервер зберігає "віртуальний DOM" у сеансі. Після запиту сторінки сервер приймає запит на відкриття веб-сокета. Корольов пов'язує відкритий веб-сокет із сеансом. Кожна подія, що надходить від клієнта, може змінити стан, пов'язаний із сеансом (але не може змінити DOM безпосередньо). Кожна зміна стану призводить до виклику функції візуалізації, яка створює нову "віртуальну DOM", яка порівнюється зі старою версією. Результатом порівняння є список команд, які слід надіслати клієнту.

Що відбувається в коді та голові розробника? Написане вище може нагадати вам про React, з тією різницею, що все відбувається на сервері. Корольов має подібний підхід. Тому, якщо ви працювали з React або іншим «віртуальним DOM», то стиль роботи Корольова вам буде знайомий. Якщо ви не знайомі з React, уявіть, що у вас є карта даних та шаблон. Обробники подій змінюють дані, сторінки змінюються самі собою.

Продуктивність

Є два популярні питання щодо Корольова: "що робити, якщо затримка велика" і "як він завантажує мій сервер". Обидва цілком розумні.

Фронт-енд хлопець звик до того, що його програма працює на локальній машині користувача. Це означає, що внесені до нього зміни будуть застосовані, як тільки машина JS закінчить виконувати код, і браузер почне візуалізацію. Я спеціально показав приклад на початку. Якщо ви не перестали читати, мабуть, у вас був хороший досвід. Особливо якщо порахувати, що цей сервер розміщений у Москві. Якщо ви живете в Сан-Франциско, теоретично мінімальний час поїздки в обидва кінці становитиме 62 мс. Також ви можете прочитати звіт про UX та обмеження часу відповіді. Перевірте середню затримку клієнта на будь-якому веб-сайті. Якщо це було менше 100, затримка відмінна. Сподіваюся, я розвіяв сумніви щодо можливості відставання.

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

10 тисяч різниць у секунду для двох довільних дерев із 500 вузлів на MacBook 2013. Статичний візуалізація також дає досить хороший результат: до 1 мільйона сторінок в секунду. Кожен "віртуальний DOM" зберігається та обробляється у спеціальній серіалізованій презентації та займає 128 КБ купи для середньої веб-сторінки. Процес візуалізації спеціально оптимізований і не має оперативної пам'яті та GC.

Що стосується швидкості програмування, тут Корольов дає чудові переваги. Не потрібно писати додатковий шар між базою даних та сервером. Не потрібно узгоджувати протокол між клієнтом та сервером. Не потрібно турбуватися про розмір пакетів JS - вага JS на клієнті завжди залишатиметься незмінною. Немає необхідності в додатковій роботі для підтримки серверних подій: прийміть повідомлення з черги і змініть стан сеансу, Корольов відтворить і доставить.

Вартість

Але переваги мають вартість. Вам слід розірвати деякі звички, а деякі нові набути. Наприклад, вам доведеться залишити JS-анімацію і задовольнитися CSS-анімацією. Вам доведеться навчитися робити інфраструктуру спочатку георозподіленою, якщо ви хочете якісно обслуговувати користувачів з різних країн. Вам доведеться кинути JS і перейти на Scala.

Мені трохи соромно (насправді ні), що я ввів читача в оману і не відразу сказав, що Корольов писав у Скалі. Чи прочитали б ви до цього моменту, якби я розповів вам про це вище? Говорячи про Корольова, я маю подолати два стереотипи. Перший пов’язаний з тим, що рендеринг сервера сприймається як щось повільне, а не інтерактивне. Другий - про Scala - це щось складне. І перший, і другий стереотипи не мають нічого спільного з реальністю.

Більше того, програмування у стилі React на Scala зручніше, ніж на JS. Сучасна JS схильна до функціонального програмування, і Scala надає її нестандартно. Наприклад, об’єкт у Scala має метод copy (), який дозволяє копіювати об’єкт, змінюючи деякі поля. Незмінні колекції, що входять до стандартної бібліотеки.

Висновок

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