Сергей Протько

json - это удобный формат сериализации данных. Возможность сериализации/десериализации в json есть буквально во всех языках программирования что делает этот формат довольно универсальным.

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

вот есть вроде бы официальная документация и все такое...

https://nodejs.org/en/download/package-manager/#de...

вам дела делать или играться? Если играться - попишите на ноде, заодно и опыта наберетесь. А если дела делать - php, раз опыт есть.

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

вызов GC вручную

И как это могло бы помочь интересно.

сокет сервер таким образом не справляется с нагрузкой?

если там есть внутри буфер сообщений на отправку - то вполне может просто не успевать отправлять сообщеньки.

Node.js - кросплатформенный. .NET - нет (пока во всяком случае).

Mono для серьезных проектов не особо прикольно использовать.

Что более перспективно в принципе?

Если не можете определиться - выучите и то и то. Будет пользы больше чем эти метания.

TDD

- пишем тесты - маленький кусочек, то что можно минут за 10 написать. На этом этапе мы формулируем что мы хотим написать.
- пишем код - пишем код, который делает тесты "зелеными". то есть все работает. Мы делаем это максимально быстро, самым тупым способом, который просто быстрее всего сделать.
- рефакторинг - после того как все работает, или еще через пару итераций, что бы набралось чуть больше "грязи", чистим код поочередно. Важно при рефакторинге чистить что-то одно. Либо код, либо тесты (да да, их тоже надо рефакторить иногда устраняя дублирование). Поправили код - прогнали тесты, все хорошо? тогда можно тесты подправить. Ну и т.д.

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

TDD - для одного разработчика, BDD - для команды. А BDD-style assertions для chai - это пафос. По сути это "планирование фич" в рамках библиотек и отдельных объектов. Чуть меньший масштаб. Но ничем от TDD вообще не отличается, хотя если сильно постараться можно так же оценивать ценность фич для пользователей нашей библиотеки и т.д.

Как никак в BDD основная мысль - фичаспеки должен иметь возможность читать продукт оунер или стэкхолдеры, то есть те кому проект собственно нужен, что бы говорить должно работать так или нет. В случае с библиотеками... ну вы пишите что-то для девелоперов, а они в состоянии читать тесты как фичаспеку. И в принципе от предметной области недалеко.

Раньше я объявлял приватные свойства и методы так:

Раньше вы криво создавали объекты и у вас получалась кривая реализация паттерна "модуль". Да и "свойства и методы" ваши приватные они как бы не совсем свойства и методы, это просто переменные (статические свойства в терминах java) и функции.

Или я что-то упустил?

Инкапсуляция в javascript достигается и достигалась ранее за счет модулей (сокрытие переменных в дочернем скоупе.

let privateStaticVar = 'foo';

// то что экспортируется - то публичное
export default class MyClass() {
    constructor() {
    }
}

// или

export default (function () {
    let foo = 'foo';

    return class FooBar {
         constructor() {
         }
    };
}());

Ну и в es2015 добавились символы как простой вариант сделать настоящие приватные переменные, ну и еще есть weakmap.

const privateFoo = Symbol('foo');

export default FooBar {
    constructor(foo) {
       this[privateFoo] = foo;
    }
}

1) пишем тесты на API
2) делаем как удобно, пока у нас есть тесты мы можем быстро подправить.

Отдельно рекомендую глянуть jsonapi.org

нотификации это как чат н только без возможности ответить.

socket-io и вперед.

PHP, ловите хоть тысячу сегфолтов в день и все будет работать.

В целом все зависит от задачи. Сделать плохо можно на чем угодно.

вопрос архитектуры. Нужно понимать как работает node.js, а именно в чем преимущества и недостатки event loop (полно и тех и тех), и нужно понимать как строить приложение в обход недостатков используя только преимущества. В целом же можно сделать массу различных прикольных вещей. Хотя новичку легко все упороть.

Вы же под ботами понимаете какую-то систему принятия решений, так?

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