Небольшой рассказ о начальном погружении в Node.js и опыте работы с Rails-like фреймворком Sails.js
Эта статья не претендует на внимание искушенных разработчиков, поскольку является лишь описанием некоторых впечатлений начинающего Rails-разработчика о Node.js. Надеюсь, кому-нибудь будет полезно.
Первые шаги
Какое-то время назад я встал на путь web и начал постигать путь Rails. Наверное, все в курсе, но все же скажу, что это замечательная мощнейшая платформа, дающая возможность писать красивый и легкий код продуктивно и с удобством. Однако, когда и до нас дошла слава Node.js, интерес к диковинке (server-side JS!) стал постепенно накапливаться, и в конце концов вылился в желание опробовать зверя.
Отсюда начались поиски MVC фреймворка на Node, и тут же я встретился с первой особенностью этой платформы.
NPM переполнен пакетами со схожим функционалом
Было здорово обнаружить на Node не только хороший пакетный менеджер npm, но и даже аналог rvm для контроля версий (nvm, соответственно). Однако, пройдя по списку тех же MVC фреймворков на Node, я уяснил одну интересную черту Node-сообщества: люди охотнее пишут свою конкурентную библиотеку вместо того, чтобы сообща развивать существующую. Список решений в некоторых группах функционала превышает порог в 10 аналогичных решений, что добавляет простора для выбора, однако никак не прибавляет качества этим самым решениям, что печально. Даже task runner’ов на Node немало, что мешает довести до блеска какой-либо один?
Sails.js
Но вернемся к моим баранам. Просмотрев с пяток MVC на Node, я остановил свой выбор на замечательном подражателе Rails — Sails.js (и не прогадал). Каюсь, больше всего в его сторону потянуло количество звезд на гитхабе, но не только это. Sails похож на Rails, как по архитектуре, так и по идеологии. Это помогло довольно быстро влиться в процесс javascript-server-mvc. Jade вместо haml, тот же REST, приятные bluebrints; модели, контроллеры и вью на своих местах. А в качестве бонуса — socket.io, делающий асинхронную связь сказкой. Супер! Но приглядевшись к моделям…
Связи моделей? Не, не слышали
Я приверженец SQL. Плохо это или хорошо, но документоориентированные СУБД для меня пока чужды, поэтому я очень обрадовался наличию адаптеров MySQL и PostgreSQL. Вот только привычных связей я не нашел. Сейчас в бете уже есть версия v0.10, с которой ребята вносят, наконец, связи между моделями в БД. (Ура!) Однако, какое-то время назад, чтобы связать таблички “многие-ко-многим”, приходилось вручную создавать таблицу связи и добавлять нужные методы в модели. Эй, мы же Rails-like!
Jade vs Meleena HAML
Пользоваться ejs, как и пользоваться erb, — возможно, но не интересно. Куда удобнее взять шаблонизатор покруче, правда? Только вот дружить с HAML Sails с наскока не захотел, а попросил заменить его на родную и знакомую ему с детства Jade. Без проблем, подумал я. Вот вам index.jade, вот layout.jade… погодите-ка.
Привычные по Rails
render layout: “admin”
render “shared/navigation”
здесь не в цене. Но все оказалось довольно просто —
extends ../layout
block body
code code code...
вставляет в нужное место layout блок сходно с yield. И даже круче! Можно же вставлять и другие блоки!
extends ../layout
block styles
стили тут…
block scripts
а скрипты вот тут...
block body
code code code...
layout.jade
doctype html
html
head
title Заголовок
block styles
block sсripts
body
block body
Вот оно, теперь все скрипты и стили будут в нужном месте в layout’е, причем менять его совершенно не обязательно, not bad. Вместо partial можно использовать
include ../shared/_navigation
Не так уж и сложно.
Нехватка пакетов, WYSIWYG
Вскоре я встретился с новой проблемой. Для выполнения некоторых — вроде бы и очевидных — задач пакетов просто-напросто нет. Мне нужен был любой Rich Text Editor для наполнения сайта контентом, но в формате “взял — используй” я не нашел ни одного. Да, они все легко грузятся на вью, но проблема-то в том, чтобы заставить плагин корректно общаться с back-end для загрузки картинок и пр. Спустя какое-то время поисков я нашел-таки решение (кажется, где-то подсмотрел — уже не помню). Ничего сложного: CKEditor + несколько строчек кода и 1 функция (описал решение здесь, вдруг кому пригодится), но такие “затыки” всегда частично сбивают боевой пыл.
Не все так плохо
Однако, с пакетами все далеко не так плохо. Тот же Express.js (на котором построен Sails) с его многочисленными middlewares порадовал уже на следующей задаче — авторизации с помощью соц.сетей. Благодаря статье ghaiklor (спасибо автору) и Passport.js oauth настроился быстро и безболезненно. А для работы с shell пригодился модуль exec.
Лапша вкуснее с чашкой кофе
Еще одна небольшая заметка, по поводу “спагетти-кода”. Есть такое дело. Асинхронность — это круто, но бесконечные вложенные callback’и сперва сбивают с толку, а сложность выполнения некоторых тривиальных задач (как, например, отправка данных браузеру ПОСЛЕ их обработки во вложенных циклах) поначалу раздражает. И тут в дело вступает CoffeeScript. Он успешно повышает скорость написания (а главное, читаемость) кода до приемлемого уровня. я пытался пойти дальше и подключить IcedCoffeeScript, но с наскока не вышло — возможно, и к лучшему.
Конечно, это только самое начало, и мне предстоит еще очень многое изучить. Но первое знакомство с Sails.js (и Node вместе с ним) оставили положительное впечатление. Пока рано говорить о замене RoR в тяжелых проектах, но в качестве дополнительной технологии они оправдали себя на ура. Спасибо всем прочитавшим!
Автор: sca
