Дані на фронтенде: крок до додатків майбутнього

Клієнт-серверна архітектура для розробників веб-додатків — це приблизно як одна з черепах, на якій стояв світ у поглядах наших предків. Важко собі уявити інше положення речей. Однак незліченна кількість веб-додатків сформувало нову потребу — управління даними на фронтенде. Поки що немає єдиного підходу і реалізації, є тільки окремі технології, що дозволяють працювати з даними клієнта. Та й з ними ніхто особливо не переймається. А між іншим, пора. Про те, що вже є в плані роботи з даними на фронтенде і що буде далі, ми поговорили з Микитою Прокоповым aka tonsky.



— Микита, привіт! Розкажи пару слів про себе, чим ти займаєшся?

— Я працюю в компанії Cognician, яка займається веб-платформою для освіти та тренінгів. Я там займаюся фронтендом і частково бекендом.

— В аннотиции до твого доповіддю на HolyJS написано, що ти Clojure-хакер...

— Це пов'язано з тим, що я пишу на Clojure вже кілька років, чотири роки, напевно. Всі мої останні роботи були на Clojure, є певна експертиза.

— Якщо пройтися по Хабру, то відразу помітно, що Clojure зустрічається значно рідше, ніж інші мови програмування. У той же час він використовує JVM, інтегрується з Java у обидві сторони, має ще ряд переваг. Що на ньому можна робити і кому Clojure підійде?

— Так, дійсно, у Clojure є невеликі проблеми з популярністю порівняно, наприклад, з тією ж Scala, у якої в цьому плані все добре. А ось Clojure в тіні. Тим не менш, це не якийсь маргінальний мову, він все ж відносно широко поширений. У ньому є кілька класних ідей.
Clojure став піонером иммутабельности «наліво і направо», в ньому є класні примітиви для синхронізації багатопотокових паралельних програм, він вміє компілюватися в JavaScript. Clojure і ClojureScript для JVM і JavaScript йдуть нога в ногу, можна писати код, який працює і там, і там. Це мова загального призначення, рекомендується всім, кому не потрібен супер низький latency або супер передбачуваність, як в системах реального часу. Він поступово знаходить своє застосування і в корпоративному секторі — Boeing і Walmart пишуть на ньому код, тобто досить серйозний бізнес приймає рішення переходити на Clojure.

— Заявлена тобою тема доповіді — «Дані на фронтенде». Про яких даних йде мова і кому це взагалі потрібно?

— Тут така історія — серйозно фронтендом я почав займатися приблизно рік тому, до цього в основному був упор на внутрішню сторону. Зараз йде зростання тенденції, що програми можна писати в браузері і їх там дійсно можна писати. Але поки фронтенд-культура не доросла до тих підходів, які давно існують на сервері. Писати програми на фронтенде — це великий фронт робіт: що і як правильно робити. Якісь проблеми вже зрозуміло, як вирішувати, які саме- поки немає. Одна з таких проблем — як зберігати дані? На сервері багато варіантів: файлова система, база даних, можна зберігати в пам'яті або в кешах. А на клієнті не дуже зрозуміло: є ad hoc рішення (як бог на душу покладе, зберегти де-небудь в local storage або змінних), можна намагатися застосовувати бази даних, які для клієнта теж є, але їх набагато менше. Додатків стає більше і більше, їм потрібно працювати з даними. Це серйозне завдання, що вимагає системного відповіді, пошуку архітектури. У доповіді я хочу розглянути, які підходи вже є, які у них плюси і мінуси.

— А що станеться з бекендом? Він залишиться або необхідність у ньому відпаде?

— Звичайно, він продовжує своє існування, тому що веб-додатки ефемерні: ти зайшов-пішов, але хочеш, щоб твої збереглися. Залишається клієнт-серверна архітектура, можливо база даних-сервер-клієнт, а може, в майбутньому, коли з'явиться і просто база даних-клієнт, це теж один з можливих варіантів. Наявність сервера — це один з найцікавіших моментів: коли сервер працює з даними, він знаходиться в тепличних умовах, а клієнт знаходиться в диких умовах, плюс на нього дивиться користувач. Саме з-за цього виникає багато проблем, як зробити добре. Тобто хочеться, щоб додаток швидко вантажилось, працювало в офлайні і т. д., а як це зробити — не дуже зрозуміло. Якщо напружитися і робити конкретно для себе, то може щось і вийде великими зусиллями. Але рано чи пізно, я думаю, з'являться якісь системні рішення, які можна буде взяти «з полиці» і використовувати.

— Мені це важко уявити. Якось звично: є додаток, наприклад, якась веб-CRM, клієнт передає дані на сервер, все як завжди. А тут раз — і потрібно управляти даними на фронтенде. Коли, при розробці додатків якого типу пора замислюватися про даних на фронтенде?

— Якщо мова саме про програму графічний редактор, щось моторошно інтерактивне), то, як тільки сайт/додаток стає динамічним, відразу виникає необхідність управління даними на фронтенде.

— У зв'язку з розмовою про управління такими даними, розкажи про DataScript. Здається, це твій проект?

