Timur Shemsedinov
@MarcusAurelius
Chief Technology Architect at Metarhia
Information
- Rating
- Does not participate
- Location
- Киев, Киевская обл., Украина
- Date of birth
- Registered
- Activity
Chief Technology Architect at Metarhia
Information
Вполне хороший подход, когда вся статика работает через REST, это же файлы их так и обрабатывает с отдельного домена, а вся динамика работает через RPC и вебсокеты (с другого домена), а урлы идентифицируют не ресурсы, а методы (глаголы). Более того, когда на клиенте развивается направление байндинга данных и GUI (тот же React), то байндить же можно и дальше сквозь сокет прямо на сервер и это прекрасно. При чем, синхронизацию состояний можно оптимизировать, чтобы не передавать все изменения мгновенно, а накапливать буфер или за малый временной промежуток и пересылать пачкой. В базу или на диск сервер может читать/писать исключительно в отложенном режиме, состояние нужно конечно персистать, но это же не нужно делать прямо во время запроса, можно отдать ответ и уже неспешно сохранить, да еще и склеить изменения за определенное время.
В общем, я к тому, что не нужно выкручивать себе руки и все тулить через REST, не нужно стараться впихнуть невпихуемое, в результате развивается промышленное производство костылей и велосипедов в особо крупных масштабах.
Тут подробнее http://habrahabr.ru/post/204958/
Тут видно, что я пишу хартбит для каждой вкладки, старые хартбиты удаляются мастером, как только время хартбита устаревает, вкладка или закрыта или зависла. Новые вкладки занимают место (слоты) старых. Работает это по принципу «один за всех, и все за одного», т.е. мастер следит за каждым, а за мастером следят все. Отдельно пишется impress.rpc.master — id текущего мастера и impress.rpc.newtab — id последней созданной вкладки. Писать impress.rpc.master нужно потому, что это создает событие изменения localStorage и все клиенты быстрее понимают, что новый мастер уже выбран, а impress.rpc.newtab так же создает событие изменения localStorage для того, чтобы мастер быстрее отправил свой хартбит, это ускоряет подключение новой вкладки при старте. В общем, вышло нетривиальное решение. Надеюсь, это поможет при реализации кода.
2. Моделирование данных, как по мне, это более важная дисциплина, даже чем теория алгоритмов, и вот структуры данных, лучше поместить именно в моделирование данных, (а не в теорию алгоритмов), рядом с реляционной, иерархической, сетевой и др. моделями данных.
3. Жаль, что не увидел в этой схеме место кибернетики (науки об управлении), за то управлению командами разработки, по сути менеджементу (лженауке об управлении) место нашлось.
Одна из основных фич в том, что на одном порту можно сделать все, мультиплексируется по урлам, на одном урле SSE, на другом WebSocket, и тех же событийных каналов много можно одновременно на разных урлах держать, ну и на том же порту API и стриминг и статика и контент и все остальное. На ноде же обычно много портов открыто для каждой задачи специфический порт, и так выходит, что даже для не очень сложных приложений уже 2-5 портов открыто. А потом какой-то маршрутизатор рубит все кроме 80 или CORS не пропускает или еще что-то, в общем мультиплексирование в ноде не развито совсем.