Руководство разработчика по улучшению структуры проекта в приложениях Meteor

За последние несколько лет произошло резкое увеличение количества доступных фреймворков JavaScript. Начиная от проверенного и надежного AngularJS и заканчивая набором фреймворков, которые выходят каждый месяц, существует впечатляющее разнообразие на выбор. Несколько лет назад мое внимание привлек фреймворк под названием Meteor. В отличие от большинства фреймворков, Meteor стремится стать полноценной платформой для разработки приложений на JavaScript. Для тех, кто плохо знаком с Meteor, я рекомендую вам проверить его на их веб-сайте. Эта статья не будет введением в Meteor. Вместо этого мы рассмотрим несколько простых способов введения структуры в проекты Meteor.

Одним из больших преимуществ Meteor является то, что с его помощью очень легко создавать прототипы сложных приложений JavaScript. Поскольку Meteor представляет собой гибрид внешнего шаблонирования и рендеринга в сочетании с сервером на базе Node, взаимодействующим с MongoDB (унифицированное решение), большая часть первоначальной настройки, необходимой для создания полнофункционального веб-приложения, уже выполнена за вас. Однако простота разработки, которую это обеспечивает, может оказаться ловушкой. При создании приложения Meteor легко нарваться на неверные методы и получить беспорядок неструктурированного кода. У меня есть несколько советов, как этого можно избежать.

Scaffolding: управляемая иерархия каталогов в Meteor

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

Чтобы решить эту проблему, я рекомендую проверить железный пакет npm Криса Мэзера. Пакет имеет множество вариантов конфигурации, поэтому их будет сложно описать здесь, но в целом он строит структуру проекта, которая будет выглядеть примерно так:

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

Однако для некоторых проектов подобная структура папок и файлов может оказаться излишней. Не каждый проект должен иметь такой детальный уровень организации с разделением коллекций, методов и кода публикации на сервере. Для тех, кто не имеет слишком большого проекта или просто не хочет устанавливать и изучать другой пакет npm, я рекомендую эту базовую структуру папок:

Ключевыми элементами являются общедоступная папка, содержащая такие файлы, как ваш значок и другие статические ресурсы, а также клиентская, общая и серверная папки. Папки клиента и сервера должны (конечно) содержать код, который выполняется на клиенте и сервере соответственно. Общая папка содержит код, который должен быть доступен как клиенту, так и серверу. Примером этого является код схемы, который мы немного обсудим.

Есть два способа выполнить самый низкий уровень организации: один — по типу файла, а второй — по функции. Организация по типам файлов означает, что, например, в папке client/templates у вас будет три папки — одна для файлов JavaScript, одна для CSS и одна для HTML. Папка HTML будет содержать все HTML-файлы вашего шаблона, например Login.html, Main.html и т. д. Папки JavaScript и CSS будут содержать файлы шаблонов соответствующего типа соответственно. Организация по функциям, с другой стороны, означает организацию по концепции, которую воплощают файлы. Например, в client/templates у меня будет папка «Вход» со всеми файлами JavaScript, CSS и HTML, связанными с процессом входа в приложение. Я предпочитаю организацию по функциям, так как это позволяет вам лучше понять, где вы можете найти определенные файлы или фрагменты кода. Тем не менее, это не чисто черное и белое, и большинство людей и групп используют некоторую смесь этих методов для структурирования своих файлов и папок.

Схема: это нужно вашему приложению, даже если ваша база данных этого не делает

Второй тип структуры, который я хотел бы обсудить, связан с базой данных. В этой статье предполагается, что вы используете MongoDB. Если нет, концепции, вероятно, по-прежнему будут применяться, но особенности не будут. Те, кто использует MongoDB, знают, что это позволяет нам хранить наши данные неструктурированными. Поскольку MongoDB — это база данных хранилища документов NoSQL, не существует фиксированной схемы для любого «типа» данных. Эта свобода означает, что вам не нужно беспокоиться о том, чтобы убедиться, что все объекты стандартизированы для какой-то жесткой формы, фактически все данные вашего приложения могут быть объединены в одну коллекцию, если вы хотите. Однако, когда дело доходит до создания приложений производственного качества, это не так желательно. Чтобы справиться с этим и добавить полезные функции, такие как проверка запросов на запись, мы можем обратиться к двум замечательным пакетам Meteor: SimpleSchema и Collection2 от Aldeed.

