Добро пожаловать в часть VI моей серии VI о Еве, захватывающем и увлекательном новом языке программирования.

Эпоха подключенных клиентов

В своем выступлении JavaScript State of the Union в августе 2015 года Джефф Шмидт из Meteor использовал термин подключенный клиент для описания наших современных архитектур приложений:

Подключенные клиентские приложения имеют несколько клиентов с разным объемом ресурсов ЦП и хранилища, которые обращаются к одной и той же службе в облаке.

Шмидт отмечает, что мы ожидаем, что наши подключенные клиентские приложения будут в реальном времени. Раньше мы ожидали, что пользовательский интерфейс веб-приложения будет статическим до тех пор, пока не будет обновлен вручную, но теперь мы ожидаем, что он будет динамическим по умолчанию.

Проблема: сегодняшние базы данных в реальном времени неадекватны

Сегодня сложно создавать подключенное клиентское приложение, потому что невозможно постоянно отслеживать сложные запросы. Я имею в виду правый нижний квадрант этой таблицы:

Традиционный запрос к базе данных - это снимок - он сообщает вам значение запроса в то время, когда вы его запрашиваете, и все. Но если вы создаете современное приложение с подключенным клиентом в реальном времени, запрос снимка не соответствует вашим потребностям. Вам нужен непрерывный запрос.

Сегодня большинство программистов используют уже готовые решения, чтобы реализовать в своих приложениях функциональность в реальном времени. Чтобы обновить пользовательский интерфейс в реальном времени, ваш сервер может опросить базу данных SQL, а затем использовать веб-сокеты для отправки клиенту сообщений об обновлении по некоторому протоколу, который вы создали.

Но на рынке также есть несколько баз данных реального времени, поэтому можно выполнять непрерывные простые запросы, а нижнее левое поле имеет зеленый цвет. Наиболее популярные базы данных реального времени:

  • Firebase
    Позволяет отслеживать изменения для ключевых запросов и простого сканирования.
  • RethinkDB
    Предоставляет каналы изменений по определенным запросам ReQL.
  • Meteor
    Позволяет отслеживать произвольные запросы MongoDB.

Эти базы данных отлично подходят для простых запросов, но не для сложных.

Прежде чем мы перейдем к их ограничениям, я хочу поблагодарить базы данных реального времени за то, что они даже существуют. Они заслуживают похвалы за реализацию непрерывных запросов на уровне базы данных. Подключенные клиентские приложения отчаянно нуждаются в этом уровне абстракции; они не должны катить свою собственную реальность в реальном времени.

Запрос количества уведомлений

В статье денормализация данных нарушена я привел пример сложного запроса, который приложение для обмена сообщениями может использовать для вычисления количества уведомлений, имеющихся у пользователя. Вот оно, написанное на ReQL:

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

Концептуально это очень просто. Все, что нам нужно, - это непрерывно передавать значение запроса-счетчика-уведомлений маленькому красному числу в пользовательском интерфейсе.

Поскольку это язык запросов RethinkDB, вы можете подумать, что мы можем получить фид изменений, просто добавив .changes() к запросу. Но мы не можем, потому что чейнджфиды по многотабличным запросам не поддерживаются.

Текущие ограничения

В настоящее время RethinkDB и Firebase серьезно ограничивают количество запросов, которые вы можете просматривать (аналогично приведенному выше примеру с подсчетом уведомлений). Meteor позволяет вам просматривать любые запросы MongoDB, но только самые простые из них бывают быстрыми.

В Meteor различие между простым и сложным определяется тем, может ли он использовать хвостовую часть oplog вместо poll-and-diff:

  • хвостовой журнал операций: отслеживает журнал операций, чтобы определить, как изменились результаты ваших запросов.
  • poll-and-diff: выполняет ваш запрос каждые несколько секунд, сравнивает его с последним выполнением вашего запроса, а затем сообщает вам обо всех изменениях.

Если вы просто ищете документ по его id, Meteor может сделать вывод, что результат вашего запроса изменяется только при изменении этого конкретного документа. Точно так же, если ваш запрос представляет собой простой фильтр, легко определить, может ли изменение журнала операций привести к изменению запрашиваемых записей.

