...

воскресенье, 8 декабря 2013 г.

[Перевод] Логика хуков ShareJS


сегодня в 01:44


В цикле коммита ShareJS существует 4 хука. Реализацию двух из них (submit и after submit) вы можете посмотреть в коде ShareJS. А двух остальных (preValidate и validate) в коде LiveDB.



Последовательность вызова хуков такова:



  1. ShareJS запускает submit middleware, которая имеет доступ к операции, имени коллекции, имени документа (_id для MongoDB) и connect-сессии. Эта middleware запускается асинхронно при первоначальной обработке операции, до попытки её применения. Таким образом, в ней вы можете асинхронно получить данные необходимые для контроля доступа или манипулировать операцией.

  2. LiveDB вызывает метод preValidate. Он получает всё доступное в submit middleware, а так же документ до выполнения операции. Этот метод вызывается синхронно в процессе коммита операции и может быть вызван многократно.

  3. LiveDB запускает метод validate. Он работает так же, как предыдущий, только вызывается после после произведения операции с документом.

  4. ShareJS запускает after submit middleware, которая получает те же данные что и submit, и так же документ после произведения операции. Это запускается асинхронно, сразу после сохранения операции и публикации её для подписчиков.


Мы потратили много времени на обсуждение деталей этих хуков и мы намеренно оставили их достаточно низкоуровневыми в рамках ShareJS/LiveDB.


Методы LiveDB намеренно сделаны синхронными. Эти методы могут быть вызваны много раз в процессе валидации, поскольку если два разных клиента одновременно изменяют один и тот же документ, выигрывает клиент сабмитящий первым и последующие попытки отклоняются до завершения операции. Добавление асинхронных вызовов для получения дополнительных данных здесь было бы неэффективным учитывая, что методы могут вызываться многократно. In addition, async calls could cause resource starvation where some servers with a slower running task could consistently lose to servers with faster tasks many times in a row. Cинхронные вызовы существенно снижают вероятность этого.


Валидация в LiveDB разделена на два метода, чтобы избежать постоянного, зачастую ненужного клонирования документа. Если вы хотите иметь единственный вызов валидации с вариантами документа до и после после операции, вы можете глубоко клонировать документ в preValidate и затем использовать его и изменённую версию в validate.


Правильный метод получения дополнительных данных для контроля доступа — использование Express middleware или ShareJS submit middleware, и добавление их сессию, которая передаётся в preValidate / validate.


Текущая реализация немного запутана и в идеале racer-access должен иметь более интуитивный API и документацию. Я рад предложениям по улучшению racer-access, но не думаю, что имеет смысл что-то менять в LiveDB.





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?



Смотри бесплатные курсы

и выиграй Xbox



Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.


Комментариев нет:

Отправить комментарий