Я хотел бы поделиться своим опытом о том, как структурировать приложения Meteor.js, которые должны иметь отдельные интерфейсы, но совместно использовать базу данных и серверную часть.
Давайте представим сценарий, в котором у нас есть набор инструментов, каждый из которых использует схожие основные функции для работы с довольно сложными объектами базы данных. Мы хотим иметь единый вход, единую библиотеку объектов базы данных для управления и результаты работы, доступные для единой административной системы бэк-офиса.
Например, персонал завода, поставщик логистических услуг и несколько разных подрядчиков, работающих над разными частями конечного продукта, будут использовать разные инструменты. За ходом поставки конечного продукта наблюдают менеджеры с помощью системы бэк-офиса.
Например, для приложения Mean stack архитектура может выглядеть так:
Различные приложения получают доступ к одной и той же базе данных либо через дополнительное серверное приложение REST (для инкапсуляции работы со сложными объектами базы данных), либо через отдельную библиотеку NPM, которую затем можно распространять через частный репозиторий и включать в каждое из приложений. Для внешних приложений каждое из них, в свою очередь, будет повторно использовать один и тот же угловой модуль, содержащий функциональные возможности для работы с одними и теми же сложными объектами базы данных на стороне пользовательского интерфейса.
Распространение библиотек и обеспечение того, чтобы приложения всегда включали самые последние и правильные версии, было бы первой задачей. Это можно решить с помощью таких инструментов, как Bower или NPM на стороне клиента. Или, может быть, даже прямое включение из одного источника. На стороне сервера самым безопасным подходом было бы создание отдельного приложения, хотя библиотека ни в коем случае не является ошибкой.
Планируя архитектуру аналогичного набора приложений для Meteor.js, я создал настройку, аналогичную описанной выше, но использующую более сильные стороны Meteor.js. Там нам действительно нужно подумать о том, как доставлять клиента и как доставлять серверные библиотеки отдельно (хотя NPM теперь может делать оба нужных типа и для стека Mean), их можно создать как пакеты Meteor.js Atmosphere.
Кроме того, каждый инструмент включает основной пакет, который инкапсулирует сложности доступа к базе данных, определяет основные коллекции и предоставляет шаблоны пользовательского интерфейса, которые можно включать в приложения.
Этот подход решает множество проблем, весь доступ базы данных к основным коллекциям может храниться в основном пакете со всеми проверками безопасности в одном месте. Все управление правами пользователей также может храниться централизованно в пакете, возможно, в другом. Также это упрощает разделение работы, выполненной разными разработчиками.
Конечно, доставить атмосферный пакет тоже не так уж и просто. До сих пор я выбирал подход, при котором каждый инструмент приложения и каждый пакет находятся в своем собственном репозитории git, последние версии пакетов хранятся в папке $PACKAGE_DIRS, а затем при развертывании mup они отправляются в производство. И это означает, что проверка зависимости версии между различными частями также является ручным процессом.
Это далеко не идеальное решение, но мне еще предстоит придумать лучшее решение, которое будет выполнять автоматическую непрерывную интеграцию и иметь возможность извлекать определенные версии приложений и пакетов, объединять их, а затем отправлять на производственный сервер. Посмотрим, как только я придумаю решение, я обновлю его здесь.
Я также хотел бы сделать все это без сохранения паролей базы данных в репозиториях git. Я хотел решить эту проблему используя сертификаты x509, но, к сожалению, это не полностью поддерживается Meteor. Есть также открытый вопрос о том, как настроить интеграцию oauth, если все приложения используют одну и ту же коллекцию пользователей.
Тем не менее, впереди интересное будущее с Meteor 1.3 и встроенной поддержкой NPM. Вероятно, скоро появятся еще лучшие способы организации такого созвездия приложений.
