Просто делимся мудростью

Ну ты ошибся с выбором, только и всего)

Существуют ли какие-либо good practice или соглашения для проектирования API на WebSocket?

Сама главная мудрость - не использовать что-то, если можно не использовать

есть еще post + sse если што

зависит от кейса опять же

Как израиль?

збс

не ожидал

девки страшные только

А я вот возвращаюсь домой

90%

Што

Ну, што што?

я уже из Екб вернулся

еще после израиля

Пью вторую бутылку винишка в бизнес-лаунже

Быстр

Привет, есть чат по работе Node.JS?

кому интересно поработать над p2p/crypto-сетью (as is) стучите в личку.

Привет, есть чат по работе Node.JS?

попробуй поискать в @javascript_jobs

Привет, есть чат по работе Node.JS?

telegram.me/nodejs_jobs Только сегодня парень создал

А как можно хранить объекты для отдельного пользователя? Например есть функция: ``` function getMoneyApi(id) { return new Promise(function (resolve, reject) { if (!api) { Account.findById(id) .then(user=> { if (!user.yMoneyToken) reject('NEED_TOKEN'); api = new yandexMoney.Wallet(user.yMoneyToken); resolve(); }) } else { resolve(); } }); } ``` И вот чтобы каждый раз в бд не лезть для инициализации. Можно ли хранить как нибудь типа req.session.moneyApi при использовании express и express-session

this.tmp[id] = new yandexMoney.Wallet(user.yMoneyToken)

А как долго будет храниться? До перезапуска сервера?

Ну максимально можно в пределах процесса при желании до перезапуска хранить, все от области видимости зависит

Лишь бы оперативку всю не сожрало на всякие кеши )

Спасибо :)

По HTTP я должен буду ждать ответа. А по сокету я просто подпишусь на событие.

Обоже

Обоже

Что?

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

Ой, все. Вот я еду в метро и смотрю сайты с мобильного. Инет несколько раз за поездку пропадает. long polling тут идеален

Истина

А вебсокеты просрут все это.

Потому надо быть готовым к тому что коннективити то есть, то его нет.

И лучше еще уметь батчить события, чтобы клиенту оно приехало пачкой

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

Мне нужно понять, почему.

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

Это все сокеты решать не помогают

Это все сокеты решать не помогают

Так можно же реализовать событийную систему подтверждений чего угодно.

Да

Без сокетов

Что за консерватизм. =)

Добрый день. Довольно такой дуратский вопрос, но как получить размер файла из POST запроса? Отправляю multipart. Получаю content_type, но размер там немного больше чем размер файла. Поэтому и хочется узнать как получить именно размер файла

Я так понимаю, проблема в том, что сообщение может не дойти, а отправитель может не знать, что сообщение не получено адресатом, верно?

Что за консерватизм. =)

Если что-то существует, то это не обязательно надо срочно использовать

Либо теряются данные, либо там учитывается размер всего http заголовка и прочего

Что за консерватизм. =)

Это нежелание делать звездолёты из говна и палок

Если что-то существует, то это не обязательно надо срочно использовать

Моя мотивация — отнюдь не фетишизм. =) Просто я хочу построить архитектуру приложения определенным образом.

Ну то есть фетешизм)

Ну то есть фетешизм)

Вообще необоснованное утверждение.

Моя мотивация — отнюдь не фетишизм. =) Просто я хочу построить архитектуру приложения определенным образом.

Зачем?

Вообще необоснованное утверждение.

Ты не хочешь решать задачи, ты хочешь забацать определенную архитектуру

Ну и. Вот

Ты не хочешь решать задачи, ты хочешь забацать определенную архитектуру

Этот вопрос тебе наверняка не известен.

Телепаты в треде

Ты только что это сказал вообще то

Это твой домысел, и вообще, не очень вежливо.

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

Этот вопрос тебе наверняка не известен.

Зачем тебе именно _определенная_ архитектура?

Это твой домысел, и вообще, не очень вежливо.

— Двач, ем с ножа, постоянно порезан рот, как лечить? — Просто не ешь с ножа — НЕ УЧИТЕ МЕНЯ ЖИТЬ, Я СПРОСИЛ КОНКРЕТНЫЙ ВОПРОС

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

Эу... Так ты не в курсе мой задачи. Я её хочу сам решить. А сюда пришёл с конкретным, узким вопросом.

— Двач, ем с ножа, постоянно порезан рот, как лечить? — Просто не ешь с ножа — НЕ УЧИТЕ МЕНЯ ЖИТЬ, Я СПРОСИЛ КОНКРЕТНЫЙ ВОПРОС

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

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

Правильно, а вебсокеты — не оверхед))

Перебоев не будет, т.к. клиент и сервер — одна машина.

Молчу-молчу

ERROR: S client not available

Короче, ты делаешь микросервисы

?

Правильно, а вебсокеты — не оверхед))

Нет. Мне всё равно нужно будет реализовать медиатор. Если событие будет попадать ещё и в сокет инстанс, архитектура не так усложнится, как это было бы в случае с рестом.

Короче, ты делаешь микросервисы

Нет. Там будет взаимодействие с аппаратной частью машины.

...

Я весь тред не читал

Но откуда у http преимущества в плане сорханности перед ws?

Если сохранность обоих регулируется tcp

.. a TCP не гарантирует доставку сообщений …

udp не гарантирует

tcp как раз гарантирует

В отличие от датаграм

А какова необходимость над этим париться при доставке сообщений на localhost и обратно?

Перепутал наверное

Но это ключевое отличие udp vs tcp

Есть ещё вриант tcp over udp

Гугл что-то такое делали

Неважно, localhost или нет, я не понял доводы людей, который топят в треде за лонгполинг и какую-то там доволнительную сохранность (щито?)

Протокол UDP но есть проверки

Я теперь вообще запутался. Никто не привёл ни пруфов, ни хинтов, куда мне копать. =)

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

Ну да, он же отпал.

Ну и не страшно.

Ну да, он же отпал.

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

Если клиент стейтлес, то логично, что при старте нового соединения, он запрашивает своё состояние у "источника правды".

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

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

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

Я не придераюсь, я наоборот за вас :)

Ок =)

Если клиент стейтлес, то логично, что при старте нового соединения, он запрашивает своё состояние у "источника правды".

Если клиент стейтлес, то тут и tcp не нужны, если можно использовать udp (ибо сам udp будет содержать состояние)

Если клиент стейтлес, то тут и tcp не нужны, если можно использовать udp (ибо сам udp будет содержать состояние)

>udp будет держать состояние Што

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