Название концепции

Не уверен, что правильно тебя понял, но случаем не REST ли ты так заковыристо описываешь?

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

pipeline

Похоже на то. Только то что я нашёл описывает это как сбор запросов на стороне сервера, а я хочу сделать это на стороне клиента.

AJAX

https://en.wikipedia.org/wiki/HTTP_pipelining

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

Это тоже pipeline, т.к. это концепция. Зашей в свой сервер (запатч jquery или что там у тебя) и делов-то.

Такая архитектура называется «дерьмо».

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

У этой архитектуры есть конкретная цель — снизить количество запросов и лишнего трафика.

Конвейеризацию запросов правильнее делать на уровне протокола (как в Cap'n'Proto), а не API, чтобы как раз не возникало методов вида «doThisShitAndOtherShitAndKitchenSink».

На уровне какого протокола? Это в любом случае нужно делать на обеих сторонах, так как клиент должен как-то упаковать, а сервер распаковать — и наоборот.

Оно? http://sitr.us/2012/07/31/promise-pipelines-in-javascript.html

Того, который используется для передачи твоего API. У тебя же абстрактный вопрос. В HTTP это называется «HTTP pipelining», например.

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

Не знаю, я по их формулировкам никак не могу понять что имеется в виду.

Да я вообще не вижу смысла делать пул — просто создать один метод обновления всего и его уже дёргать когда нужно. У меня нет смысла обновлять что-то одно отдельно от всего остального.

Нет, ссылка выше это не то. Ты определись с моментом отдачи результатов.

Ты сформировал запрос на получение разных данных. Задача заключается а) в агрегировании ответов на стороне сервера в один ответ б) агрегирование ответов сервера на строне клиента.

ИМХО, ты либо переусложнишь сервак (т.е. ему надо дожидаться ответа всех операций), либо ты просто пишешь на серваке отдельные функции и не паришь мозг.

ИМХО, ты либо переусложнишь сервак (т.е. ему надо дожидаться ответа всех операций), либо ты просто пишешь на серваке отдельные функции и не паришь мозг.

А какая разница, надо ему дожидаться или нет? Так он даст ответы по одному, так все вместе — время расчётов суммарно одинаковое (общее возможно даже меньше так как меньше вызовов методов).

Я просто не знаю в каком контексте ты собираешься это использовать.
А чем это отличается от тупого GET /obnovleniya с разбором ответа вида {comments: {text: 'haha', author: 'putin'}, likes: [3, 7, 2]}? И зачем придумывать этому название?

Это называется RPC. Ты вызываешь удаленную процедуру «get_all_updates».

Ничем не отличается, это оно и есть.

И зачем придумывать этому название?

Чтобы спросить, чем такой подход или хорош, но при этом не описывать простыню текста.

Я не знаю что у тебя за сервак и что за запросы. Просто 5 запросов заалоцируют в 5 раз больше памяти, чем когда они выполняются друг за другом. Умножить на 1000 клиентов и у тебя сервак начнет не успевать отрабатывать 5 запросов меньше чем за секунду. Память будет выжираться гигибайтами при высоких нагрузках. Можешь сам попробовать.

Это твоя архитектура, делай как знаешь.

Такая архитектура называется «дерьмо».

Дерьмо это то во что превращается REST когда его применяют не к месту.

Да при чём тут REST вообще.

Да при чём тут REST вообще.

А как по твоему называется то что ты предлагаешь?

чем такой подход или хорош

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

В описанном примере будет один запрос getNotificationsAndNewPostsAndSomeShit, а сервер будет так же одним методом возвращать всё это.

Ничего, что это убивает HTTP-кеширование?

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

Проснись, ты обосрался. Мы в 2016, популярные браузеры вовсю поддерживают HTTP2, сервера догоняют семимильными шагами.

Да как угодно. Я вообще-то не только применительно к вебу говорю.

У этой архитектуры есть конкретная цель — снизить количество запросов и лишнего трафика.

Это уже давно не проблема с нормальными серверами и системами хранения данных.

Я не говорю что это проблема. Мне интересен сам подход.

batched request

например вот

В мире HTTP2 повсюду, а они костыли лепят.

В JSON-RPC есть batch запросы.

http2 я и так использую, мне просто не нравится что куча отдельных запросов и обработчиков для них. Хочу сделать один большущий :3

Извращенец :3

Хочу сделать один большущий

А что тут лепить?

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

/get-data?foo&fooParam[]=1&fooParam[]=2&bar&barParam[]=a&barParam[]=b

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

буферизация выхлопа - AJAX response buffering

можно еще что-то типа мультиплексирование ответов

Утипути какие мы толстые. Сильно зависит от реализации же.

Есть и batch, который считается очнеь даже прямым способом. А возможно просто отдавать целое дерево и парсить его на стороне сервера в запросы.

А ещё, сложные sql запросы и есть подобная вещь)

В реальных приложения это не так просто, ведь запросы могут зависеть друг от друга, причём как на клиентской стороне(то есть надо принимать решения на основе ответов на запросы), так и на серверной(последовательность запросов может играть роль, например если мы создаём какой-то ресурс, в котором потом другой и тд. И тут играет роль получилось ли нам создать родительский ресурс или нет).

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

2 чая этому господину