Структурирование наших пакетов моделей метеоров

Я работаю с Метеором почти 2 года. За это время я пережил много больших изменений и адаптировал только mmmelon (система пакетов, маршрутизатор потока, реакция…).

Сейчас мы усердно работаем над добавлением новых функций, запрошенных пользователями, а также ожидаем роста нашей команды, поэтому я решил начать работу над прочной базой, которая есть во всех наших модельных пакетах. База, которая облегчает мне и будущим программистам работу над моделью mmmelon, а также делает mmmelon готовым к будущим изменениям в экосистеме Meteor.

За это время, работая с Meteor, я выявил много проблем, но некоторые из них следующие:

  • Тестирование. Лучшее слово для описания тестирования в Meteor - «Ужасно». Я надеюсь, что с Meteor 1.3 это станет намного лучше, но сейчас тестирование утомляет.
  • Зависимости: мир Javascript движется очень быстро, и Meteor находится на вершине этого мира. Новые вещи, которые меняются, появляются каждый день. Блейз изменился и теперь кажется мертвым. Meteor уже объявил, что добавит GraphQL с поддержкой реального времени. Это делает использование сторонних зависимостей большим риском. Вы можете использовать пакет сегодня, который завтра может сломаться или просто не быть готовым к той X новой вещи, которую вы должны сделать, и тогда вам придется все изменить.
  • Пламя / хаос модели: действительно легко объединить ваши представления с логикой модели, проверкой ... Это становится большой проблемой, когда ваше приложение растет.

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

  • Предсказуемо: должно быть легко увидеть, что произошло и что произойдет.
  • Тестируемый. Модульное тестирование 100% кода несложно.
  • Понятный: его должно быть легко кодировать и читать.
  • Инкапсулированный: модель должна раскрывать только то, что нужно приложению. Операции с базой данных, методы… Все должно быть инкапсулировано внутри пакета и никогда не использоваться вне его.
  • Meteorized: мы используем метеор не зря. Модель должна быть основана на компенсации задержки.
  • Безопасность: операции с клиентской базой данных всегда плохие. Любая операция от клиента должна быть заблокирована, кроме вставок, где вам нужен _id сразу после вставки.
  • Функциональная: (или своего рода) ваша модель должна представлять данные, которые вы сохраняете в базе данных, но не должна содержать методов. Функции никогда не изменяют данные. Это упрощает чтение и тестирование.

Эта работа опубликована на github, поэтому каждый может прочитать и помочь сделать ее лучше. Это просто идея незавершенного производства того, что, на мой взгляд, лучше всего соответствует нашим потребностям. Мы уже внедряем его с отличными результатами, но мне хотелось бы узнать мнение других метеоритов по этому поводу. Может быть, есть лучший способ написать код, следуя этим основным принципам.

Вы можете ознакомиться с полной спецификацией здесь.