Guía del desarrollador para mejorar la estructura del proyecto en aplicaciones Meteor

En los últimos años, ha habido un aumento espectacular en la cantidad de marcos de JavaScript disponibles. Desde el AngularJS probado y verdadero hasta la veintena de marcos que salen cada mes, hay una diversidad impresionante para elegir. Uno que me llamó la atención hace unos años es un framework llamado Meteor. A diferencia de la mayoría de los marcos, Meteor pretende ser una plataforma completa para el desarrollo de aplicaciones JavaScript. Para aquellos que son nuevos en Meteor, los animo a que lo consulten en su sitio web. Este artículo no será una introducción a Meteor. En su lugar, exploraremos algunas formas sencillas de introducir la estructura en los proyectos Meteor.

Uno de los grandes beneficios de Meteor es que es muy fácil crear rápidamente prototipos de aplicaciones JavaScript complejas con él. Debido a que Meteor es un híbrido de plantillas y renderizado front-end junto con un servidor basado en Node que interactúa con MongoDB (una solución unificada), la mayor parte de la configuración inicial necesaria para la creación de una aplicación web de pila completa ya está hecha por usted. Sin embargo, la facilidad de desarrollo que esto proporciona puede ser una trampa. Es fácil caer en malas prácticas y terminar con un revoltijo de código no estructurado al crear una aplicación Meteor. Tengo algunas sugerencias sobre cómo se puede evitar esto.

Scaffolding: jerarquía de directorios manejable en Meteor

En primer lugar, es importante mantener la estructura de carpetas recomendada al desarrollar su aplicación. Meteor le permite colocar archivos en cualquier lugar dentro de la carpeta del proyecto de forma predeterminada; incluso puede tener todo su código en un solo archivo si lo desea. Si bien esto podría funcionar para un proyecto de hackathon, la complejidad en la que incurren las aplicaciones escalables de nivel de producción habitual es difícil de administrar sin una estructura sólida.

Para resolver este problema, recomiendo revisar el paquete de hierro npm de Chris Mather. El paquete tiene una variedad de opciones de configuración, por lo que será difícil describirlo aquí, pero en general construye una estructura de proyecto que se verá así:

 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

Sin embargo, para algunos proyectos, una estructura de carpetas y archivos como esta puede ser una exageración. No todos los proyectos necesitarán tener este nivel de organización detallado, con separaciones para colecciones, métodos y código de publicación en el servidor. Para aquellos que no tienen un proyecto demasiado grande o simplemente no quieren tener que instalar y aprender otro paquete npm, recomiendo esta estructura básica de carpetas:

Los elementos clave son una carpeta pública que contiene archivos como su favicon y otros activos estáticos, y las carpetas de cliente, común y servidor. Las carpetas del cliente y del servidor deben (por supuesto) contener código que se ejecuta en el cliente y el servidor respectivamente. La carpeta común contiene código que debe ser accesible tanto para el cliente como para el servidor. Un ejemplo de esto es el código de esquema, que discutiremos en un momento.

Hay dos formas de realizar el nivel más bajo de organización: una es por tipo de archivo y la segunda es por función. La organización por tipo de archivo significa que en su carpeta cliente/plantillas, por ejemplo, tendrá tres carpetas: una para archivos JavaScript, otra para CSS y otra para HTML. La carpeta HTML contendrá todos los archivos HTML de su plantilla, por ejemplo, Login.html, Main.html, etc. Las carpetas JavaScript y CSS contendrán archivos de plantilla de su tipo, respectivamente. La organización por función, por otro lado, significa organizar por el concepto que encarnan los archivos. Por ejemplo, en cliente/plantillas, tendría una carpeta "Iniciar sesión", con todos los archivos JavaScript, CSS y HTML asociados con el proceso de inicio de sesión de la aplicación. Prefiero la organización por función, ya que te permite tener más claro dónde puedes encontrar ciertos archivos o fragmentos de código. Sin embargo, no es puramente blanco y negro, y la mayoría de los individuos y equipos recurren a una combinación de estos métodos para estructurar sus archivos y carpetas.

Esquema: su aplicación lo necesita incluso si su base de datos no lo necesita

El segundo tipo de estructura que me gustaría discutir está asociado con la base de datos. Este artículo asume que está utilizando MongoDB. Si no es así, los conceptos probablemente se seguirán aplicando, pero no los detalles. Aquellos que usan MongoDB saben que permite que la forma en que almacenamos nuestros datos no esté estructurada. Dado que MongoDB es una base de datos de almacenamiento de documentos NoSQL, no existe un esquema fijo para ningún "tipo" de datos. Esta libertad significa que no tiene que preocuparse por asegurarse de que todos los objetos estén estandarizados en una forma rígida; de hecho, todos los datos de su aplicación podrían incluirse en una sola colección si lo desea. Sin embargo, cuando se trata de crear aplicaciones con calidad de producción, esto no es tan deseable. Para gestionar esto y agregar funciones útiles como la validación de solicitudes de escritura, podemos recurrir a dos maravillosos paquetes Meteor: SimpleSchema y Collection2 de Aldeed.