На данный момент настройка Meteor на масштабируемость в основном означает отказ от сложных запросов.

Текущие обходные пути

Как мы можем запрограммировать клиент нашего приложения для обмена сообщениями на постоянный мониторинг количества уведомлений? Мы не можем сделать это с помощью базы данных в реальном времени, которая позволяет нам наблюдать за сложным запросом, но это правильная абстракция для того, что мы пытаемся сделать. Единственные решения, которые возможны с помощью современных технологий, - это обходные пути.

Двумя основными обходными путями являются опрос и денормализация. Опрос основан на возможности выполнения сложных запросов к моментальным снимкам, в то время как денормализация опирается на выполнимость простых непрерывных запросов.

Решения для опросов просто кодировать. Очевидным недостатком является то, что использование ресурсов пропорционально длительности интервала опроса. Опрос 100 мс в 10 раз дороже опроса за 1 секунду.

Решения по денормализации потенциально могут быть намного более эффективными по времени, но они требуют дополнительного места. Что еще более важно, их проблематично кодировать.

Meteor заслуживает некоторой похвалы за включение обходного пути опроса в уровень абстракции базы данных в реальном времени. Это позволяет нам мечтать о том, что однажды у нас будет технология, позволяющая эффективно выполнять непрерывные сложные запросы, и тогда наш код Meteor на уровне приложения вообще не будет нуждаться в изменении.

Решение Евы

В Части II я упомянул, что Eve поддерживает сложные архитектуры CQRS, и пообещал показать более сложный пример. Поехали…

Помните тот запрос для подсчета уведомлений пользователя, который мы хотели бы отслеживать в реальном времени?

Вот эквивалентный запрос у Евы:

Что круто, так это то, что зеленая строка У Liron 2 непрочитанные комнаты очень чувствительна к своим логическим зависимостям. В этом видео вы можете увидеть, как изменение метки времени сообщения мгновенно меняет количество переговорных комнат, которые считаются непрочитанными.

Если вы использовали MobX, вы, возможно, были разочарованы тем, что для вашего уровня данных нет ничего лучше MobX. Вот что такое bind Евы.

И важно отметить: вместо bind привязки этого 2 к @view базе данных для отладки, мы могли бы так же легко привязать его к специальной базе данных, которую Ева синхронизирует с клиентом.

Ева одновременно расширяет границы возможностей CQRS, денормализации и сложности запросов к базам данных реального времени. Лично я в восторге!

Безуровневые запросы

Когда вы говорите о мониторинге запроса на уровне базы данных, термин «данные в реальном времени» звучит как нечто необычное. Но когда мы выполняем вычисления на уровне приложения для локальных данных, то, конечно, мы ожидаем работать с последними значениями переменных.

Видение Евы состоит в том, чтобы код прикладного уровня получал доступ к значениям запроса из базы данных так же, как он получает доступ к значениям локальных переменных. Все это часть унификации вашего программного стека.

И как только Ева размывает эти слои, возможно, вся концепция «слоев вашего стека» исчезнет, ​​и останутся только бесслойные запросы.

Когда вы пишете бесуровневый запрос (т. Е. Стандартный Eve search), среда выполнения Eve может выполнить удаленный запрос, чтобы получить данные точно в срок или передать их клиенту заранее. Это может зависеть от таких факторов, как ваше оборудование и возможность подключения к сети.

А бесуровневые запросы не просто абстрагируются от слоев данных, они также абстрагируются от вычислительных слоев. Иногда единственная причина, по которой у нас есть сервер, заключается в том, что он выполняет тяжелые вычисления. С помощью Eve мы могли бы декларативно определить алгоритм и оставить его на усмотрение среды выполнения, чтобы решить, будет ли он работать на клиенте или где-то вне его.

Заключение

На протяжении всей серии, вместо того, чтобы подробно учить Еву, моей целью было указать на те области в статус-кво основного программирования, которые, по-видимому, созрели для улучшения. Я надеюсь, вы согласны с тем, что Ева обещает улучшить жизнь в этих областях.

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.

Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!