— Ну так, я основний розробник. Були кілька пул-реквестов, мені допомагали люди, але в основному це моя розробка. Його ідея в тому, що якщо дані структуровані і їх відносно багато, їх зручно зберігати в якійсь подобі бази даних. DataScript — один з прикладів бази даних, дуже легкою. Це навіть не повною мірою база даних, а швидше in-memory структура даних, по якій можна запускати запити і в якої є транзакції. Грубо кажучи, це досить зручна структура даних (вони реляційні, між ними є зв'язки), всередині все зберігається в плоскому вигляді, індексується. За такої структурі зручно робити навігацію, як по графу, вперед-назад і зручно швидко знаходити потрібні дані. Плюс, є иммутабельность — можна робити архітектури, які на React робляться, коли state зберігається в одному об'єкті, він иммутабельный і можна undo/redo робити, є транзакції можна створювати реактивні системи. Є мова запитів Datalog зі своїм синтаксисом і можливостями. Немає тільки персистентності, DataScript працює в пам'яті.

DataScript потрібен, коли є складне багатовимірне стан і хочеться на нього дивитися з різних сторін, трансформувати. DataScript відоміший всього в Clojure-середовищі (хоча підтримує Clojure, ClojureScript, JavaScript і JVM) і часто використовується в зв'язці з Datomic на сервері. Ми використовуємо DataScript в Cognician, щоб представляти сесію клієнта (запитання, відповіді, коментарі, сценарії), плюс поверх цього синхронізуємо лог подій в Datomic (в обидві сторони). Хлопці з Precursor використовують такий же стек для колаборативного малювання графіки (фігури, об'єкти, групи), у них теж рішення для синхронізації своє самописное. Є кілька проектів, де в DataScript зберігається безліч дрібних властивостей об'єктів, проекти по інвентаризації. Є інтернет-магазин. Це дуже зручна основа, коли дані лежать акуратно в одному місці, щоб писати поверх неї системне рішення для синхронізації, наприклад.

— Зараз в руках розробників знаходиться цілий зоопарк баз даних. Що вибрати? Чи воно без різниці?

— Паперо-орієнтовані — найпростіший вид бази даних. Якщо нічого немає краще, то потрібно брати їх. Якщо говорити конкретно про клієнта, то вибір зовсім маленький: є miniMongo, PouchDB, вони обидві документо-орієнтовані. Можна писати на голому local storage. В ідеалі, потрібно брати базу, яка дає багато можливостей, зокрема, синхронізацію з сервером. Прозора двостороння синхронізація з сервером зніме більшу частину головного болю.

— Раз вже пішла мова про синхронізацію… Реактивна синхронізація даних, Swarm.js — що це?

— Реактивна синхронізація даних — це коли у сервера є нова інформація і він сам розуміє, якому клієнтові її відіслати. Поки ніхто нормального це робити не вміє. Є рішення на базі RethinkDB і Meteor — ти явно подписываешься на сервері на певні об'єкти або колекції і вони приходять тобі server-push-го. Це нетривіальне завдання і виникає багато проблем: по-перше, багато клієнтів, а сервер один, по-друге, як підтримувати цей список підписок. Потік змін на сервері постійний — клієнтів багато, через сервер проходять всі транзакції і сервер повинен розпізнати транзакції і зрозуміти, кого сповіщати, а кого — ні. Ці завдання ефективно вирішуються дуже вузькими технологіями, якщо взагалі вирішуються.


Здається, ця картинка скоро перестане бути актуальною

І там же виникає питання консистентности — хотілося б ще, щоб були якийсь порядок і повнота у всіх цих об'єктах. Це, власне, реактивна модель — тут і на сервері з цим щодо все погано, майже ніякі бази даних не вміють нативно сповіщати про операції та зміни. Ця проблема серверними програмістами вирішується за допомогою черги: ми не пишемо безпосередньо в базу, а складаємо завдання в чергу, читаємо з цієї черги і пишемо — тоді всі, кому цікаво, теж можуть читати з цієї черги. Реактивна модель досить нова саме для архітектури всієї системи. Тобто всередині мови програмування можна що-небудь таке навигадувати, а от коли мова йде про цілу систему (дані, база, сервер, інтерфейс користувача), то тут підходи поки тільки нащупываются. Мова про те, як таку штуку зібрати.

Сервер і клієнт — розподілена система, в якій клієнтів багато, а один сервер. Клієнти можуть писати і читати з сервера. І тут виникає модель, коли у клієнтів накопичується пул змін і ми хочемо, щоб вони потрапили на всіх інших клієнтів. Чисто теоретично ця задача не вирішується в загальному випадку, але вона вирішується красиво для певних видів досить простих структур даних. Swarm.js — це бібліотека, яка надає структури даних, для яких проблема синхронізації вирішується красиво, та протокол їх синхронізації. Грубо кажучи, якщо я зайшов на одну і ту ж сторінку Amazon з двох браузерів і в одному браузері додав один товар в корзину, а в іншому — інший, ці дві корзини можна злити операцією об'єднання і конфліктів бути не може. Проблеми починаються, якщо можливо, наприклад, видалення — тоді зливати можна і потрібно щось придумувати. Є таке нове віяння в розподілених системах — CRDT (Conflict-free Replicated Data Type), це типи даних, які легко зливаються і Swarm.js — одна з реалізацій таких штук. Це всі шматочки пазла, а глобальна мета у нас — зробити повністю реактивну систему, в якій будь-які зміни, які відбуваються, поширюються по всій системі, причому система складається з бази, сервера і безлічі клієнтів. IT знаходиться в пошуку такої системи. Швидше за все, це буде не якесь готове рішення, а підхід, слідуючи якому можна вже створювати архітектури.



Послухати Микиту, подискутувати з ним, а також з іншими доповідачами, розповісти про свої знахідки і думках про майбутнє можна буде на конференції HolyJS, яка пройде в Санкт-Петербурзі 5 червня 2016 року.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.