Подсоветуйте фреймворк для node?

Есть идея написать браузерку для мобилок, так как владею JS и имел опыт работы с node, то соответственно на ноде и думаю делать. Но если честно совсем никак не могу определиться с фреймворком — слишком уж их много… Подскажите, пожалуйста. Сильно много мне не нужно, MVC да рендринг страниц на сервере. Понравился этот новенький impress, но не стремлюсь использовать самопальный продукт, могущий в любой момент свернуться и даже не имеющий документации…

P. S.: Вообще хотелось бы выслушать все предложения по поводу написания мобильных текстовых игр ;)
  • Вопрос задан
  • 8662 просмотра
Пригласить эксперта
Ответы на вопрос 7
MarcusAurelius
@MarcusAurelius Куратор тега Node.js
автор Impress Application Server для Node.js
Как основной автор Impress, не буду я его советовать, но вот несколько слов скажу, чтобы не было лишних ожиданий от фреймворка. И дам советы, которые на любом фреймворке помогут Вам написать хороший проект.

Ответы:

agentx001:
Сильно много мне не нужно, MVC да рендринг страниц на сервере.

Что такое MVC нет общего мнения, так случается, что каждый поймет это по-разному, потом напишет что-попало, и назовет это MVC. Так вот, Impress это не MVC, если понимать MVC, как отдельное написание контроллеров, моделей и представлений. Не будем обсуждать, что такое MVC, это очень затертый термин, и мы запутаемся в домыслах, которые вокруг него нагромождены. Лучше я скажу, что ждать от фреймворка: Impress, сам по себе, это универсальный контроллер, он как раз написан для того, чтобы не писать контроллеров. В нем есть реализация представления — это рендереры, один из рендереров — это шаблонизатор (с его помощью можно рендерить не только HTML, но и CSV, CSS, TXT и что угодно), но есть еще рендерер для JSON, он совсем простой, можно дописывать другие рендереры, для других форматов данных, если шаблонизация не подходит, например, для бинарных данных. Еще в Impress есть реализация логики приложений — которая разделяется на три части: (а) логику модели данных предметной области, (б) логику представления, т.е. логику рендеринга, (в) логику библиотек общего назначения, не связанных с предметной областью. Логика предметной области — это бизнес-логика приложения, например: алгоритм вычисления маршрута доставки груза, для системы крекинга грузов. Логика рендеринга — это если нужно сформировать данные для рендеринга при помощи императивного кода (т.е. при помощи обычного алгоритмического программирования с условиями, циклами и вызывами), а не только при помощи декларативных шаблонов и декларативных условий в них. Логика библиотек общего назначения — это все универсальные задачи, которые могут быть переиспользованы в других проектах, например, генерация DOCX документа, валидация данных, чтение количества кадров из анимированного GIFа и т.д. Все эти три вида логики (кода), гораздо важнее отделать друг от друга, чем модель от представления. А вот отделать представление от логики представления — это вообще страшная ересь, в которую впадают многие MVC-фреймворки.

agentx001:
Понравился этот новенький impress, но не стремлюсь использовать самопальный продукт, могущий в любой момент свернуться и даже не имеющий документации…

Кроме самописных Вы еще какие знаете? Может есть какие-то автоматически писанные или сгенерированные? Есть статьи, есть примеры, часть API уже документирована, например, вот тут: impress/wiki. Скоро будут скринкасты, я уже об этом говорил. И в Impress очень мало кода, ядро весит 43кб. Код написан аккуратно, его можно прочитать за 5 дней, если читать по 5 страниц на ночь. Примеры готового веб-приложения (админ-панель для БД MySQL и MongoDB) даются вместе с системой и описываются тут: http://habrahabr.ru/post/192302/

rozhik:
По поводу критики impress — я бы таки выбрал другой. Очень странная архитектура, если он выживет — то явно поменяет не только половину апи — но и принципы расположения файлов.

Фреймворк не на пустом месте появился, файловые структуры, как и API, созданы как портированные на ноду, наработки моей команды за последние 15 лет на Delphi, C#, PHP и JavaScript. Структура каталогов и API будут наращиваться, но не переделываться кардинально, я уже нашел для себя золотую середину в архитектуре систем. Вот что будет меняться в ближайшие месяцы — это формат конфига, т.е. Impress же не просто фреймворк, это сервер приложений, и он может сразу обслуживать несколько приложений (на разных доменах). Для этого, конфиг будет разделен на основные настройки и отдельную конфигурацию, для каждого приложения. Но конфиг не вилик, его разнести на несколько файлов — не проблема, при чем, структура конфига не сильно изменится.

