Тимур Шемсединов: еще раз, что значит "синтаксис JS" в контексте структур данных? Данные гоняются в бинарном или текстовом виде? Если первое - то чем это отличается от messagepack/thrift? Если второе - то это же json, нет?
что-что простите? Тип нэйтив экстеншенами структурки гоняете в сыром виде? Ну так это же на корню убивает возможность заимплементить другую часть системы на чем-то другом нежели js. И я не думаю что способ этот эффективнее messagepack или thrift.
Тимур Шемсединов: в целом я вижу смысл переходить на вещи вроде zeromq (не голые же сокеты использовать, да?) только тогда когда http узкое место, как минимум потому что дебажить и поддерживать проще. Сколько уже команд обожглось от этих преждевременных оптимизаций.
chupasaurus: не совсем так. У вас децентрилизованное общение происходит. То есть например в пределах 5-ти клиентов один может выступать сервером для остальных, но для 1000 клиентов можно выстроить более интересные топологии. В целом же в случае webrtc это все чуть проще.
NeoCode: объясните мне, зачем вам сравнение "всех фреймворков"?) Если архитектура фреймворка влияет на приложение - это так себе фреймворк. Например возьмем Yii - у него топорная архитектура, половина принципов нарушена, высокая связанность.... зато прототипы на нем клепать одно удовольствие. Другое дело что после придется все переписать.
Или например возьмем Symfony. Сам по себе он вообще не влияет ни на что. Все через IoC, максимум контроллеры что-то знают о фреймворке. В документации основная идея описывающая архитектуру описана. И ваш код не должен знать об архитектуре фреймворка.
Так же и Laravel например, просто из коробки идет ORM с высокой связанностью с базой данных.
Короче изучать фреймворки - глупо. Если слова "высокое зацепление" вам что-то говорят то в принципе просто возьмите Symfony или Zend, как я уже говорил. Ну и php the right way почитайте. Знание паттернов вообще ничего не дает, нужно понимание того, какие проблемы оно решает и за счет чего.
NeoCode: ну и да... литература вроде книг Эванса или там Макконела это такая штука, которую после прочтения надо будет где-нибудь через пол годика-годик перечитать. Ибо материал весьма сложный, хоть местами и может казаться очевидным. Эти очевидности быстро забываются. Ну и пометки тоже стоит делать какие-то для себя.
Так же перед Эвансом стоит примерно познакомиться с паттернами проектирования, так как там будут отсылки на них. У Эванса к примеру вы узнаете что фреймворк это второстепенная штука и в приложениях расчитанных на активный период поддержки > 5 лет например весьма критично отделить приложение от фреймворка.
NeoCode: я где-то предлагал изучать исходники фреймворков? Это глупо. Нужно примерно знать как работают абстракции которые ты используешь а не все досконально - жизни не хватит.
А по книгам - я дал вам указание на авторов, берем и читаем.
komarevtsev: руководствуйтесь таким понятием как coupling (связанность), cohesion (зацепление, сцепка), не делайте single point of failure и все будет хорошо. У вас сейчас как раз таки single point of failure, если сокет сервер упал - у вас ни один микросервис не может работать. Ну и опять же, вдруг вы когда-нибудь решите что часть микросервисов должны общаться по http например в угоду простоты разработки.
