Одним из самых больших изменений в предстоящем выпуске Meteor 0.5.1 является улучшение нашего алгоритма компенсации задержки. Meteor сохраняет оперативность, кэшируя часть базы данных вашего приложения в памяти клиента. Это не просто кеш только для чтения: когда клиент отправляет серверу изменение базы данных, он одновременно обновляет свой локальный кеш предлагаемым изменением. Это означает, что клиенту не нужно ждать двустороннего обмена, чтобы обновить экран пользователя. Но эти симулированные обновления локального кеша сохраняются только до тех пор, пока клиент не узнает, что на самом деле произошло на сервере. Если эти результаты различаются, Meteor заменяет симулированную запись реальным результатом сервера. Эта компенсация задержки не требует дополнительных усилий со стороны разработчика: Meteor берет на себя всю бухгалтерию за кулисами. Поскольку клиент может выполнять несколько операций записи, сложность этой бухгалтерии заключается в замене смоделированных результатов на клиенте только в том случае, если последующие симуляции не зависят от них.
В предыдущих версиях Meteor каждая новая симуляция неявно зависела от каждого выдающегося метода. Прежде чем выполнять какие-либо оптимистичные записи в локальный кеш, мы сделали снимок всего кеша локальной базы данных и прекратили применение любых изменений данных с сервера. Как только все методы обновления завершили выполнение на сервере, мы вернули всю базу данных обратно к моментальному снимку (отменив все изменения на стороне клиента) и одним махом применили все изменения буферизованных данных сервера. В обычном случае, когда все методы увенчались успехом, будут применены те же самые изменения с сервера, что и при моделировании (и ничего на экране не нужно будет обновлять), но если метод не удался, это вернет локальную базу данных обратно к стоимость сервера. Если несколько методов записи выполнялись одновременно, Meteor ждал, пока все не будут завершены, чтобы выполнить шаг «отменить изменения клиента, применить изменения сервера».
Эта стратегия работала хорошо и обеспечивала согласованность кэша клиента с сервером, но она не была идеальной. Примечательно, что если метод записи был медленным, то все изменения данных на стороне сервера будут игнорироваться клиентом до тех пор, пока метод не будет выполнен. Таким образом, со старым кодом, если ваше приложение имело чат вверху и панель управления запуском космического корабля внизу, и запуск космического корабля занимал 10 минут, обновления чата откладывались до завершения запуска шаттла. Нам нужен способ держать чат в курсе последней информации с сервера, даже если панель управления запуском все еще ждет подтверждения запуска шаттла.
Итак, в Meteor 0.5.1 мы сделали компенсацию задержки более тонкой. Теперь, вместо того, чтобы замораживать содержимое всей базы данных при каждом вызове метода, Meteor делает моментальные снимки отдельных документов данных (документы Mongo в текущей реализации, хотя интерфейс предназначен для работы с любым бэкэндом базы данных с локальным кэшированием), которые обновляются клиентом. боковая сторона. Изменения данных в других документах теперь применяются напрямую без буферизации. Таким образом, ваш чат продолжает работать, пока вы находитесь в середине обратного отсчета запуска.