Советы:

1. Если у Вас сайт, то рендерите шаблоны на сервере, но если у Вас приложение, то сделайте одну страницу (ну или несколько основных страниц), и на сервере сделайте API на AJAX и JSON. Присылайте данные в клиентское приложение, будь то веб-приложение или мобильное приложение для iOS или Android или оконное приложение, на любом языке. Это гораздо универсальные и удобнее для интеграции и поддержки.

2. Используйте оперативную память, не лазьте в базу данных постоянно. Нода — это великолепная возможность писать быстрые приложения, и даже не из-за того, что она не блокирующая, за последний год я понял, что правильное использование памяти гораздо более ускоряет, Вам даже не нужно делать операции ввода-вывода в реальном времени, все они могут быть отложенные (ленивые, лэйзи). Вместо этого, разворачивайте данные в память приложения, стройте хеши, объекты, массивы. Не нужно бояться, что нода запущена в несколько процессов, и запросы одного пользователя могут приходить в разные процессы и находить там разные структуры данных. Это можно решить, делая «прилипание» клиентов по IP адресу или по Cookie при помощи балансировщика, к отдельному процессу ноды. В Impress такой балансировщик есть встроенный, можно использовать nginx или сервисы Вашего дата-центра, для больших проектов можно и нужно привлекать аппаратные балансировщики. Между разными процессами так же можно взаимодействовать через ZeroMQ, TCP, HTTP, IPC и еще что-угодно. Таким образом, данные разных процессов, в зависимости от того, что это за данные, могут или дублироваться в памяти (кешироваться, если это общие данные) или быть разделены на «прилепленные» сессии или синхронизироваться между собой через межпроцессовое взаимодействие.

3. Не очаровывайтесь технологиями, берите их как можно меньше, и лучше копайте вглубь, чем по верхам. Для ноды сейчас очень большое разнообразие всего написано, и есть какая-то общая тенденция, поподключать в проект сто модулей, которые делают совершенно плевые вещи, а те тянут за собой еще какие-то зависимости и потом оно расползается и становится совершенно неконтролируемым. Подумайте 100 раз перез тем, как написать require, а если есть несколько альтернатив, то потратьте немного времени чтобы пощупать их код, протестировать производительности и удобство, это сэкономит потом много времени.
Ответ написан
@evgabd
Возможно, этот подойдет: expressjs.com
Ответ написан
@rozhik
Я не буду советовать какой-то конкретный фреймворк (простите), но хотел отметить, что если он вам понравился, и в текущем состоянии удовлетворяет — то берите его. Развивайте с авторами, (тем более он очень простой). В конце концов форк никто не отменял. Все продукты были самопальными.

По поводу критики impress — я бы таки выбрал другой. Очень странная архитектура, если он выживет — то явно поменяет не только половину апи — но и принципы расположения файлов.

P. S.: Вообще хотелось бы выслушать все предложения по поводу написания мобильных текстовых игр ;)
предлагаю их не писать (если вы хотите заработать денег).
Ответ написан
Weageoo
@Weageoo
Поговаривают, что несмотря на существование всяких Sails.js, Geddy.js, Tower.js и проч. народ в большинстве своём использует Express.js (а сам экспресс.жс лежит в основе многих фреймворков). Я сам только начинающий нода-райтер, но ситуацию просканировал буквально недавно, и мой план такой:

— изучаю голую ноду;
— изучаю express.js;
— после приму решение — стоит ли брать к.-л. фреймворк с большей абстракцией.

Потом — со всякими Sails.js, Geddy.js, Tower.js могут быть проблемы в плане кроссплатформенности, неудобства (если использовать Windows для разработки), потом в облачных IDE типа c9.io тоже проблемы. Так что предлагаю следовать моему нехитрому плану — если никто не предложит план получше.
Ответ написан
pomeo
@pomeo
Берите express и не мучайтесь. Я иногда поглядываю на derbyjs.com, но вот брать его и использовать где-нибудь я бы не стал.
Ответ написан
@agentx001 Автор вопроса
Дабы не плодить — на какие модули для экспресса стоит обратить внимание? Шаблонизатор, ORM, там…
Ответ написан
Комментировать
qfox
@qfox
Ответы есть у меня
Можно еще попробовать https://github.com/2gis/slot

У них там специфичный БЭМ, изоморфность, и все такое.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы