Реализация API на вебсокетах

Что за набор детсадовских базвордов. С чего ты взял, что реальность всех ограничена реалиями твоего колхоза?

Где валидация

Расскажи мне про хттп-валидацию, вася.

где секурити

Сообщаю новость, никакой секурити и прочих базвордов в хттп нет, секурити в твоём колхозе обеспечивает ssl/tls, которая точно так же обеспечивает его и для вс.

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

Я вот не понимаю, зачем ты лезешь туда, где нихрена не понимаешь? Ты не осилил базовые вещи. Сообщаю новость, в контекст вс/сокетов не нужно определять «какой из клиентов внул запрос», клиенты никаких запросов не пинают.

Что за балаболы с их колхозным мышлением.

как отключить сессию

Сообщаю новость, никакие сессии ненужны. Опять колхозные представления. Зачем ты лезешь куда-то, если твои представления о реальности не вышли за пределы детсада?

где пингалка чтобы следить за отпавшими запросами

Никаких отпавших запросов нет. Опять детсадовские потуги. Отпадает оно на том уровне, который находится за пределами твоего понимания.

где возможность фалбачнуться на хттп?

Кому и зачем нужен такой мусор как хттп? Твоему колхозу? Ну да это меня не интересует.

Где в конце концов возможность сгенерить жс клиента для апи чтобы не писать все запросы руками?

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

ЗЫ: У меня в проде жсон рпц через вебсокеты живет.

Зачем ты пытаешься меня обмануть? Ты не понимаешь даже базовые вещи, которые должен понимать любой, кто хоть раз осознанно использовал подобные методы. Помыл полы рядом с тем, кто заюзал какую-то говнолибу - это не значит, что что-то там и у тебя. Слишком переоцениваешь себя.

Есть что возразить?

Несколько AJAX-запросов? Вряд ли.

Я вот вас, форумных балаболов, не понимаю. Ты даже реалий своего хттп не знаешь, но яро пытаешься его защищать.

Сообщаю новость, осознай это. Хттп не может в несколько запросов, это очевидно. И очевидно то, что несколько запросов требуют несколько хттп. Скрываем покровы.

браузер лучше знает, как грузить быстрей, зачем ты его хочешь замедлить?

Эти мечты, эти надежды тех, кто ничего в теме не понимает. Ничего нового.

Конечно. RPC синхронный по определению: на входе аргументы, на выходе - возвращаемый результат. А если это разделить, то нет никакого procedure call.

Я уже твои рассуждения помножил на ноль, но ты продолжаешь. Модераторы ведь почистят.

Вообще говоря, тезис о том, что одно TCP-соединение лучше и быстрее нескольких, срабатывает не всегда - это зависит от того, какие-данные, какого объема и как часто реально гоняются по соединению. Гляньте хотя бы предыдущее замечание насчет HTTP/2.

Основания для данного утверждения в студию.

Использовать REST-подход, как уже было сказано выше, никто не заставляет — это актуально, только если для проекта существенна возможность промежуточного кэширования HTTP-ответов сторонними сервисами.

Рассуждения смысла не имеют. Всегда есть сервисы, которые работают с ограниченным набором базвордов, но это мало кого волнует.

Опять же, никакой rest никто не закэширует. Ты можешь попытаться рассказать мне о том, как ты будешь поддерживать кэш в актуальном состоянии. Только вот, у тебя вряд-ли это получится.

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

Что касается полного перевода API c HTTP на WebSocket, то тут, увы, есть одна заковыка, которая сразу ограничивает область применимости вашего подхода - это SEO.

Да тут у нас эксперты заехали. Сео на данные у него случилось. Ты опять что-то перепутал.

Если вы собираетесь «штамповать SPA сайты», то вы должны знать, как в настоящее время реально обеспечивается индексирование SPA-сайтов в основных поисковых системах.

А, дак пациент опять перепутал базворды. Это не удивительно, когда ты балабол. Причём тут spa, если мы говорим о api через ws?

Так что, таким образом можно более-менее спокойно поступить только с той частью API, которая не имеет отношения к формированию индексируемого контента. Всё остальное надо изначально увязывать с поддержкой SEO.

Тут явно прослеживается альтернативно-одарённое восприятие реальности. Каким образом api, по которому передаётся контент для заполнения индексированной страницы может как-то повлиять на её индексацию - ведомо только подобных пациентам.

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

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

RPC синхронный по определению: на входе аргументы, на выходе - возвращаемый результат. А если это разделить, то нет никакого procedure call.

Странные у тебя представления.

Обычные.

Асинхронщина никак не отменяет факт вызова, опять же.

Вызов отменяет асинхронщину. Иначе это не вызов, а посылка сообщения с явным ожиданием ответа.

айдишник для каждого запроса по-твоему зачем передают?

айдишник для каждого запроса по-твоему зачем передают?

А по твоему - зачем?

Причём тут spa, если мы говорим о api через ws?

TC: «Я сейчас занимаюсь только тем что штампую SPA. Так вот у меня все равно уведомления через веб сокеты работают. Зачем мне сранный REST?»

Предлагается весь API spa-сайтов перевести на WS. Ну, т.е. грузится, к примеру, в веб-обозреватель статичная SPA-заглушка, а остальное выгребается с веб-сервера через WS.

Соответственно, вопрос: а что и как будет получать поисковый робот? Вот, к примеру, Гугл и другие поисковики заявляют, что их роботы будут вскорости (или уже) сами выдавать нужные AJAX-запросы, но это не относится к WS.

Тут собственно вопрос к ТС: каким образом сейчас обеспечивается индексирование SPA-сайтов, которые он уже наклепал? Какую роль играет API в формировании начального содержимого страницы?

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

О гуглоботе

Гуглобот:

* Не сохраняет состояния (не принимает куки, не использует локальное хранилише) * Не понимает ES 6 (поэтому через Babel vue-говно компилируют в ES 2015) * поддерживает только HTTP/1.x и FTP, протокол WebSocket не поддерживает

Но мне эти ограничения по барабану. Для гуглобота есть одностраничник.

* лендинг

Обычные.

Нет.

Вызов отменяет асинхронщину.

В параллельной реальности да, в этой - нет.

Иначе это не вызов, а посылка сообщения с явным ожиданием ответа.

Ога, чем отличается это посылка об любой другой, в частности синхронной? Почему это явное, а там не явное ожидание ответа?

В рамках вызова вызов синхронный, поэтому это именно вызов. Давай на примере:

//client
@rpc
f();

//выглядит использование так:
const value = await f();//соответственно, это реальный вызов функции. Он является "синхронным" в твоём представлении, т.е. он лочит поток исполнения.

В крестах же, очевидно, это выглядит так: auto value = f(); Ведь кресты позволяют реализовать реально лочить поток исполнения, а не эмулировать это( как в жабаскрипте).

гугл давно аякс-сайты индексирует

Ну, скажем прямо, далеко не все, а только те, которые HTML-снапшоты выдают или у которых все нужные AJAX-запросы выдаются на определенной стадии формирования DOM.

я интерактивные веб-приложения делаю, а не сайты в обычном понимании. мне индексация не нужна

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

Тогда вообще нет никаких вопросов )

TC: «Я сейчас занимаюсь только тем что штампую SPA. Так вот у меня все равно уведомления через веб сокеты работают. Зачем мне сранный REST?»

Это не имеет никакого отношения к тому, о чём ты говорил ранее. Опять же, SPA могут(и в 95% случаев работают) работать через rest/http и любое другое дерьмо. SPA не является следствием ws/rpc.

Предлагается весь API spa-сайтов перевести на WS. Ну, т.е. грузится, к примеру, в веб-обозреватель статичная SPA-заглушка, а остальное выгребается с веб-сервера через WS.

Ты явно не понимаешь как это работает. Ты пытаешься натягивать свои хттп-пхп представления на spa. Суть spa в генерации представления контента, очевидно, что сам транспорт для контента - никого не волнует. Да, есть нюансы, но к данном теме они отношения не имеют.

В ситуации с spa через ws через rpc никакого веб-сервера нет. Ты опять всё перепутал.

Соответственно, вопрос: а что и как будет получать поисковый робот?

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

И опять же, всё это никак не связано с каким-то ws/rpc.

Вот, к примеру, Гугл и другие поисковики заявляют, что их роботы будут вскорости (или уже) сами выдавать нужные AJAX-запросы, но это не относится к WS.

Опять же, ты нихрена не понимаешь того, о чём пишешь. Ты пишешь полную и тотальную херню. Никакие хренак-запросы никакой гугл вскорости выдавать куда-то не будет, это очевидно.

Давай я тебе помогу. Основная проблема в том, что контент является динамическим, а поисковик обрабатывает статистические файлы. Очевидно, что если у тебя есть любой днище-запрос, то никакой гугл с ним ничего не следует - ведь он не сможет исполнить ту логику, которая обрабатывает и вызывает той днище-запрос. Это очевидно.

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

Тут собственно вопрос к ТС: каким образом сейчас обеспечивается индексирование SPA-сайтов, которые он уже наклепал? Какую роль играет API в формировании начального содержимого страницы?

Мне лень объяснять тебе базовые вещи, которые ты должен сам понимать прежде, чем вещать и скрывать покровы в интернете.

А) с чего ты взял, что ему нужно какое-то индексирование динамического контента?

б) с чего ты взял, что в рамках spa нельзя организовать сервер-сайд рендеринг для ботов? Либо просто реализовать специальный бот-интерфейс.

в) с чего ты взял, что твои рассуждения об спа имеют хоть какое-то отношение к вс/рпц?

Ну, скажем прямо, далеко не все, а только те, которые HTML-снапшоты выдают или у которых все нужные AJAX-запросы выдаются на определенной стадии формирования DOM.

Неверно. Это работает именно так, как я предполагал ранее. Ни о каких снашпротах, стадиях и прочей херне оно не знает - это существует только в твоих фантазиях. Оно просто исполняет код на странице( с некими ограничениями) и позволяет ему формировать контент(хтпл) который потом парсит как обычный робот. Ему абсолютно насрать что ты там передаёшь по хренаксу или любой другой херне.

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

Это очевидно, и если это не очевидно тебе, то это чисто твоя проблема.

//client
@rpc
f();

Это и есть параллельная реальность.

const value = await f();

А это - _асинхронный_ вызов. Не просто procedure call, а asynchronous procedure call. Чувствуешь разницу? Хотя, наверное, нет.

Пошли манёвры. С чего вдруг ты проигнорировал пример с крестами? Тут уже можно констатировать слив.

А это - _асинхронный_ вызов.

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

В чём заключаются эти глупые попытки манипулировать. Дело в том, что в жабаскрипте просто нет такого понятия как синхронные вызовы для io, да и для почти всего. Т.е. что угодно в жс будет асинхронным, хоть какая имплементация rpc.

Из этого следует только одно. Данный пациент игнорируя пример на языке, на котором синхронное io существует, пытается выдать свойство самого языка(io api) за свойство rpc.

Это вся суть тутошних экспертов.

С чего вдруг ты проигнорировал пример с крестами?

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

Тут уже можно констатировать слив.

Это единственное, что ты умеешь.

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

С чего вдруг это не C++? Обосновывай. Если ты не знаешь язык, а ты его не знаешь, и если ты не понимаешь как это реализовать - не утверждай, а спрашивай.

Кстати, почему ты не отвечаешь на все остальное? Куда пропали сообщения? Куда пропало всё остальное?

С чего вдруг это не C++?

С того, что в Си++ пока нет ключевого слова await и конструкции @rpc (я подразумеваю, что это атрибут, и ты пытался написать [[rpc]]).

Кстати, почему ты не отвечаешь на все остальное? Куда пропали сообщения? Куда пропало всё остальное?

Без понятия. Возможно, они были продуктом твоего воображения.

Какой же наивный. Я вот не понимаю, что на тебя нашло и ты решил со мною поспорить. Хотя должен знать исход, ладно.

С того, что в Си++ пока нет ключевого слова await и конструкции @rpc (я подразумеваю, что это атрибут, и ты пытался написать [[rpc]]).

Вот это ты зря.

В крестах же, очевидно, это выглядит так: auto value = f();

Внимание вопрос, кто и где пациенту утверждал, что код был на С++?

Без понятия. Возможно, они были продуктом твоего воображения.

Хорошо. Пытаешься играть на моей снисходительности к тебе, хорошо - её не будет.

Внимание вопрос, кто и где пациенту утверждал, что код был на С++?

Ты попросил обосновать, почему этот код не Си++ - я обосновал. Вопросы есть?

Пытаешься играть на моей снисходительности к тебе, хорошо - её не будет.

Как ты меня напугал.

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

Именно это Гугл уже и делает, но только позволяет «исполняться» до определенного момента, что возможно только при использовании HTTP-AJAX и определенных правилах реализации SPA-логики.

с чего ты взял, что в рамках spa нельзя организовать сервер-сайд рендеринг для ботов? Либо просто реализовать специальный бот-интерфейс.

Можно - я этим лично занимался ) Но достаточно сложно. И WS эту задачу еще более усложняет.
Но эту тему уже не имеет смысла обсуждать в связи с пояснением ТС-а.

Тебе повезло и эта дристня действительно не умеет ws, но это ничего не меняет - ведь этой чистая случайность

Это не случайность, а принципиальный момент. Просто движок робота при использовании AJAX может определить для себя тот момент, когда следует остановиться и просто догрести нужные AJAX-ответы. А вот при WS у него такой возможности нет - требуется какой-то специальный сигнал от сайта, что, мол, уже можно DOM сериализовать в HTML. А Гуглы пока таких сигналов знать и специфицировать не хотят.

Неверно. Это работает именно так, как я предполагал ранее. Ни о каких снашпротах, стадиях и прочей херне оно не знает - это существует только в твоих фантазиях.

Еще как знает ) Вы просто не знакомы с соответствующими спецификациями от Гугла - видимо, только сейчас по ходу дела что-то для себя выясняете в этой новой для вас теме. А я в это деле разбираюсь очень хорошо, поскольку занимался индексированием SPA-сайта в Яндексе, Google, Bing, Mail.RU и пр. Соответственно, мне знакомы все тонкие моменты.

Хорошо. Начнём сначала.

Вызов отменяет асинхронщину. Иначе это не вызов, а посылка сообщения с явным ожиданием ответа.
Не просто procedure call, а asynchronous procedure call.

Оправдывайся.

Вызов отменяет асинхронщину. Иначе это не вызов, а посылка сообщения с явным ожиданием ответа.
Не просто procedure call, а asynchronous procedure call.

Оправдывайся.

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

Оправдывайся. Каким образом у тебя в одной потуге были сообщения, а потом ты вдруг сел в лужу и уже появились вызовы. Тебе нужно объяснить, почему первая ахинея противоречит второй.

Хотя ты уже сел в лужу. Ничего нового, очередной балабол в очередной раз обделался.

Оправдывайся.

Читай: Реализация API на вебсокетах (комментарий)

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

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

В очередной раз мы убедились

«Только редакторы газет и люди с глистами имеют право говорить о себе „мы“» (ц) М.Твен.

И ты явно не редактор газеты.

И самое главное, с чего вдруг балабол решил, что я говорю о себе?

А ты не можешь говорить от имени других. Хотя, если это твои воображаемые друзья... да, Марк Твен был не совсем прав.

Хттп не может в несколько запросов

Может. Учи матчасть.

Не может. Ну ты можешь попытаться, я даже заранее могу сказать, о чём ты будешь мне вещать. Где-то услышал базворд типа keep-alive, и уже показалось, что что-то может. Я тебе сообщаю, ничего не может.

Погугли HTTP 2 multiplexing

при наличии WebAssebly, http вообще теперь нужен максимум для бутстрапа и всё.

И без наличия васма этот мусор так же не нужен. А бутстрап через хттп - это просто текущие ограничения броузера, не более. Легаси мусор с которым приходится жить.

Хотя опять же, даже тут никакой хттп не нужен. Там нужно как максимум get по / и не более. Это не является хттп в полной мере, даже в частичной.

это просто текущие ограничения броузера, не более. Легаси мусор с которым приходится жить.

Первое «царское» мудрое замечание в этой теме )))))))))))))
Именно - ПРИХОДИТСЯ. Порой - годами. И от этого никуда не деться. Это та реальность, с которой приходится считаться и которую вот так запросто никуда не отбросишь )

Хорошо, когда твой сайт не работает у части клиентов?

Ну так, через прокси всякие боты зато лазить не будут. Да и вообще, честным людям проски не нужны. А огранизации пускай организуют нормальный nat, чем это извратное прокси.

Соответственно, вопрос: а что и как будет получать поисковый робот? Вот, к примеру, Гугл и другие поисковики заявляют, что их роботы будут вскорости (или уже) сами выдавать нужные AJAX-запросы, но это не относится к WS.

Сгенеренную статику. Дергание AJAX ботом - это не нужно. Страница генерится дольше, индекс сайта ниже.

Сгенеренную статику. Дергание AJAX ботом - это не нужно. Страница генерится дольше, индекс сайта ниже.

Заранее генерить статику для нормального, динамически меняющегося сайта невозможно - это лишний гемор и проблемы всяких несостыковок, которые могут отразиться на позициях сайта. Генерить статику (то, что называется HTML-снапшотом) надо на лету. И тут возникают всякие тонкие моменты.

Насчет дергания AJAX ботом - на мой взляд это тоже не очень нужно. Разве что, для простеньких сайтов, где людям вообще лень заморачиваться на SEO. Но Гугл пока считает по другому и перевел снапшоты в статус «deprecated» - куда всё это в конечном итоге придет, зависит от наличия здравого смысла у соответствующих гугловых «начальников». Надо сказать, в наличии этого здравого смысла я очень сильно сомневаюсь.

Rule 14: Do not argue with trolls

Я меру в общении с троллями знаю ) Общаться с ними можно сколько угодно - просто не следует «разводиться» на эмоции (то, чем они питаются). На самом деле, любой тролль зарвавшись может сам себя опустить - что уже и произошло, когда «царёк» полез рассуждать о вопросах, в которых он вообще ни бельмеса не понимает (типа, слышал звон, да не понял, где он), а вот многие другие понимают...

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

Например какого? Для магазина, скажем, проблем особых нет. Залил товар, обновил статику.

Например какого? Для магазина, скажем, проблем особых нет. Залил товар, обновил статику.

Хорошо, когда только ты заливаешь - а когда абсолютно другие люди в произвольный момент времени? Суется бот по ссылке, полученной на одной странице, а снапшота еще нет. Замечание в кабинете, отметочка в БД поисковика по поводу недостаточного качества...

Опять же, генерить-то нужно тем же способом, что и на лету - сериализовать DOM в HTML. Ну и к чему вся эта ручная деятельность, плюс, штатная обязанность заливщика? )
Но это мы уже полезли совсем в другую тему.

Хорошо, когда только ты заливаешь - а когда абсолютно другие люди в произвольный момент времени?

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

Дёргаешь обновление статики автоматом после заливки позиции

Чтобы обеспечить целостность представления статики для бота, нужно делать все аккуратно. Если говорить просто о полном обновлении статики (чтобы не заморачиваться на всякие мелочи и дополнительное программирование этого дела), то это достаточно «грузящая» процедура. Лишнее барахло на сервере - лишняя морока.

Ну, собственно, это дело хозяйское - каждый решает сам. Но моя точка зрения не такая уж и особенная. Заходим на prerender.io и видим: «We've served over 32 billion pages to search engine crawlers!» )

Не, я серьёзно, но да неверно выразился,nginx нелимитирован,а вот железо и канал да, если у меня в переди прокси на nginx, а позади него 10 сервов гигабитных и на каждом kore висит и на каждый из них пойдёт 500000 запросов... ну ты понял. Это я про то что при таких нагрузках балансировку можно в клиент отдать, а проксирование исключить вовсе либо чисто балансировщик который будет по 301 пересылать на наиболее свободные серваки. Ну в общем я вот про это, и дадада выразился неверно )) Не бубни музыкант)

Ути-пути, мамеменькин прогромист. Приходи после того как поработаешь хотя бы пол года. А то читать ты научился а понимать, что прочитал ещё нет.

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

гарантировать не просто доставку, а корректную обработку сообщения

Конечный автомат на сообщениях без проблем это все реализует. Испокон веков пользовательские интерфейсы являются конечными автоматами и общаются с внешним миром посредством обработки/генерации событий.

Хттпшная концепция запрос/ответ не очень подходит для этого, именно по этой причине джаваскрипт в браузере работает через асинхронную обертку.

не могу не добавить говнеца чего требует специфика лора

Обилие макак от кодинга привело к появлению всевозможных синхронных оберток над асинхронной оберткой (async/await ага). Потому что макака, отправив запрос, может забыть что она его отправила, и соответственно забыть что нужно написать обработчик.