El paquete SimpleSchema, como sugiere su nombre, le permite validar objetos en su aplicación de forma reactiva. Consulte los documentos en GitHub. El paquete Collection2 se inicia a partir de SimpleSchema y le permite incorporar esquemas adecuados a las colecciones de Meteor. Lo que esto permite es la validación automática de las solicitudes de escritura del lado del cliente y del servidor a cualquier colección con un esquema adjunto. Ambos paquetes son muy profundos y personalizables, por lo que es difícil dar una comprensión completa de ellos en unos pocos párrafos. Más bien, le recomiendo que consulte los archivos Léame detallados que Aldeed ha compilado para conocer los detalles. Simplemente hablaré sobre cómo obtuve valor de estos paquetes. Una de las mejores cosas que habilitaron fue la validación de la entrada del formulario del usuario. Esto es útil para validar documentos de usuario de Meteor (del paquete Cuentas). De forma predeterminada, los usuarios de Meteor tienen un esquema implícito sorprendentemente complejo. Aquí hay una imagen de una parte del código que Aldeed tuvo la amabilidad de poner a disposición:

 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 } });

Ese es simplemente el esquema para el objeto de perfil del usuario. Intentar validar todo el objeto User sería un desastre sin un paquete especialmente diseñado como SimpleSchema. Si bien todos esos campos aparecen como opcionales en la imagen, si quisiera un esquema de usuario debidamente validado, probablemente no lo serían, y cosas como "Schema.UserCountry" en realidad redirigen a otros esquemas para su validación. Al adjuntar este esquema al objeto Usuario e integrarlo de forma reactiva a nuestros formularios, quizás con un paquete como AutoForm de Aldeed, podemos obtener un buen grado de control sobre lo que ingresa y lo que no ingresa en nuestras bases de datos, ahorrando tiempo y esfuerzo con un modelo conceptual de cómo se manejan los datos en nuestra aplicación que se puede señalar y discutir en términos concretos.

Roles: Para los 401 y 403

La sugerencia final que tengo para estructurar y mejorar un proyecto Meteor es el paquete Roles de Alanning. Este es un sistema de autorización para Meteor y le permite verificar los niveles de acceso de los usuarios para cualquier parte de su aplicación web. Los permisos se adjuntan al perfil de usuario en forma de cadenas que luego se validan o invalidan cuando el usuario intenta acceder a cualquier método Meteor o datos publicados en el cliente. Por ejemplo:

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

Aunque el núcleo del sistema es relativamente simple, permite permisos complejos y detallados para cualquier parte de su aplicación. Dado que todos los roles se almacenan como cadenas, puede configurar un sistema tan profundo como desee: "admin", "admin.division1.manage", "admin.division1.manage.group2", etc.

El problema con la libertad que permite este paquete es que puede ser difícil hacer un seguimiento de un sistema de roles altamente granular. El paquete proporciona funciones como "getAllRoles" que, como sugiere el nombre, recupera todos los roles que ha creado, pero depende de usted hacer un seguimiento de todos sus significados y cuándo debe hacerlo un rol determinado. ser usado. Y para aquellos que tienen curiosidad sobre cuál es la diferencia entre "roles" y "permisos", para los propósitos de este paquete, esencialmente no son diferentes.

Terminando

Desafortunadamente, debido a la amplitud del artículo (cada uno de los paquetes mencionados aquí merece su propio tutorial), no fue posible entrar en detalles sobre ningún paquete en particular, pero espero arrojar algo de luz sobre cómo puede trabajar para lograr un "programa estandarizado". “La aplicación Meteor en la que puede estar seguro funcionará bien en producción y a escala. Si está buscando más información, consulte los enlaces que publiqué y eche un vistazo a una cosa más que no llegó a este artículo, pero que es útil tener en una aplicación Meteor: el paquete Restivus, que le permite para exponer fácilmente una API REST para su aplicación.

Como descargo de responsabilidad, no soy el autor de ninguno de estos paquetes y me disculpo si he tergiversado alguna de las características o los objetivos de cualquier paquete. Gracias por leer, y espero que este artículo haya sido de beneficio para usted. No dude en ponerse en contacto conmigo con cualquier pregunta que pueda tener, o dejar un comentario a continuación.