Еще очень не скоро. Я сейчас на этапе размышлений архитектуры. Однозначно это будет компонентная архитектура и нужно будет наследовать все компоненты от базового (это уже сделано). Также все это дело пишется на ES6\7, так что я иду в ногу со временем, так сказать. Пилить свои ORM и прочие монстры я не буду, т.к. есть вещи в которых это и так уже хорошо сделано. Я как закончу тестовые образцы базовых компонентов и устаканюсь с интерфейсом и документация для создания своих компонент, тогда все задокументирую и выложу в отдельную организацию на GitHub.
Они почему-то закрылись в Slack'е, в гиттер не выходят. Мне трудно было добиться к ним, но все-таки я попал в группу в Slack и теперь активно начинаю их пинговать за всякие фичи.
P.S. А вообще я свой фреймворк пишу :) У которого компонентная структура, сервером является Hapi, ORM Mongoose и Sequilze. Хочу сделать все что круто у Sails, но без бажных проблем (когда пытаешься все сделать сам).
Народ, я тут генератор запилил, которые многие траблы решает — github.com/ghaiklor/generator-sails-rest-api. Если вам нужен чистый рест апи, то думаю это быстрый и хороший старт.
Аналогично сейчас стоит вопрос о моем внедрении в команду к ним, поэтому буду делать все возможное — в первую очередь апгрейд експресса и лодаша.
delete это такое же изменение структуры объекта, как и добавление нового свойства в него.
Да, я с вами согласен. Поэтому если есть возможность задекларировать структуру объекта заранее, лучше это сделать и не изменять ее больше. Любое изменение структуры или типа данных в рантайме плохо сказываться на скорости работы. Хоть язык и с динамической типизацией, это еще не дает добро добавлять и удалять атрибуты с объектов или менять Number на String, когда переменная уже объявлена как Number и тому подобное.
Что касается «о-о-очень медленный» — то только в случае с перечислимыми свойствами в прототипе
На своем опыте удостоверился в том, что зачастую так и бывает. Разработчики итерируют полноценные объекты со своими цепочками и т.д. Поэтому ваше уточнение про плоские объекты имеет место быть.
Тут собраны советы по тому, как избежать распространённых ошибок и малозаметных багов, а также проблем с быстродействием и неправильного стиля программирования.
Я вижу только плохие примеры.
Зачем писать специальные примеры, в которых все плохо? Лучше же сделать примеры, где хорошо.
Объекты — хорошо. Пример показывает что все в JS есть объектами.
Удаление свойств — НЕ используйте delete, вообще никогда! Изменение структуры объекта, после его определения очень сильно бьет по производительности и V8 такие места не оптимизирует.
Зарезервированные слова — хорошо. Можно даже привычку выработать, всегда заключать в кавычки.
Прототипы
Bar.prototype = new Foo(); // Не делайте такого! Не плодите лишние объекты, когда у вас прототип уже и так объявлен!
Bar.prototype = Object.create(Foo.prototype); // Так правильно
Проход по объекту
Этот код о-о-очень медленный. Вообще забудьте что у JS есть оператор in.
for(var i in foo) {
if (foo.hasOwnProperty(i)) {
console.log(i);
}
}
Используйте его аналоги .keys(), .forEach() та хоть for(;;), только не for in.
Согласен. В hapi с этим хуже.
Я работаю с Sails уже чуть больше года и все устраивает. Не без минусов, конечно, но это все решается парой шаблонов проектирования. К тому же Waterline действительно «решает» в связке с Sails.
Sails построен на Express. Радуют его blueprints, которые с коробки генерируют все REST роуты, есть policies, где можно писать ACL. На Express это пришлось бы делать все самому.
Нет, я имел ввиду именно ODM (Object Document Mapper), в то время как ORM — это Object Relation Mapper. А так как Mongo — это документо-ориентированная, то логичнее считать Waterline ODM. Правда это спорный вопрос, так как Waterline поддерживает и ORM :)
Да, он там уже есть и пока только под версией 0.1.0, которая делает просто разворачивание проекта. В 0.2.0 включится автоматическая установка зависимостей, готовая фабрика для cipher'ов и интегрирован passport с возможностью делать локальную авторизацию по username\password паре и Facebook с Twitter токенами.
Исходники — клац
Название в репозитории yeoman — sails-rest-api.
ЗЫ. Отличительной чертой данного скаффолдера является уже настроенный Sails для работы с REST API. То есть, там уже выключены все ненужные хуки и функционал вроде Grunt, views и подобные. Получаете только чистый backend в виде API.
Отличный инструмент.
Недавно начал делать скаффолдер для REST API на основе Sails. Теперь разворачиваю настроенное API с оптимизациями и с готовой авторизацией через JWT + bcrypt за полминуты.
Вот думаю, продолжить это дело и дополнить скаффолдер еще фабриками для отправок писем, смс, работы с амазоном и т.д. Чтобы при разворачивании проекта оставалось только API ключи прописать.
Тот генератор, который идет в поставке с Sails, убогий и ничего толкового не умеет.
P.S. А вообще я свой фреймворк пишу :) У которого компонентная структура, сервером является Hapi, ORM Mongoose и Sequilze. Хочу сделать все что круто у Sails, но без бажных проблем (когда пытаешься все сделать сам).
Аналогично сейчас стоит вопрос о моем внедрении в команду к ним, поэтому буду делать все возможное — в первую очередь апгрейд експресса и лодаша.
github.com/ghaiklor/generator-es5-npm-module — под ES5
github.com/ghaiklor/generator-es6-npm-module — и под ES6
Благодаря этой статье, я наконец-то понял как прикрутить istanbul, mocha и coverall к Node. Однозначно в избранное :)
Да, я с вами согласен. Поэтому если есть возможность задекларировать структуру объекта заранее, лучше это сделать и не изменять ее больше. Любое изменение структуры или типа данных в рантайме плохо сказываться на скорости работы. Хоть язык и с динамической типизацией, это еще не дает добро добавлять и удалять атрибуты с объектов или менять Number на String, когда переменная уже объявлена как Number и тому подобное.
На своем опыте удостоверился в том, что зачастую так и бывает. Разработчики итерируют полноценные объекты со своими цепочками и т.д. Поэтому ваше уточнение про плоские объекты имеет место быть.
Я вижу только плохие примеры.
Зачем писать специальные примеры, в которых все плохо? Лучше же сделать примеры, где хорошо.
Объекты — хорошо. Пример показывает что все в JS есть объектами.
Удаление свойств — НЕ используйте delete, вообще никогда! Изменение структуры объекта, после его определения очень сильно бьет по производительности и V8 такие места не оптимизирует.
Зарезервированные слова — хорошо. Можно даже привычку выработать, всегда заключать в кавычки.
Прототипы
Проход по объекту
Этот код о-о-очень медленный. Вообще забудьте что у JS есть оператор in.
Используйте его аналоги .keys(), .forEach() та хоть for(;;), только не for in.
Я работаю с Sails уже чуть больше года и все устраивает. Не без минусов, конечно, но это все решается парой шаблонов проектирования. К тому же Waterline действительно «решает» в связке с Sails.
Нет, я имел ввиду именно ODM (Object Document Mapper), в то время как ORM — это Object Relation Mapper. А так как Mongo — это документо-ориентированная, то логичнее считать Waterline ODM. Правда это спорный вопрос, так как Waterline поддерживает и ORM :)
Также очень радует его ODM Waterline, которая работает просто прекрасно и уровень абстракции очень хороший.
Исходники — клац
Название в репозитории yeoman — sails-rest-api.
ЗЫ. Отличительной чертой данного скаффолдера является уже настроенный Sails для работы с REST API. То есть, там уже выключены все ненужные хуки и функционал вроде Grunt, views и подобные. Получаете только чистый backend в виде API.
Недавно начал делать скаффолдер для REST API на основе Sails. Теперь разворачиваю настроенное API с оптимизациями и с готовой авторизацией через JWT + bcrypt за полминуты.
Вот думаю, продолжить это дело и дополнить скаффолдер еще фабриками для отправок писем, смс, работы с амазоном и т.д. Чтобы при разворачивании проекта оставалось только API ключи прописать.