Структурирование наших пакетов моделей метеоров
Я работаю с Метеором почти 2 года. За это время я пережил много больших изменений и адаптировал только mmmelon (система пакетов, маршрутизатор потока, реакция…).
Сейчас мы усердно работаем над добавлением новых функций, запрошенных пользователями, а также ожидаем роста нашей команды, поэтому я решил начать работу над прочной базой, которая есть во всех наших модельных пакетах. База, которая облегчает мне и будущим программистам работу над моделью mmmelon, а также делает mmmelon готовым к будущим изменениям в экосистеме Meteor.
За это время, работая с Meteor, я выявил много проблем, но некоторые из них следующие:
- Тестирование. Лучшее слово для описания тестирования в Meteor - «Ужасно». Я надеюсь, что с Meteor 1.3 это станет намного лучше, но сейчас тестирование утомляет.
- Зависимости: мир Javascript движется очень быстро, и Meteor находится на вершине этого мира. Новые вещи, которые меняются, появляются каждый день. Блейз изменился и теперь кажется мертвым. Meteor уже объявил, что добавит GraphQL с поддержкой реального времени. Это делает использование сторонних зависимостей большим риском. Вы можете использовать пакет сегодня, который завтра может сломаться или просто не быть готовым к той X новой вещи, которую вы должны сделать, и тогда вам придется все изменить.
- Пламя / хаос модели: действительно легко объединить ваши представления с логикой модели, проверкой ... Это становится большой проблемой, когда ваше приложение растет.
Помня об этом, я начал работать над простым способом структурировать наши пакеты моделей. Все они должны следовать этим принципам:
- Предсказуемо: должно быть легко увидеть, что произошло и что произойдет.
- Тестируемый. Модульное тестирование 100% кода несложно.
- Понятный: его должно быть легко кодировать и читать.
- Инкапсулированный: модель должна раскрывать только то, что нужно приложению. Операции с базой данных, методы… Все должно быть инкапсулировано внутри пакета и никогда не использоваться вне его.
- Meteorized: мы используем метеор не зря. Модель должна быть основана на компенсации задержки.
- Безопасность: операции с клиентской базой данных всегда плохие. Любая операция от клиента должна быть заблокирована, кроме вставок, где вам нужен _id сразу после вставки.
- Функциональная: (или своего рода) ваша модель должна представлять данные, которые вы сохраняете в базе данных, но не должна содержать методов. Функции никогда не изменяют данные. Это упрощает чтение и тестирование.
Эта работа опубликована на github, поэтому каждый может прочитать и помочь сделать ее лучше. Это просто идея незавершенного производства того, что, на мой взгляд, лучше всего соответствует нашим потребностям. Мы уже внедряем его с отличными результатами, но мне хотелось бы узнать мнение других метеоритов по этому поводу. Может быть, есть лучший способ написать код, следуя этим основным принципам.
Вы можете ознакомиться с полной спецификацией здесь.