Андрей

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

Суть юнит тестирования - тестировать только один юнит за раз, все остальное - моки. То есть мокать надо сам сервис а не $http

Вот до тех пор пока все будут учить фреймворки, а не принципы проектирования и то как работает браузер, у нас и будут появляться быдлокодеры. Это мысли в слух. Не в обиду автору.

Фреймворк это просто инструмент. Он за вас решит ряд вопросов. Позволит какие-то фичи сделать быстрее за счет того, что они уже были решены ранее. Но любой фреймворк можно изучить и применять за приемлемое время при условии, что у вас будут достаточно прокачанные скиллы по js, по тому как работает браузер, по тому как передается информации между клиентов и сервером (сокеты, xhr, cors и прочие свистелки).

Если вы новичок, то просто пишите код. Ставьте задачи. Смотрите как эти задачи решены были ранее в рамках любого фреймворка или библиотеки, прочитайте исходники.

Фреймворки, к сожалению, весьма подвержены моде. Раньше был тренд на Backbone.js, затем под ореолом Гугла все подхватили Angular.js, сейчас начинается повальное увлечение React.js. Завтра появится, что то новое, все кинутся на него.

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

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

А человек, который на ваш вопрос "Что мне изучать?" быстро и легко назовет имя любого фреймворка, скорее всего сам еще недостаточно прокачался, потому как он видимо не понимает, что нет "серебряной пули". Нет идеального фреймворка, который бы решал все ваши задачи.

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

— Сложно найти готовых к работе толковых программистов, даже среди фронтендщиков. Но можно обучить. На обучение и понимание среды nodejs, API, асинхронности, замыканий, калбэков, событий, функционального подхода — уходит примерно месяц-два.
— Библиотеки из форнтендов использовать можно, но только если они грамотно написаны и оптимизированы для перманентной работы. Иначе есть риск, что они сожрут всю память или повесятся.
— Сервер nodejs обычно однопоточный, со всеми вытекающими. Имеется возможность форкать и открывать дочерные процессы, на это нужны дополнительные затраты труда. Но это требуется только в исключительных случаях.
— Код пишется в основном легко, если следовать чёткому стандарту, который обычно навязывается используемым фреймворком. Однако javascript, ввиду своей нестрогости, неустойчив к коррозии, в спешке или по неопытности можно наделать рака и превратить жизнь своей команды в ад.
— При сложной логике со множеством вызовов можно без злого умысла нагородить «лестниц» из калбеков. Однако, проблема решается разными вариантами библиотек управления задачами (async, Q, и т.д.). Вообще лучше делать максимальную декомпозицию кода, создавать бесчисленные функции внутри функций — не очень хорошая практика.

По поводу камней:
— Обычно, всякие руководства и мануалы типа «hello world» используют один сокет для соединения с БД. На практике оказалось, что если этот сокет зависает под тяжёлым запросом, то все остальные запросы прилежно ждут его освобождения. Поэтому первое, что нужно сделать в новом проекте — это подключить database connection pool.
— Случилось так, что количество одновременных подключений к серверу перевалило за тысячу, и внезапно возникли необъяснимые аномалии и отказы. Как выяснилось, страшного ничего не произошло, и нужно было просто в операционной системе разрешить открывать на порядок больше файловых/сокетных дескрипторов.
— Память для nodejs лучше ограничивать ключами запуска и отдавать больше для БД (если они на одной машине). В противном случае nodejs не спешит запусктать сборщик мусора (это ведь затратная операция) и разрастается.
— Перезагрузки nodejs из-за внезапных падений от багов решаются специальными библиотеками, например forever.
— Чтобы nodejs не вылетал из-за исключений, нужно ставить глобальный обработчик uncaughtException, который пишет их в лог или сразу шлёт на мыло ответственному лицу.
— Нужно не забывать отвязыватсь обработчики от событий по окончании работы подписанного на событие объекта (removeListener()).

По поводу фреймворков, используем express, потому что он красивый, простой и мы к нему привыкли.