These are chat archives for NodejsRUS/chat

22nd
Jan 2016
Andrey Gurtovoy
@jt3k
Jan 22 2016 08:55

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

Чтобы эту трубу оседлать нужно писать свой протокол на котором твой сервер и клиент будет общаться по этой трубе.

Нужна реализация аля ремоте-процедуре-колл

This message was deleted
Vadim Petrov
@imposibrus
Jan 22 2016 09:02
@jt3k RPC-style колбэки есть в socket.io.
что я уже только ни писал, но вот протокол для взаимодействия клиента и сервера - точно нет) обычно, если в protobuf не завернуть, то использую json. формат описывал в доках к API. правда, RPC я в продакте нигде не использовал, может там своя атмосфера)
Andrey Gurtovoy
@jt3k
Jan 22 2016 09:06

я придумал такой подход
клиент шлёт серверу

{
  command: 'myFunc',
  args: [1,2,'verbose'],
  identificator: 'uniqid_123'
} ;

сервер принимает запрос и на сервере есть объект с привязками строчек команд и функций. Примерно вот такой

let cmds = {
  myFunc:  myfuncs.myMegaFunc0,
  myFunc1: myfuncs.myMegaFunc1
};

Я запускаю эти функции вот так

let answer = cmds[request.command].apply(myfuncs, request.args);
let answerObj = {
  id: request.id,
  answer: ansver
};

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

@imposibrus ок, понял, спасибо. надо сокет.ио потыркать

Andrey Gurtovoy
@jt3k
Jan 22 2016 09:27

Ещё одна неприятность есть, и вопрос как с ней побороться.

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

Эти промисы запускаются по событиям от вебсокета,
То есть у меня есть объект установленого соединения клиента и сервера и на нём возникают события, которые я ловлю и выполняю промисы

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

Как Вы пишете мощные приложения чтобы код выглядил не как лапша ?

Я думаю добавить в приложение require('event') (это евент-емитер) и развязать этот код. Это норм решение, или это усложнит программу ?
сорри, пример кода не привожу. Но если есть желание поделиться серебряной пулей, или "проучить щегла, показав ему новые трюки", то велкам
Andrey Gurtovoy
@jt3k
Jan 22 2016 11:53
Есть живые ?
Kyrylo Yakovenko
@blia
Jan 22 2016 11:54
https://github.com/dev-ua/node тут поживее.
просто я ничо не понял. Но возможно там помогут.
Andrey Gurtovoy
@jt3k
Jan 22 2016 11:58
да про архитиктурку спросить хотел. как строить большие расширяемые приложения
Kyrylo Yakovenko
@blia
Jan 22 2016 11:58
это я как раз понял :)
могу поделиться своим подходом.
Andrey Gurtovoy
@jt3k
Jan 22 2016 11:59
о, давай
Kyrylo Yakovenko
@blia
Jan 22 2016 11:59
у меня архитектура построена на именованых раутах
АПИ не берем в счет. Там все ясно как 2+2
Andrey Gurtovoy
@jt3k
Jan 22 2016 12:00

/about
/disqus
/basket

о таких роутах говоришь ?

Kyrylo Yakovenko
@blia
Jan 22 2016 12:00
да
пишу
Kyrylo Yakovenko
@blia
Jan 22 2016 12:14

Именованные рауты на примере магазина

IndexPage - /
Categories - /categories
ProdutcsByCategory - /:category
ProductInfo - /item/:id

Я не делаю практически никогда вложенных раутов.

Раут имеет такие части

path = string/regExp/func - мэтчит собственно относится ли запрос к рауту и может возвращать некоторые данные для следующего этапа ()

model = async func - получает параметры и на их основе собирает все данные нужные для данного раута(формирует состояние приложения)

далее идет рендер - шаблон или жсон, в зависимости от Accept

Все рауты это get запросы имеющие четкое состояние без сайд эффектов

Далее у раута могут быть экшены - это уже различные POST/PUT... запросы мутирующие наше состояние приложения, например

ProductInfo - /item/:id может иметь экшены order/addToCart

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

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

При этом состояние предается через всю цепочку. От инициализации до рендера. И оно соответсвенно мутируется в процессе.

это у меня сформировалось после нескольких лет опыта работы с различными фреймворками. На сегодня мне этот подход кажется оптимальным для обычных сайтов
для api я использую готовые решения, типа sails/fortunejs/graphQL
можешь задавать вопросы
Andrey Gurtovoy
@jt3k
Jan 22 2016 12:40
нода уже умеет в async или у тя бабел?
Kyrylo Yakovenko
@blia
Jan 22 2016 12:41
у меня бабель, но не суть async я написал просто, что эта функция долгая с обращениями к базе. ЭТо может быть просто промис
вот функции path и render - быстрые без промисов.
Andrey Gurtovoy
@jt3k
Jan 22 2016 12:42
я частями почитаю, ... сейчас мало времени чтобы прочесть всё