Но это кажется настолько неправильным!
Это имеет смысл, если учесть цели дизайна позвоночника, реализацию того, что MacCaw называет «Асинхронный интерфейс» (название the blog post вы связаны с вашим связанным с этим вопросом). Эта парадигма пытается устранить все следы традиционного шаблона запроса/ответа из пользовательского опыта. Больше нет «загрузки» графики; мгновенно реагировать на взаимодействие пользователя.
Эта парадигма предполагает иной подход к развитию. Сохранение на сервере становится скорее фоновой нитью, которая при нормальных обстоятельствах никогда не должна терпеть неудачу.
Это означает, что при нормальных обстоятельствах ваша логика приложения не должна зависеть от порядка или планирования запросов по позвоночнику.
Если ваше приложение сильно зависит от ответов сервера, то позвоночник может быть неправильной библиотекой.
Зачем нужно, чтобы Spine принимал так много контроля и упорядочивал все POSTS (например) от клиента?
Из-за отсутствия блокировки философии дизайна отдела позвоночника, ваше приложение слагает управления потоком, который вы могли бы иметь в другую библиотеку, как Backbone, в котором вы могли бы сделать что-то вроде отключить кнопку «Отправить» в то время как запрос делается, или иным образом запрещает пользователям рассылать сервер с запросами, отличными от idempotent.
Spine's Model#save, например, немедленно возвращается и касается клиента, уже произошло до того, как сервер даже получит запрос. Это означает, что spinejs нуждается в для сбора и обработки запросов в том порядке, в котором они поступают, чтобы обеспечить правильную обработку. Подумайте о попытке пользователя нажать кнопку «Сохранить» для новой записи. Первый клик отправит POST, второй - PUT. Но кнопка спам-пользователя не знает и не заботится об этом. Позвоните, чтобы убедиться, что POST успешно завершен до отправки PUT или возникнут проблемы с клиентом.
Объединить чувствительность заказа неблокирующей вход интерфейса с первой точкой, что ваше приложение не должно касаться себя слишком много с персистентностью, и вы можете начать видеть, почему spinejs упорядочивает запросы.
Даже если Spine пытается достичь некоторого здравомыслия, упорядочивая все POST для каждого клиента, он по-прежнему не может предотвратить одновременные и конфликтующие POSTS, происходящие от разных клиентов. Итак, зачем беспокоиться?
Поскольку точка решения заключается в предоставлении единообразного, некорректного пользовательского интерфейса пользователя для одного клиента. Например. если клиент создает, затем обновляет, а затем удаляет запись, позвоночник должен гарантировать, что все эти запросы сделают это на сервере успешно и в правильном порядке. Обработка конфликтующих сообщений между клиентами - отдельная проблема, а не точка очереди запросов.
Ключ можно найти в количестве вопросов SO в соответствии с строками «как я могу сериализовать несколько связанных вызовов AJAX?» – slashingweapon
Я не говорю, что нам не нужно сериализовывать звонки AJAX. Я только спрашиваю, почему бы всегда * позвоночник ** сериализовать все POSTS? Я понимаю необходимость сериализации вызовов (иногда), и я думаю, что это нужно оставить на усмотрение разработчика, когда это сделать. – brainOverflow