Клиент-серверная архитектура для разработчиков веб-приложений — это что-то вроде одной из черепах, на которой стоял мир в представлениях наших предков.
Трудно представить себе иное положение дел.
Однако бесчисленное количество веб-приложений породило новую потребность — интерфейсное управление данными.
Единого подхода и реализации пока не существует; есть только отдельные технологии, позволяющие работать с данными на клиенте.
И никто им особо не заморачивается.
Кстати, пора.
Мы рассказали о том, что уже есть в плане работы с данными на фронтенде и что будет дальше.
Никита Прокопов он же тонкий .
- Никита, здравствуйте! Расскажи пару слов о себе, чем занимаешься? 
— Я работаю в компании Когниник , которая управляет веб-платформой для образования и обучения.
Там я делаю фронтенд и частично бекенд. - В аннотации к вашему отчет по HolyJS там написано, что вы хакер Clojure. — Это связано с тем, что я пишу на Clojure уже несколько лет, наверное, четыре года.
Все мои последние работы были на Clojure, есть определенная экспертиза.
— Если вы зайдете на Хабр, то сразу заметите, что Clojure встречается гораздо реже, чем другие языки программирования.
При этом он использует JVM, интегрируется с Java в обоих направлениях и имеет ряд других преимуществ.
Что с ним можно сделать и кому подходит Clojure? — Да, действительно, у Clojure есть небольшие проблемы с популярностью по сравнению, например, со Scala, у которой в этом плане дела идут неплохо.
Но Clojure находится в тени.
Однако это не какой-то маргинальный язык, он все еще относительно широко распространен.
Есть несколько крутых идей.
Clojure является пионером в неизменяемости слева направо, имеет классные примитивы для синхронизации многопоточных параллельных программ и может компилироваться в JavaScript. Clojure и ClojureScript для JVM и JavaScript идут рука об руку, вы можете писать код, который работает в обоих случаях.
Это язык общего назначения, рекомендуемый всем, кому не нужна сверхмалая задержка или сверхпредсказуемость, как в системах реального времени.
Постепенно он находит свое применение в корпоративном секторе — на нем пишут код Boeing и Walmart, то есть вполне серьезные бизнесы решают перейти на Clojure. — Заявленная вами тема отчета — «Данные на фронтенде».
О каких данных идет речь и кому они вообще нужны? — Вот история: серьезно заниматься фронтендом я начал около года назад, до этого в основном упор был на серверную часть.
Сейчас растет тенденция к тому, что приложения можно писать в браузере, и они действительно могут быть написаны там.
Но пока фронтенд-культура не доросла до тех подходов, которые давно существуют на сервере.
Написание приложений на фронтенде — это большой участок работы: что делать и как делать правильно.
Некоторые проблемы уже ясно, как решать, другие еще нет. Одна из этих проблем — как хранить данные? На сервере много опций: файловая система, база данных, может храниться в памяти или в кэшах.
А вот на клиенте не очень понятно: есть специальные решения (как Бог даст, сохраните где-нибудь в локальном хранилище или в переменных), можно попробовать использовать базы данных, которые тоже доступны клиенту, но их гораздо меньше из них.
Приложений становится все больше, им нужна работа с данными.
Это серьезная задача, требующая системного реагирования и поиска архитектуры.
В докладе я просто хочу посмотреть, какие подходы уже существуют, каковы их плюсы и минусы.
— Что будет с бэкендом? Останется ли он или в нем не будет необходимости? — Конечно, оно продолжает существовать, потому что веб-приложения эфемерны: вы приходите и уходите, но хотите, чтобы ваши данные сохранились.
Остаётся архитектура клиент-сервер, возможно БД-сервер-клиент, а может в будущем будет простой БД-клиент, это тоже один из возможных вариантов.
Наличие сервера — один из самых интересных моментов: когда сервер работает с данными, он находится в тепличных условиях, а клиент — в диких условиях, плюс на него смотрит пользователь.
Именно из-за этого возникает множество проблем, как сделать это хорошо.
То есть вы хотите, чтобы приложение быстро загружалось, работало в автономном режиме и т. д., но как это сделать не очень понятно.
Если напрячься и сделать это специально для себя, то, возможно, с большим усилием что-то и получится.
Но рано или поздно, я думаю, появятся какие-то системные решения, которые можно будет взять «с полки» и использовать.
— Мне трудно представить.
Как-то знакомо: есть приложение, например, какая-то веб-CRM, клиент передает данные на сервер, все как всегда.
И опять же — вам нужно управлять данными на стороне пользователя.
Когда и при разработке какого типа приложений пора задуматься о данных на внешнем интерфейсе? — Если мы говорим конкретно о приложении (графический редактор, что-то жутко интерактивное), то как только сайт/приложение становится динамическим, сразу возникает необходимость управлять данными на фронтенде.
— В связи с разговором об управлении такими данными расскажите о Датаскрипт .
Я думаю, это ваш проект? - Ну да, я главный разработчик.
Было несколько запросов на включение, люди мне помогали, но в основном это была моя разработка.
Его идея заключается в том, что если данные структурированы и их относительно большой объем, их удобно хранить в какой-то базе данных.
DataScript — это один из примеров очень легкой базы данных.
Это даже не полноценная база данных, а скорее структура данных в памяти, к которой можно выполнять запросы и в которой происходят транзакции.
Грубо говоря, это достаточно удобная структура данных (они реляционные, между ними есть связи), внутри все хранится плоско и индексируется.
С такой структурой удобно перемещаться, как по графику, вперед-назад и удобно быстро находить необходимые данные.
Плюс есть неизменяемость — можно делать архитектуры, которые сделаны на React, когда состояние хранится в одном объекте, оно неизменяемо и можно делать undo/redo, есть транзакции — можно создавать реактивные системы.
Существует язык запросов Datalog со своим синтаксисом и возможностями.
Сохранения нет, DataScript выполняется в памяти.
DataScript нужен, когда есть сложное многомерное состояние и вы хотите посмотреть на него с разных сторон и преобразовать.
DataScript наиболее известен в среде Clojure (хотя он поддерживает Clojure, ClojureScript, JavaScript и JVM) и часто используется вместе с Datomic на сервере.
Мы используем DataScript в Cogniian для представления сеанса клиента (вопросы, ответы, комментарии, сценарии), а также синхронизируем журнал событий в Datomic (в обоих направлениях).
Ребята из Precursor используют один и тот же стек для совместного рисования графики (фигур, объектов, групп), также у них есть собственное самодельное решение для синхронизации.
Есть пара проектов, в которых множество мелких свойств объектов хранятся в DataScript, проекты инвентаризации.
Есть даже интернет-магазин.
Это очень удобная основа, когда данные аккуратно лежат в одном месте, чтобы поверх них написать системное решение для синхронизации, например.
— Сегодня в руках разработчиков находится целый зоопарк баз данных.
Что выбрать? Или это не имеет значения? - Документоориентированная – простейший тип базы данных.
Если нет ничего лучше, то нужно брать их.
Если говорить конкретно о клиенте, то выбор очень невелик: есть miniMongo, PouchDB, они оба документоориентированные.
Вы можете писать в чистом локальном хранилище.
В идеале нужно брать базу, предоставляющую множество возможностей — в частности, синхронизацию с сервером.
Прозрачная двусторонняя синхронизация с сервером снимет большую часть головной боли.
— Раз уж мы говорим о синхронизации.
Реактивная синхронизация данных, Рой.
js - Что это? — Реактивная синхронизация данных — это когда у сервера есть новая информация и он сам понимает, какому клиенту ее отправить.
Пока никто не знает, как это сделать правильно.
Есть решение на базе RethinkDB и Meteor — вы явно подписываетесь на определенные объекты или коллекции на сервере и они приходят к вам по-серверному.
Это нетривиальная задача и возникает много проблем: во-первых, клиентов много, а сервер один, во-вторых, как вести этот список подписок.
Поток изменений на сервере постоянный — клиентов много, все транзакции проходят через сервер, а сервер должен распознавать транзакции и понимать, кого уведомлять, а кого нет. Эти проблемы эффективно решаются очень узкими технологиями, если они вообще решаются.
Кажется эта картинка скоро перестанет быть актуальной
И тут встает вопрос последовательности — мне бы тоже хотелось, чтобы во всех этих объектах был какой-то порядок и завершенность.
Это, по сути, реактивная модель — здесь и на сервере с этим всё относительно плохо, почти ни одна база данных не может нативно уведомлять о транзакциях и изменениях.
Эту проблему серверные программисты решают с помощью очереди: мы не пишем напрямую в базу данных, а ставим задачи в очередь, читаем из этой очереди и пишем — тогда все желающие смогут читать и из этой очереди.
Реактивная модель является достаточно новой для архитектуры всей системы.
То есть что-то подобное можно нагромоздить внутри языка программирования, но когда мы говорим о всей системе (данные, база данных, сервер, пользовательский интерфейс), то подходы еще только нащупываются.
Вопрос в том, как собрать такую вещь.
Сервер и клиент — распределенная система, в которой много клиентов и один сервер.
Клиенты могут писать на сервер и читать с него.
И тут возникает модель, когда клиенты накапливают пул изменений и мы хотим, чтобы они дошли до всех остальных клиентов.
Чисто теоретически эту задачу в общем случае решить невозможно, но можно прекрасно решить для определенных типов достаточно простых структур данных.
Swarm.js — это библиотека, предоставляющая структуры данных, которые хорошо решают проблему синхронизации, а также протокол для их синхронизации.
Грубо говоря, если я зашёл на одну и ту же страницу Amazon из двух браузеров и в одном браузере добавил в корзину один товар, а в другом — другой, то эти две корзины можно объединить с помощью операции слияния и конфликтов быть не может. Проблемы начинаются, если можно, например, удалить - тогда слить не получается и надо что-то придумать.
Есть такая новая тенденция в распределенных системах — CRDT (Бесконфликтный реплицируемый тип данных), это типы данных, которые легко объединяются, и Swarm.js — одна из реализаций таких вещей.
Это все части пазла, и наша глобальная цель — сделать полностью реактивную систему, в которой любые происходящие изменения распределяются по всей системе, а система состоит из базы данных, сервера и множества клиентов.
ИТ находится в поиске такой системы.
Скорее всего, это будет не какое-то готовое решение, а подход, следуя которому уже можно создавать архитектуры.
Послушать Никиту, обсудить с ним, как и с другими спикерами, рассказать о своих выводах и мыслях о будущем можно на конференции.
СвятойJS , который пройдет в Санкт-Петербурге 5 июня 2016 года.
Теги: #Разработка веб-сайтов #JavaScript #frontend #Оптимизация клиента #clojure #datascript #данные фронтенда #данные приложения
-
Универсальное
19 Oct, 24 -
Бессемер, Генри
19 Oct, 24 -
Этимология
19 Oct, 24 -
Мы Упрощаем Документооборот С «Поэтому»
19 Oct, 24 -
Paypal Получил Доступ В Россию
19 Oct, 24 -
Там Тоже Есть Глюки
19 Oct, 24