Пакет SimpleSchema, как следует из названия, позволяет реактивно проверять объекты в вашем приложении. Ознакомьтесь с документами на GitHub. Пакет Collection2 загружается с SimpleSchema и позволяет добавлять правильные схемы в коллекции Meteor. Это позволяет автоматически проверять клиентские и серверные запросы на запись в любую коллекцию с прикрепленной к ней схемой. Оба эти пакета очень глубокие и настраиваемые, поэтому сложно дать полное представление о них в нескольких абзацах. Вместо этого я рекомендую вам ознакомиться с подробными файлами readme, составленными Aldeed, чтобы узнать подробности. Я просто расскажу о том, как я извлек выгоду из этих пакетов. Одной из лучших вещей, которые они включили, была проверка ввода пользователем формы. Это удобно для проверки документов Meteor User (из пакета Accounts). По умолчанию пользователи Meteor имеют удивительно сложную неявную схему. Вот изображение части кода, который Aldeed любезно предоставил:

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

Это просто схема для объекта профиля пользователя. Попытка проверить весь объект User была бы беспорядочной без специального пакета, такого как SimpleSchema. Хотя на картинке все эти поля кажутся необязательными, если вам нужна должным образом проверенная схема пользователя, они, вероятно, не будут, и такие вещи, как «Schema.UserCountry», фактически перенаправляют на другие схемы для проверки. Прикрепляя эту схему к объекту User и интегрируя ее реактивно в наши формы, возможно, с помощью такого пакета, как AutoForm от Aldeed, мы можем получить хорошую степень контроля над тем, что попадает и не попадает в наши базы данных, экономя время и усилия с помощью концептуальная модель того, как данные обрабатываются в нашем приложении, на которую можно указать и обсудить на конкретных условиях.

Роли: для моделей 401 и 403.

Последнее предложение, которое у меня есть для структурирования и улучшения проекта Meteor, — это пакет ролей Аланнинга. Это система авторизации для Meteor, которая позволяет вам проверять уровни доступа пользователей к любой части вашего веб-приложения. Разрешения прикрепляются к профилю пользователя в виде строк, которые впоследствии проверяются или аннулируются, когда пользователь пытается получить доступ к любым методам или данным Meteor, опубликованным для клиента. Например:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

Хотя ядро ​​системы относительно простое, оно позволяет устанавливать сложные и детализированные разрешения для любой части вашего приложения. Поскольку все роли хранятся в виде строк, вы можете настроить систему сколь угодно глубоко — «admin», «admin.division1.manage», «admin.division1.manage.group2» и так далее.

Проблема со свободой, которую дает этот пакет, заключается в том, что может быть трудно отслеживать очень детализированную систему ролей. Пакет предоставляет такие функции, как «getAllRoles», которая, как следует из названия, извлекает все роли, которые вы создали, но вам решать, как отслеживать все их значения и когда данная роль должна быть использована. использоваться. А для тех, кому интересно, в чем разница между «ролями» и «разрешениями», для целей этого пакета они по сути ничем не отличаются.

Подведение итогов

К сожалению, из-за объема статьи (каждый из пакетов, упомянутых здесь, заслуживает отдельного руководства) не было возможности подробно остановиться на каком-либо конкретном пакете, но я надеюсь, что пролил некоторый свет на то, как вы можете работать над «стандартизированным пакетом». Вы можете быть уверены, что приложение Meteor будет хорошо работать в производственной среде и в больших масштабах. Если вам нужна дополнительная информация, просмотрите ссылки, которые я разместил, и взгляните на еще одну вещь, которая не вошла в эту статью, но полезно иметь в приложении Meteor: пакет Restivus, который позволяет вам чтобы легко предоставить REST API для вашего приложения.

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