Tutorial Meteor JS: Estructura y Seguridad

Recordemos que ya tenemos una aplicación funcionando, así que llegados a este punto vamos, conociendo los principales ficheros con los que se trabaja en Meteor, veamos hoy la estructura que habrá de tener nuestra aplicación para facilitar su escalado en caso de ser necesario.

Obviamente el funcionamiento dado con tres archivos (*.js, *.html y *.css) es completamente funcional, pero no del todo práctico, por lo que creemos la estructura necesaria para colocar cada cosa en su sitio.

Securizando

Antes de ir con la estructura que deberá tener la aplicación, intentemos incrementar un poco la seguridad, deshabilitando unos paquetes activos por defecto que no nos gustaría que entrasen en acción cuando se ponga la aplicación en producción. Veamos con qué paquetes hemos trabajado hasta ahora escribiendo dentro de la carpeta del proyecto la siguiente orden:

Meteor list

Algunos de los resultados ya los conocemos debido a que hemos sido nosotros los que los hemos puesto ahí (accounts-password, accounts-ui…), pero hay otros tantos paquetes que no conocemos y deberían preocuparnos.

Más concretamente hablo de insecure y autopublish , unos paquetes dentro de todo proyecto destinados a los desarrolladores que deberíamos deshabilitar en caso de que no seamos nosotros quienes trabajemos con la app. Éstos nos garantizan total acceso a la base de datos, que como desarrolladores deberíamos tener, pero no nos gustaría que cualquier usuario pudiese ver toda la información de otro. Por ejemplo, si escribiésemos:

Meteor.users.find().fetch()

Tendríamos la lista completa de los usuarios que tenemos registrados, emails, nombres y demás información. Esto es debido a autopublish , que nos da un volcado completo de la base de datos del campo que solicitemos y por supuesto, no debemos permitir que sea una opción activa en nuestro proyecto, por lo que deberemos deshabilitarla con:

Meteor remove autopublish

Y la siguiente vez que ejecutemos la línea anterior a esta deberíamos obtener una lista vacía ;).

Pero ojalá aquí acabase la cosa. Resulta que también podemos editar o eliminar mensajes mediante:

Twitts.remove({_id: ‘id del mensaje’})

Lo que dará acceso a cualquiera que deseé leer, modificar, eliminar o añadir información a la base de datos, por lo que quitaremos también el paquete insecure , causante de esto último

Meteor remove insecure

Con lo que si ahora volvemos a intentar eliminar algún mensaje recibiremos un error de denegación de acceso.

meteor remove insecure
remove failed: Access denied

Estructura

Como decía antes, hemos estado moviendo la app únicamente con tres archivos, algo muy simple y cómodo, pero que en un entorno real no es en absoluto eficaz. Meteor ofrece sin embargo, una estructura de ficheros y directorios que aportará un algo nivel de escalabilidad y flexibilidad al proyecto mediante una carga ordenada de todos los elementos.

Hemos visto como especificamos todas las dependencias JS fuera del HTML, al contrario que en otros frameworks, por lo que se deberán cargar todos los archivos de la app, vigilando entonces la estructura que otorgaremos.

Existen una serie de directorios que definen la estructura de la aplicación en Meteor:

• client: Equivale al bloque de código encabezado por Meteor.isClient .
   
• server: Equivale al bloque de código iniciado por Meteor.isServer .
   
• public: Albergará los componentes estáticos y comunes.
   
• private: Contendrá los componentes o datos únicamente disponible para el lado del servidor.
   
• tests: Aquí podremos incluir bloques de código que aún no queramos implementar en producción, el código “de pruebas” por decirlo de alguna forma.

Además, también tenemos el directorio /lib que será cargado antes que los arriba listados, pues contiene las colecciones de la base de datos requeridas por nuestra app para su correcto funcionamiento.

Sabiendo esto, vamos a dividir nuestro código en ficheros y alojarlos en una estructura más eficaz según el modo de trabajo de Meteor. Partiremos el fichero miTwitter.js en dos *.js que contendrá cada una de las plantillas, y de igual forma haremos con miTwitter.html , quedando un resultado como este:

La base de datos será accesible por ambas partes (cliente y servidor), por eso debemos ponerla en el directorio que se cargará antes. Os dejo unos enlaces a los ficheros tal y como quedarían:

https://drive.google.com/drive/folders/0B25enSYLZJFHUzJQdGt1QjktS1U?usp=drive_open

Y con esto ya podríamos seguir desarrollando nuestro proyecto dada una estructura más elegante y sobretodo eficaz. Recordad que hace poco ha dado inicio el curso de Meteor , donde se profundizará en este gran framework que como veis tiene innumerables posibilidades. Un saludo!