Vamos a conectar ahora la aplicación con MongoDB. Vamos a tocar acá en "connect", vamos a elegir "connect your application", "short SRV" ya que estamos usando una versión compatible con 3.6 superior. Copiamos y reemplazamos en el "app.js" que tenemos acá la configuración de MongoDB. Permitime solamente... Vamos a comentar esto porque en breve voy a volver a esa instrucción. AquÃ, lo que vamos a hacer es reemplazar la conexión local con esta conexión que vamos a hacer. Acá tenemos que empezar con el "password", por eso es que me guardé ahà la clave. Guardamos y ya tenemos configurada la conexión contra MongoDB. Vamos a probarlo. Entonces, nuestro ambiente local conectado con esa base de MongoDB. Acá vemos que ha "crasheado" porque cambió una actualización en la versión. No pasa nada, esto es habitual, vamos a hacer un "npm install" para actualizar todo; y un "npm upgrade bcrypt", con esto actualizamos la versión de "bcrypt" que es lo que nos está indicando, en esta versión, de que la librerÃa "bcrypt" fue compilada con una versión de Node.js diferente, y demás. Entonces, al momento de hacer el "update" se actualiza y problema resuelto. Corremos. Nos pide que se va a conectar, le damos el "okey". Esa conexión es porque intentó conectarse a un servidor remoto. Vamos a la versión local. Ya hemos comenzado a trabajar, vamos a ir a "bicicletas". Nos pide el "Login", vamos a ingresar nuestra cuenta y crear una bicicleta para ver si empieza a funcionar. Antes que nada, lo que vamos a hacer es, para ingresar al sitio, crear un usuario. Obviamente, acabamos de crear la base y la base va a estar vacÃa, por lo tanto, no hay ningún usuario logueado para probar el "Login". Asà que, lo que vamos a hacer por ahora, como no tenemos ningún dato de inicialización de usuario, muchas veces lo que se hace es crear un archivo, le dicen "seed" o "semilla", que es para inicializar los datos básicos de una base. A veces, son datos productivos, se puede tocar directamente la base, aunque no es una práctica recomendada. TÃpico caso es el usuario "admin", que hay uno solo por sistema, para que pueda empezar a hacer todo, porque sino todo está atrás de un "Login" y no se puede ingresar. En este caso, nosotros no hemos puesto bajo un "Login" o una autenticación la creación de usuario desde la API. Esto, por seguridad, deberÃa estarlo. Dicho esta salvedad de cómo resolverlo, vamos a aprovechar la API. FÃjate que esto es el "usuarioControllerAPI" y aquà lo que podemos hacer es, por si no está actualizado tu proyecto, le agregamos al usuario el modelo de usuario acá, en el momento de la creación, el "email" y el "password" que es lo mÃnimo que precisamos ahora. En caso de error, le devolvemos un "500" y en caso de éxito un "200". Vamos a crear un usuario usando el "Postman". FÃjate que tenemos el sitio corriendo y acá vamos al "local host" que ya está configurado con la base de MongoDB, y eso es lo que queremos probar que esté todo bien. Hacemos "testing", "email", "password", mandamos enviar. Nos devuelven un "200" y los datos del usuario que acabamos de crear. Vamos a ingresar al sitio con este "email". Después, vamos a ir a "login", "password", ingresamos correctamente. Por otro lado, si vamos a la base de MongoDB Atlas, a la visión "web", al visor "web", vamos a refrescar la colección. También podemos usar el Compass. Vamos a "collections" y acá vemos que está el usuario que acabamos de crear, por lo tanto, ya la conexión la hicimos exitosamente. Ahora, ¿qué problema estamos teniendo? FÃjate lo siguiente. Primero, antes que nada, aquà estamos pegándole directamente a la base que va a ser nuestro sitio de producción. Eso por un lado, y eso no está bueno si éste sitio, si ésta base va a ser la de producción, ya que van a estar los datos de los usuarios de verdad, o sea, los que el sitio comercial va a operar. Por lo tanto, nunca se trabaja en desarrollo contra la base de producción; salvo ciertas excepciones donde se quiera testear algo con algún dato de producción, teniendo mucho cuidado de no modificar nada. Para eso, en parte, es que sirven estos datos, estos tipos de usuario con perfil solo lectura, también. Pero, de todas formas, no es una práctica habitual. Perfil de usuario de tipo lectura, me refiero a los roles de MongoDB que vimos antes. Entonces, ¿cómo resolvemos esto?, o sea, ¿qué es lo que quisiéramos tener? De alguna manera, lo que nos gustarÃa serÃa poder preguntar algo asÃ, lo pongo en comentario: "Si estoy en el ambiente de desarrollo, usar... ", "local host". "Si no, usar... ", esto que está acá abajo. La conexión que pusimos recién contra el MongoDB. Entonces, vamos a ver cómo podemos resolver esta situación en el próximo tutorial. A su vez, pensá lo siguiente, esta conexión que son los datos públicos, mejor dicho, los datos de conexión a la base de producción, estamos exponiendo usuario y "password" de administrador que se va a conectar. Eso, evidentemente, no está bueno. Pensá que, como parte del equipo de desarrollo, que todo el equipo conozca las credenciales de acceso a producción no parece ser una buena práctica. Entonces, para eso, la práctica que se suele utilizar es guardar esos ambientes en lo que es variables de configuración de ambiente o de entorno que, generalmente, están alojadas dentro del servidor que requiere conectarse. Para eso vamos a usar algunas herramientas.
