Лучший способ обойти ограничение одновременных вызовов AJAX - PullRequest
0 голосов
/ 26 октября 2018

Находясь под угрозой провала за отсутствие публикации кода, как лучше всего обойти ограничение 6 одновременных вызовов для запросов ajax?

Итак, в настоящее время я работаю с приложением, которое может иметьдо 40 или около того запросов AJAX при загрузке страницы.Для фона большинство этих запросов относятся к различным графикам, скрытым за вкладками.Пользователь может инициировать некоторые запросы (например, обновить имя объекта без обновления страницы).Это означает, что с ограничением одновременных запросов пользователь не сможет ничего менять, пока не будет запущено только 5 других запросов, и это неприемлемо для пользователя.

Это может означать, что приложение плохо структурировано,но в большинстве случаев загрузка не требуется сразу.

В любом случае, я немного изучил fetch () и веб-разработчиков, но не могу найти никакой информации о том, помогут ли они обойти ограничение.

Одним из решений было бы размещение ресурсов на разных поддоменах, но это излишне усложняет бэкэнд-API (и это проблема браузера, а не сервера).

Я рассмотрел следующие подходы:

  • задерживает запросы до тех пор, пока пользователь не будет активно в них нуждаться (IMO, это плохой пользовательский опыт, потому что ему придется немного подождать, что раздражает)
  • создать очередьсистема, которая оставляет открытой одну точку для пользовательских запросов (я не уверен, как это реализовать, но шоэто будет выполнимо)
  • реструктурируйте API так, чтобы больше запросов возвращалось за запрос (это опять-таки в основном бэкэнд-решение, которое кажется немного грязным и не готовым к работе.Кроме того, это не обязательно увеличит время загрузки)
  • цепочка вызовов, например, с Советы по нескольким асинхронным вызовам AJAX (однако, учитывая непредсказуемое количество вызовов на несвязанных конечных точках, поэтому я не будуне думаю, что это все, что практично здесь)
  • веб-работники?(опять же, не уверен, что это могло бы помочь, так как это используется для многопоточности js)
  • fetch ()?(Я не могу найти информацию о том, распространяется ли на это такое же ограничение)

Ответы [ 3 ]

0 голосов
/ 26 октября 2018

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

Кроме того, задержка запросов до тех пор, пока они не потребуются пользователю, кажется мне подходящим выбором. Это основа для того, почему у нас есть CSS-стиль "выше сгиба" и бесконечная прокрутка. Сначала загрузите то, что нужно, и отложите то, что на самом деле может не иметь значения, когда это необходимо.

0 голосов
/ 14 апреля 2019

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

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

Пример:

Добавьте приведенный ниже код в JaxWeb.js

onmessage = function (e) {
    var JaxWeb = function (e) {
        return {
            requestChannel: {},
            get_csrf_token: function () {
                return this._csrf_token;
            },
            set_csrf_token: function (_csrf_token = null) {
                this._csrf_token = _csrf_token;
            },
            prepare: (function ( e ) {
                this.requestChannel = new XMLHttpRequest();
                this.requestChannel.onreadystatechange = function () {
                    if (this.readyState == 4 && this.status == 200) {
                        postMessage(JSON.parse(this.responseText));
                    }
                };
                this.requestChannel.open(e.data.method, e.data.callname, true);
                this.requestChannel.setRequestHeader("X-CSRF-TOKEN", e.data.token);
                var postData = '';
                if (e.data.data)
                    postData = JSON.stringify(e.data.data);
                this.requestChannel.send(postData);
            })(e)
        }
    };
    return JaxWeb(e);
}

Использование:

jaxWebGetServerResponse = function () {
    var wk2 = new Worker('path_to_jaxweb_js/JaxWeb.js');

    wk2.postMessage({
        "callname": '<url end point>',
        "method": '<your http method>',
        "data": ''
    });

    wk2.onmessage = function (serverResponse) {
        //
        //process results
        //with data that is received from server
    }
};



//Invoke the function 
jaxWebGetServerResponse();
0 голосов
/ 26 октября 2018

Это в значительной степени основано на мнении.

40 запросов не является необоснованным, но в зависимости от настроек вашего сервера и сайта это может занять довольно много времени.

При таком количестве вызовов я бы связал несколькоиз них вместе в initializePage=X вызове.Это включает в себя некоторые серверные работы.

Delay requests не обязательно плохо, в зависимости от вашего предполагаемого времени доставки.Если возможно, вы можете представить какую-то анимацию или «ожидаемый результат» до тех пор, пока не появится ответ, чтобы развлечь пользователя.То же относится и к Queing вашим запросам.

Реструктуризация вашего кода для возврата всего в пакете также может значительно ускорить ваш сайт, если вы выполняете много инициализации на своем сервере (например, проверки безопасности).

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

Webworkers - это не ответ, так как проблема заключается в скорости соединения и одновременностипределы подключения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...