Сила сообщества и Sailsjs

Роль сообщества в удобстве использования того или иного инструмента для разработки может быть сильно недооценена. Особенно у нас в СНГ, после эпохи форумных советчиков, которые, прежде чем ответить на вопрос, успеют обвинить, переспросить, предложить десяток вариантов не о том и поспорить друг с другом. Могилы этих топиков всё ещё гуглятся, но отпугивают современного обитателя Toster & Stackoverflow, как и положено могилам.

Боязнь советов и стремление сделать всё одному (этому миру не нужен ещё один велосипед) может нас сподвигать на немыслимые поступки. Например, брать инструмент, о котором никто не слышал.
Точнее, слышали: основной репозиторий собирает на гитхабе 11к звезд. Но это ничего не значит, потому что все остальные репозитории с разработками нужных сервисов для этого инструмента никому неизвестны и last update: two years ago.

Займитесь детальным изучением инструмента, который вы выбираете, перед тем как его использовать!

Речь пойдёт о небезызвестном Nodejs и таком вот замечательном его фреймворке — Sails. О нём я узнал по рекомендации одного из авторитетных (для меня) нодеров, и как только выпал проект на Nodejs, я не стал воротить нос аки заядлый php-шник. Тут же указал Sails вместо привычного всем Express в графе «используемые технологии».

Не скажу, что задумка Sails плохая. Там много простых и понятных вещей, если нужно просто сделать простое API. Даже с авторизацией, даже с валидацией, с вменяемыми сообщениями и Twilio-верификацией телефонного номера. Мне нравилось как легко и просто всё это подключать и использовать, хотя осадок от нодовского «сделай ещё одно замыкание и выпей чаю» даёт о себе знать кошмарами по ночам.

Но спринты двигались, а задачи стояли на месте. «Сделай нормальные сообщения при валидации!», — орал QA. «Где мой swagger?!». «Что за Waterline?!». «Стой, что? Миграций нет?..».
Рабочие дни уходили, начинались выходные, а я пилил и пилил им Swagger вручную, гуглил и гуглил о внешних ключах в Waterline, и…

Первое: все найденные ответы либо были единственными во всём Stackoverflow с двумя-тремя плюсами (я на это ориентируюсь, да).

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

Третье: очень скудные best practice. «Тонкие контроллеры», говорит документация Sails. Но вы не узнаете, как это должно выглядеть. И знаете что? В условиях асинхронности, когда try-catch работает не так просто, как в привычном php, утоньшение контроллера становится искусством. Которым никто не хочет заниматься. И любой сервис, предлагающий что-то для sails, тут же предлагает examples с толстенными контроллерами. А мы и учимся. И страдаем. И используем пачки довольно нестабильного кода…

Ах да! Sails сам по себе 0.12.13 версии. Как бы бета. И недавно выпустили 1.0, но я его не рискнул использовать, потому что на него ещё меньше нужного сопровождающего кода от сообщества и ещё больше вопросов.

Сообщество это сила. Энтузиасты, которые пишут хороший код, тестируют его, развивают фреймворк, расширяют его (я говорю в частности об yii2), делают жизнь невероятно лёгкой и приятной. Это позволяет заняться проектированием и не пригорать по поводу отваливающегося bcrypt (в чём вообще была сложность сделать нормальный bcrypt?) и прочего такого, служебного и нужного только в двух местах во всем приложении.

Используйте популярные фреймворки. Держитесь мейнстрима, не бойтесь быть как все, потому что в программировании это скорее благо для вас. Это тысячи человекочасов, работавших бесплатно (вы же ничего не платили?) для вашего удобства.

Держитесь подальше от Waterline. Сомневайтесь перед тем как брать Sails в работу. У него мертвое сообщество.