El caso es que queremos evitar tener errores en nuestro código, obviamente.
Para eso se utilizan herramientas que se llaman linters o lint, como quieras llamarle,
que al final es una herramienta que detecta y te señala los errores que tiene cualquier lenguaje de programación.
En este caso, pues JavaScript, en especial cuando estás trabajando con Node.js.
No solo errores, sino que también el linter te puede decir cosas de code styling, ¿vale?
De qué estilo de código estás utilizando.
Por ejemplo, estás utilizando dos espacios y el proyecto debería ser con cuatro espacios.
Estás utilizando punto y coma y yo no utilizo punto y coma.
Lo que te ayuda es a tener un code styling, ¿vale?
Así que el linter es la primera herramienta que deberías instalar en todos los proyectos.
El linter más extendido es slint, ¿vale?
Así que vamos a instalar ese.
Para ello, pues aquí tenemos la terminal.
Voy a hacer npm install slint-d porque es de desarrollo, ¿vale?
Es una dependencia de desarrollo.
Ahora que me lo he instalado en el Packardison, pues puedo ver que tengo, por un lado,
las dependencias de desarrollo, que es slint y nodemon.
Mira, me ha puesto el caret otra vez, pues se lo voy a quitar por si acaso.
Y dependencias que es express por ahora.
Vale, pues aquí hay diferentes formas de hacerlo.
Ahora, como estamos empezando, lo mejor es que entiendas que puedes ejecutar un binario
que se llama slint y pasarle la posibilidad de inicializarte la configuración.
Con esto, pues directamente empiezas desde cero y te va haciendo unas preguntas
de cómo tiene que hacer cada cosa y tal.
Por ejemplo, vamos a darle.
Ya te pregunta.
¿Qué quieres que haga slint?
Pues me chequea la sintaxis, me encuentra problemas y me obliga a tener un estilo de código.
Yo esta es la que te recomiendo, ¿vale?
Ahora, ¿qué tipo de módulos estás utilizando en tu proyecto?
Pues ya hemos dicho que estamos utilizando CommonJS.
No estamos utilizando los JavaScript módulos, así que CommonJS.
¿Qué framework estamos utilizando en nuestro proyecto?
Ninguno de estos, en este proyecto.
Tenemos TypeScript, no por ahora, pero más adelante sí que lo veremos.
¿Dónde estamos ejecutando esto?
¿En Node?
Ay, me ha seleccionado browser.
Bueno, luego lo arreglo.
¿Cuál es el estilo que te gustaría en tu código?
Bueno, podría ser uno popular, inspeccionar.
Le vamos a decir que me pregunte y ahora me va preguntando.
¿Cómo te gustan los archivos de configuración?
JavaScript.
¿Qué utilizas?
¿Tabs o espacios?
Espacios.
¿Utilizas comillas dobles?
Single.
Estoy en Unix.
No quiero semicolons.
A mí no me gustan semicolons.
A cada uno que le guste o no le guste.
Ahí lo puedes hacer.
Vale.
Todo esto, al final lo que ha hecho es crearme este SlintRC, ¿vale?
Que tiene toda la configuración del linter.
De esta forma hemos iniciado con algo y no nos tenemos que preocupar.
Si ahora voy al index.js, pues tengo un montón de errores en mi código.
¿Por qué?
Porque no estoy siguiendo las reglas que le he dicho en el linter.
O sea, me he saltado cosas aquí.
Por ejemplo, aquí me dice que la indentación está mal porque tiene cuatro.
Esto ya os digo que eso lo voy a cambiar porque no me gusta la indentación de cuatro espacios.
Me gusta la de dos.
Pero bueno, si yo ahora, ¿por qué me ha estado dando todos estos errores al editor?
Porque tengo una extensión que es la del linter, ¿vale?
Que tienes que instalar sí o sí, que es esta, Slint.
Y esta, al final, lo que te hace es leerte la configuración que tienes en tu proyecto y dice, vale, pues con esta configuración que tienes en tu proyecto, estos son los errores que tienes en tu código.
Si además quieres que te enseñe en la misma línea el error, ¿vale?
Porque por defecto no te lo enseña así, te puedes instalar esta, Error Lens, ¿vale?
Para que te enseñe en la misma línea el error.
Esto lo hace una extensión diferente, ¿vale?
Que la del linter.
Esto me lo han preguntado mil millones de veces, la de Error Lens.
Si me lo han dado un euro cada vez que me han preguntado esto.
Sería rico.
Vale, ahora que tenemos esto, se puede configurar Slint, tiene un montón de configuraciones.
Lo mejor que podéis hacer es darle a esta ruedecita y vais aquí a Extension Settings.
Aquí tenéis, bueno, que os podéis aburrir.
Una de ellas es, por ejemplo, las acciones que puede hacer cuando se guarda, cada cuánto tiene que ver los errores.
Puedes, por ejemplo, configurar si cuando guardas el archivo te los arregla.
Por ejemplo, si yo ahora guardo el archivo, me va a arreglar todos los errores.
¡Pum!
Me los ha arreglado.
Yo, porque tengo que cuando se guarda el archivo, justamente que me haga el modo fix de Slinter y ya está.
Pero, mira, hay alguno, este no lo ha podido arreglar.
No lo arregla todo, hay algunos que sí, otros que no.
Esto sería en el editor, pero es importante también saber que tenemos el binario, no un modules que hemos utilizado antes
y lo podemos ejecutar para que nos detecte los errores.
En este caso, no me lo ha detectado porque me he saltado.
No he puesto dónde tiene que buscar, ¿vale?
Tenemos que ponerle punto para que sea en el proyecto este.
¿Ves? El error que tengo aquí en la línea 60 también me ha encontrado aquí.
Así que lo mejor es que en el package.json, igual que teníamos lo de antes, pues tengamos aquí lint y hagamos un node.
Ay, no, un model no.
Es lint, punto.
Y así lo mismo, ¿no?
Npm run, lint.
Y ya está.
Así, pues ya tenemos una forma de lintar nuestro código.
Además del editor.
¿Por qué?
Porque el editor a lo mejor hay gente que no lo utiliza o no tiene configurado el linter,
así que es importante una forma de tener este comando, ¿vale?
En nuestro proyecto.
Ahora, para arreglar esto sería borrar y darle al espacio otra vez.
Esto es un error muy típico que te dice que tienes los espacios irregulares porque a lo mejor ese no ha sido un espacio, no sé, lo ha detectado de otra forma.
A mí me gusta, por ejemplo, esto.
La indentación me gusta con 2 en lugar de con 4, ¿vale?
Porque me da más espacio y se lee lo suficientemente bien.
Por ejemplo, un error de no decirle, ves que me ha puesto browser true.
¿Qué pasa?
Que ahora este puerto, si yo utilizase aquí el process.env.port, por ejemplo, que esto ahora os explicaré para qué sirve.
¿Ves este process que me dice que no está definido?
Esto no es verdad, porque en node esto es una variable que está definida.
Pues para solucionar esto tendría que decirle, oye, no, es que esto lo vamos a utilizar en el entorno, en lo que lo estamos ejecutando.
Esto es node, ¿vale?
Y es true.
Si guardo esto, ves, ya me deja de dar problemas.
Esto lo utilizaremos ahora en un momentito.
Esto sería una forma que funciona, ¿vale?
Hay diferentes formas.
Puedes decir, hay gente que le encanta el Airbnb Slint, que ya tiene una guía de estilo.
Y de hecho, cuando te está preguntando la configuración, puedes utilizar la Airbnb.
Hay un montón de formas, de configuraciones y tal.
Yo os voy a decir la que yo utilizo y la que a mí me gusta más y la que utilizo en todos mis proyectos.
No os voy a explicar todas las razones de por qué, que son un montón,
pero os la voy a enseñar y la vamos a dejar en el proyecto porque a mí es la que más me gusta.
Y bueno, pues además no tiene configuración y todo lo que no te da configuración para mí es un win.
Esto es la configuración, ¿vale?
Entonces, la que yo utilizo es una que se llama Standard,
que básicamente ya te viene con un montón de reglas preestablecidas
y que está basada en no utilizar semicolons, puntos y comas, en JavaScript.
Y ya te arregla todos los problemas que puedas tener al respecto,
te viene con un montón de reglas y no tienes que pensar en ellas y tal.
Para utilizar Standard, lo mejor que puedes hacer, ¿vale?
Una sería, ya hemos visto, utilizando el linter a mano, esa sería una.
Para utilizar Standard, lo mismo que hemos hecho antes.
npm install standard menos d, ¿vale?
Así que le voy a dar, vamos al Package JSON y ya voy a eliminar la de slint porque esta no la necesitamos.
¿Por qué? Porque Standard en realidad utiliza slint por detrás.
Ahora voy a eliminar el caret, importante.
Esta configuración la voy a quitar, ya no la necesito.
Y lo que voy a hacer en el Package JSON es añadir un slint config,
que es otra forma de indicar la configuración del linter.
Y lo que vamos a decir es que vamos a extender de la configuración que tenemos en
node modules standard slint rc.json.
Slint rc.json, a ver qué nos valía.
Vale, guardamos los cambios.
Y ahora se supone que esta configuración está utilizando la de Standard, ¿vale?
Ya no tengo la configuración del linter que tenía antes, ahora tengo esta de Standard.
Ves que ahora me está detectando otros cambios.
Por ejemplo, me está diciendo, mira, esto lo estás haciendo con comillas cuando no es necesario.
También te puede encontrar espacios que no está utilizando.
Ves, aquí tengo espacios que no los estoy utilizando.
Es un poquito más amplio que lo que teníamos antes.
Vale, pues ahora voy a guardar los cambios y ya vemos que me lo ha dejado súper bien.
A mí es el que más me gusta por un montón de motivos, pero cada uno que utilice la que quiera.
Lo mejor de esto es que cada uno puede utilizar lo que prefiera y seguir siendo feliz, ¿vale?
Yo creo que lo mejor es que ya no es tan importante, ¿no?
Es como que, ¿cuál es la utilidad en realidad de preocuparte de este tipo de cosas?
Y es que no tiene mucho sentido.
Cuando lo guarda se cambia solo.
¿Qué más da?
Vale, a ver.
Nos queda el deploy en Heroku, que lo vamos a ver ahora en un momentito, ¿vale?
Pero antes, déjame que te explique dos cositas.
Una, lo que es un middleware.
Un middleware, que en realidad ya estamos utilizando middleware.
Esto es un middleware, ¿vale?
Un middleware básicamente es una función que intercepta la petición que está pasando por tu API.
Por ejemplo, vamos a poner aquí un app.use y aquí, ¿qué se le pasa en el use?
Pues fíjate, lo mismo, un callback, que tiene la request, la response y otra cosita que se llama next, que esto ahora te lo explico.
Entonces aquí lo que puedo poner, por ejemplo, un console.log que sea request.method, ¿vale?
Y así vamos a ver qué es lo que le está llegando.
Request.path, console.log, request.body, si es que tiene, por ejemplo.
Vale.
Y esto, ahora, vamos a poner esto así.
Claro, ¿cuándo se ejecuta esto?
Pues esto, tal y como está puesto aquí, tenemos que leer nuestra aplicación de arriba a abajo.
Lo primero que va a ejecutar es este middleware.
Por lo tanto, la request va a pasar por aquí.
Luego, la request pasará por este de aquí, ¿vale?
La petición pasará por aquí.
Y luego seguirá bajando y dirá, vale, la request que estoy haciendo encaja con esto.
Si encaja, voy a entrar aquí y voy a devolver esto.
Si no encaja, voy a probar con esto.
Y si encaja aquí, pues devuelvo esto, ¿vale?
O sea, va de arriba a abajo y va visitando y va mirando.
Si yo ahora miro y pongo aquí otro app.use, vamos a ponerlo, ¿vale?
Voy a poner aquí un app.use y vamos a ver si entra.
Voy a poner, he entrado aquí, solo para ver si entra, ¿vale?
Si ese console.log lo vemos en la terminal.
Vamos a quedarnos también con este, ¿vale?
He puesto esto, app.use.
Este use lo que quiere decir es que cualquier petición, ya sea un get, ya sea un post, ya sea un delete, sea lo que sea, va a pasar por aquí.
Y como no le hemos puesto un path, lo que va a hacer es que pasen todas, ¿vale?
Si yo le pongo aquí el path, pues lo que va a hacer es que sí que pase por aquí.
Vamos a ver diferentes cosas aquí y algún problemilla, entre comillas, que vamos a encontrar, ¿vale?
Vamos a volver aquí al localhost 3001, api notes.
Venga, vamos a api barra notes.
Fíjate que se ha quedado esto pensando, ¿vale?
Se ha quedado pensando y no me está devolviendo nada.
Pero si voy a la consola, sí que ha entrado al middleware, pero se ha quedado ahí.
¿Por qué? ¿Qué ha pasado? No ha hecho nada.
Se ha quedado aquí, pues porque está esperando a saber qué es lo que tiene que hacer.
Si lo que queremos es que básicamente siga para la siguiente, para el siguiente endpoint, ¿vale?
El siguiente check que os he comentado que tenía que hacer, lo que le tenemos que decir es, vale, next.
Ve a la siguiente ruta para ver si tienes que ejecutarte, ¿vale?
Ve al next.
Si no, pasa lo que pasa, que no está respondiendo el servidor.
Se ha quedado aquí y ahí se ha quedado.
Ha dicho, ah, bueno, pues yo he trabajado.
Aquí ha terminado mi trabajo.
Aquí se queda.
No.
Queremos que siga, ¿vale?
Esto es súper típico.
Lo que estamos haciendo es que, vale, pasa por aquí, pero tú continúa a ver si este path realmente encaja con algo.
Vale.
Pues vamos a guardar esto.
Vamos a volver a probar.
Bueno, ¿y ves?
Ahora sí que me devuelve esto.
Sí que ha entrado a la request y si voy a la consola puedo ver que ha estado entrando a ese middleware que hemos visto antes.
Pero no ha entrado, no ha entrado a este de aquí.
Que también hemos dicho que si va de arriba abajo y va mirando en cada una, ¿por qué no ha entrado aquí?
Porque no estamos haciendo un next.
Lo que estamos haciendo aquí, en este de aquí, es responder con un JSON.
O sea, que sí que está respondiendo y por eso no se queda pensando porque sí que está respondiendo.
Pero no estamos diciendo, vale, haz algo más.
No le hemos dicho que haga nada más, ¿verdad?
Para hacer el next lo tendríamos aquí.
Y podríamos decir, vale, vea la siguiente.
En este caso no es muy útil.
Pero ¿para qué es útil?
¿Para qué puede ser útil este app.use?
Este app.use es súper útil para el 404.
¿Por qué?
Mira, ahora si intento ir a una ruta que no existe, esta por ejemplo.
Bueno, se me puede quedar pensando, pero eso puede ser por otro problema.
Vamos a ver, voy a guardar.
Vale.
Hay un error.
Hay un error que no estoy controlando.
O sea, hay un error y tal.
No quiero esto.
Yo lo que quiero es controlar y decir, no, yo quiero que esto, yo sé que es un 404.
No existe esa ruta.
Pues lo que podemos hacer es poner un app.use.
Es decir, que aquí tendríamos el request y la response.
El status es un 404.
Y bueno, aquí podríamos poner el error, que es un not found, por ejemplo.
¿Vale?
Y ahora, si intentamos aquí, ves, ahora sí que estamos controlando esta ruta.
Como está mirando de arriba a abajo, está mirando de arriba a abajo, ha entrado aquí,
ha hecho lo que tengo que hacer, ha entrado aquí, veremos aquí que sí que tenemos el
get, ¿veis?
Ha hecho todo el login que teníamos en este callback, en este middleware, ¿vale?
Ha ido a la siguiente ruta, ha ido entrando aquí, no tengo que entrar, no tengo que entrar,
no tengo que entrar, pam, pam, pam, hasta que ha llegado a esta.
Y esta, como es la última, ya sería nuestro 404.
Esto es otra buena práctica que puedes hacer rápidamente para solucionar cualquier problema
de rutas.
Además, esto te puede servir de login, ¿no?
Saber qué rutas están llegando aquí.
Puedes decir, ostras, voy a mirar, esto es un, qué path está yendo al 404, ¿no?
Y esto te lo puedes enviar a una base de datos, a lo que sea.
Pues esto sería el 404.
Ahora, interesante, los middlewares, por supuesto, esto es una función.
O sea, que podríamos tener, además voy a crear un módulo para que veamos también
cómo funcionan los módulos.
Podríamos tener una función aparte que sería, pues, logger, le voy a llamar logger,
ponemos aquí y este logger, pues lo tendríamos aquí, lo pasaríamos así.
Otra cosa que podemos hacer, pues eso, tenerlo aquí, logger, logger, middleware.js.
Y esto, lo que haríamos es tenerlo aquí.
Ahora, para exportarlo, teníamos que hacer un módulo.export, ¿vale?
Es diferente a lo que habíamos visto antes.
Que esto, justamente, antes era export default logger o tal.
Pues no, aquí es módulo.export, pues es common.js.
Y ahora, para importar esto, pues nos vamos aquí, logger, require, the logger, middleware.
Y este logger ya lo podríamos utilizar aquí.
Y esto debería funcionar bien si no la he liado parda, ¿vale?
Pues ahí lo tenemos funcionando.
Si vamos aquí, ahí está nuestro logger funcionando.
Esto tiene un montón de utilidades, por ejemplo, para archivos, para publicar, por ejemplo, archivos estáticos.
También hay middleware que te hacen eso.
Hay un montón, hay un montón de cositas.
Vale.
Vamos con el tema de Heroku, entonces.
Porque ya tenemos, justamente, todo esto.
O antes, no, antes de deployar, antes de deployar, una cosa.
Porque todo esto lo hemos hecho para algo, ¿vale?
Os he dejado aquí en mi repositorio.
Ahora os paso el repo.
A ver si encuentro el repositorio.
Porque he preparado la aplicación de React, ya preparada.
Mira, NotesApp está.
Os la voy a dejar en el chat, ¿vale?
Que es súper importante.
Vale.
Entonces, ese repo lo podemos clonar.
De hecho, lo voy a clonar en un momento, ¿vale?
Git, clone.
Vamos a clonar este repo.
¿Qué es lo que tenemos aquí?
Lo que tenemos aquí es nuestra aplicación de notas que hicimos en las clases anteriores de React, ¿vale?
Así que vamos a NotesApp.
Voy a instalar las dependencias.
Esto puede tardar un ratito.
Me da tiempo a beber.
Vale.
Lo que vamos a hacer, claro, es utilizar nuestra API.
Es que ahí es donde está la gracia también, ¿no?
Que utilicemos nuestra API.
Claro, si la hemos creado para algo.
Bueno, cuando hago las instalaciones creo que se pone...
Igual se me escucha mal, ¿eh?
Ahora termina.
Pero vamos a utilizar nuestra API ya que la hemos creado.
Bueno, ¿dónde está la gracia, no?
A ver, MPN run start.
MPN run start.
Eso nos lo deja en el puerto 3000.
Vale.
Ahora debe estar petando porque no he levantado la API.
La API que tenía...
Esto está tirando una API suya interna.
Vale.
Tenemos aquí las notas.
No tenemos notas porque esto está tirando la API interna.
Vamos a hacer que tire de la nuestra.
Ahora, voy a poner aquí code punto y lo voy a hacer en el source.
Si os recordáis, es un servicio que es una de las notas.
Esto tiene el cost 3001 barra notes, pero esto no es correcto.
Es barra API barra notes.
Voy a guardar los cambios y vamos a ver si esto funciona.
No funciona de buena.
Vamos a ver qué más tenemos por aquí.
Esto sí que lo tenemos.
API barra notes.
Vamos a ver si hay algo que se me está escapando.
Vamos a ver que esto funciona porque si no...
Aquí es donde está la magia.
¿Dónde está la gracia de todo el asunto?
A ver.
Este es el...
Vale, es que tengo un montón de cosas abiertas por aquí.
Voy a cerrar editores.
Voy a cerrar editores.
Este es el nuestro, ¿no?
Este es el nuestro.
Vale.
Esto lo puedo eliminar, que ya no nos está sirviendo para nada.
Tenemos API notes.
Esto nos responde con las notas.
Voy a limpiar esto.
Vamos a ir aquí.
A ver la consola.
Vamos a abrir la consola.
Está...
Vale.
¡Aquí está!
Esto es lo que quería enseñaros.
Esto es lo que quería enseñaros.
¿Por qué está vacío?
Si lo he hecho bien.
Si está bien.
Si...
Mira, ¿ves?
Esto me está diciendo.
Que está haciendo una petición a localhost 3001 API notes.
¿Vale?
Esto...
Esto es.
Esto es.
Mira.
Si yo voy aquí, me devuelve la información.
¿Por qué no veo aquí la información si estoy devolviendo las notas que esperaba que estuviesen aquí?
¿Por qué?
Vale.
Y además, aquí podemos ver la petición.
Pero peta.
Esto está petando.
Está rojo.
Rojísimo.
No nos gusta el rojo.
Ya te...
Aquí lo tienes.
Mira.
Te dice status.
Dice cross origin resource sharing error.
Missing allowed origin header.
Este es uno de los grandes problemas del mundo, seguramente.
Y de la programación.
Si también me pagasen otro euro cada vez que me han preguntado por esto.
De hecho, en los últimos días había un montón de gente.
Vale.
¿Qué es esto del course?
Que se llama course.
Que es el control origin resource sharing.
No.
El control...
Ahora, ¿cómo era esto?
Cross origin resource sharing.
¿Vale?
Básicamente es compartir recursos entre diferentes orígenes.
Vale.
¿Qué pasa?
Que nosotros tenemos la API en el puerto 3001.
Y nuestra aplicación en el puerto 3000.
Por lo tanto, son orígenes distintos.
¿Ok?
Normalmente, en orígenes distintos, no hay problema en funcionar
cuando estamos hablando de algunos recursos.
Como, por ejemplo, imágenes.
¿Cuántas veces has hecho un image source de una imagen que está en otro dominio
y no has tenido un problema de course?
10.000 millones de veces.
¿Cuántas veces?
Yo qué sé.
Pues lo mismo con JavaScript.
¿No?
¿Cuántas veces has utilizado una CDN con un JavaScript en tu dominio?
Y es otro dominio.
Un millón de veces.
¿Vale?
Entonces, normalmente, por defecto, ocurre con ciertos tipos de recursos.
Como, por ejemplo, fuentes.
Con fuentes suele pasar y hay que poner ciertas cosas.
Y, en este caso, con este tipo de recursos JSON que haces un fetch.
Con los fetch, con las requests, suele ocurrir.
Pero esto tiene solución.
Sobre todo, en nuestro caso, que dominamos el backend.
¿Vale?
Porque si no tuviésemos acceso al backend, tendríamos que hacer diferentes cosas.
Entre ellas, podríamos hacer un proxy.
Pero eso ya lo veremos.
Pero, en este caso, se puede solucionar muy fácilmente porque, como tenemos acceso al backend, lo vamos a arreglar en el backend.
Que es la magia.
¿Qué pasa aquí?
Que nosotros tenemos la potestad de decirle qué orígenes pueden acceder a nuestros recursos.
Claro, cuando tú haces una API, por ejemplo, una API de producción, pues imagínate que eres Google y tienes una API.
Pues tú dices, ostras, bueno, esto es la guía de un videojuego.
No, esto es lo que quería ver.
Aquí, esta es Google, ¿no?
Y tú tienes una API.
Y dices, bueno, pues la API.Google, yo lo que quiero es justamente que solo se pueda utilizar en Google.com.
El origen Google.com.
Pero, normalmente, cuando tú haces una API que, sobre todo, está abierta a todo el mundo, tú lo que quieres es que lo utilice cualquiera.
Para esto, existe un middleware, también en Express, que se llama Cores.
Vamos a poner el menos E para que nos guarde la versión exacta.
E, importante, es una dependencia de producción, ¿vale?
No de desarrollo, de producción.
Ahora, este Cores lo podemos requerir, ¿vale?
Lo voy a poner aquí arriba.
Y este middleware, lo único que tenemos que decirle es que lo use.
Así que hacemos Cores y hacemos esto.
Esto lo que va a hacer por defecto, porque esto tendría un montón de configuración y tal que podríamos ver, por ejemplo, como configurar qué orígenes son los que nos interesan.
Con esto lo que vamos a hacer es que cualquier origen funcione en nuestra app, ¿vale?
Así que voy a guardar los cambios.
Esto me ha debido refrescar el servidor.
Vamos a nuestra aplicación de React, lo refrescamos y ahora aquí lo tenemos.
Ya está funcionando nuestra API totalmente para cualquier origen.
En este caso, pues este origen que es un localhost, pero ahora si fuese otro origen de fuera, pues también funcionaría.
En nuestro caso, es importante tener el cost preparado.
Una de dos, podemos o identificar todos los orígenes que nos interesan, que suele ser un coñazo, o podemos decir que es un asterisco.
En este caso, que cualquier origen funcionaría correctamente, ¿vale?
Que es lo que hemos hecho.
Con esto tenemos el tema de Cores.
Espero que esto os haya ayudado, porque, bueno, es interesante.
Y ya sabéis, claro, para darle mayor seguridad, pues podrías decir, a ver, Cores Express.
Vamos a ver un momento el middleware este.
Pero, ta, ta, ta, a ver, config, configuring Cores, ¿ves?
¿A qué le puedes pasar? Pues el origen que sea tal.
Y que entonces sí que vaya bien, ¿ves?
Orígenes dinámicos.
Los puedes cargar, por ejemplo, puedes pedir a una base de datos que te diga los orígenes que sí que deberían funcionar.
O sea que es bastante potente.
Pero en este caso, lo mejor que puedes hacer es directamente poner un asterisco y ya está.
¿Por qué digo lo del asterisco?
Porque creo que hay mejores formas de controlar esto.
Como, por ejemplo, tokens, autentificación, que son cosas que veremos.
No creo que evitar el origen, porque además el origen se puede hackear muy fácilmente.
Puedes hacerte pasar por un origen.
No creo que sea una de las grandes...
Puede ser interesante, todo ayuda, pero no creo que sea lo que te va a salvar de cualquier cosa, ¿vale?
Además, mira, lo puedes hacer por path en concreto.
Esto también puede ser interesante, ¿no?
Por ejemplo, para cosas más sensibles, como recuperar un producto en concreto, pues esto sí que lo tienes que hacer.
Lo puedes pasar por cost.
O sea, nosotros lo hemos utilizado como middleware, pero también lo puedes utilizar para cada path, porque los middleware también se pueden utilizar a nivel de cada path.
¿Vale?
Así que aquí lo tendríamos.
Y aquí podríamos crear midu, midu, dudu, dudu, save.
Y aquí lo tendríamos.
Y si refrescamos, vale, midu, dudu, dudu.
Esto es una cosa que está en la aplicación, que voy a quitar.
Esta.
Que era una prueba.
Y parece raro, porque parece como que...
Pero, vale, midu, dudu, yo puedo ir guardando, y esto está haciendo llamadas, y ya está.
Vale.
Ahora, vamos a deployar esto, si os parece, a producción.
Esto lo vamos a hacer...
Bueno, espero que si todo va bien lo hagamos rápido.
Lo primero que vamos a hacer para deployar...
Bueno, os voy a comentar dónde lo vamos a deployar.
Lo vamos a deployar en Heroku, que es una plataforma donde puedes hospedar...
Es una plataforma con hospedaje en la nube, donde puedes deployar servicios, no solo de Node, sino de un montón de tipos.
Y que es totalmente gratis.
O sea que, si me damos el pricing, es totalmente gratis para cosas pequeñitas, ¿vale?
¿Ves?
Free and Hobby, si empieza a crecer, pues ya van a querer cobrar y os enviarán un aviso y tal.
Pero para este tipo de pruebas lo vais a poder utilizar sin ningún tipo de problema.
Entonces, lo primero que vamos a hacer...
Lo primero que vamos a hacer es...
No sé si os he pasado...
Os he pasado...
Os lo voy a pasar.
Si no, me podéis seguir también en...
Me podéis seguir en GitHub y ahí estaréis súper informados.
¿Quién deploya en 10 minutos?
Vamos a probar, Dana Vallardi.
A ver cuánto tardamos.
Vamos a hacer más cosas en 10 minutos.
Primero vamos a crear un repositorio, ¿vale?
Que es nodes API backend, por ejemplo, ¿vale?
Y aquí le vamos a poner public y vamos a crear el repositorio.
Si no tienes una cuenta de GitHub, deberías hacértela ya.
Creamos el repositorio, ¿vale?
Aquí nos dice que podemos crear el repositorio desde la línea de comandos.
Vale, yo todavía no he creado, si no recuerdo mal, esto...
Este es el backend, ¿vale?
El de node.
Aquí no tenemos...
Esto no es un repositorio todavía, ¿vale?
No es un repositorio.
Pues vamos a hacerlo.
Vamos a hacer un git init.
Vamos a...
¿Ves?
Ya he inicializado el repositorio.
Vamos a hacer un commit con my first API.
¿Vale?
Voy a añadir...
Voy a añadir todo.
En este caso, es que yo tengo aliases, ¿vale?
Esto es que no me acuerdo ya ni siquiera...
Git...
No sé cómo era.
Git all.
Creo que era así, ¿no?
¿Puede ser?
Que tengo...
O sea, estoy tan acostumbrado a los aliases ya que...
Git add all.
A ver, ¿cómo era esto?
Estoy tan acostumbrado a los aliases.
Ah, git add punto.
Vale.
Vale, un problema.
¿Ves?
Me lo ha añadido todo, pero esto está mal.
Me ha añadido demasiado.
Me ha añadido demasiado.
Me ha añadido demasiado porque...
¿Qué pasa?
Que nosotros vamos a crear aquí un git ignore para ignorar el NodeModules, ¿ok?
No queremos que la carpeta NodeModules la subamos al repositorio.
Así que creamos un archivo git ignore y decimos que ignore NodeModules.
Ahora sí.
Git add punto.
¿Vale?
Ahora sí, hacemos un git status.
Perdón que utilizo los aliases, pero es que me sale de dentro.
Bueno, pues, tendríamos qué es lo que vamos a añadir en nuestro repositorio.
Podemos seguir un poco lo que nos dice aquí.
Podemos el git commit menos m.
Yo utilizo gcmsg.
Git commit menos m.
My first backend with Node.
¿Vale?
Ahora esto, tendríamos un commit ya preparado.
Ahora lo que nos falta es empujar este commit que tiene un mensaje con unos archivos.
Vamos a pushearlo a nuestro repositorio.
¿Vale?
Bueno, aquí, claro, lo primero que nos dice es que cambiemos la rama.
¿Vale?
Esto sería para, en lugar de utilizar master, utilizar main.
Bueno, podríamos utilizar master y quedarnos igual.
Pero vamos a utilizar main.
Cambiamos a esta rama de main porque todavía hemos pusheado, o sea que no existe ni master ni main en el repositorio que tenemos aquí.
Aquí todavía no existe nada.
Da igual el nombre de la rama.
Y le vamos a añadir el origen remoto.
¿Vale?
Que es donde vamos a guardar esta información antes de empujarla.
Tenemos que decirle dónde la tiene que llevar.
Así que le vamos a decir que el origen remoto donde vamos a guardar la información de este commit es en esta dirección.
¿Vale?
Esta dirección es la que hemos creado aquí.
Así que le vamos a dar.
Y ahora, pues, básicamente lo pusheamos.
Vamos a pushear y le decimos que lo haga en la rama main.
En el origen que ya hemos añadido, en la rama main.
Ahora esto debería pushear.
Pam.
Tenemos aquí, si yo refresco, debería ver todos mis ficheros ahora.
¿Vale?
Y aquí tengo todos mis ficheros con las requests.
¿Ves?
Es interesante que ha quedado ahí bastante...
Hasta aquí bien, ¿no?
Ahora, para Heroku.
Bastante sencillo.
Lo primero que tenemos que hacer, vamos otra vez al editor.
Lo primero que hay que hacer, a ver si me acuerdo cómo era el nombre, es proc file.
¿Vale?
Mira, de hecho, ¿ves que ha cambiado el icono?
Un archivo proc file.
Que le tenemos que decir qué tipo de recursos es el que queremos deployar.
En este caso es un servicio web.
Y le tenemos que decir cuál es el comando que tiene que ejecutar
para inicializar este servicio.
En este caso, npm start.
¿Vale?
Ya lo hemos visto aquí, ¿no?
Npm start, pues esto hace node.index.js.
Hasta aquí bien.
¿Qué es lo que tenemos que decir ahora?
Pues vamos a crear nuestra aplicación en Heroku.
Para eso tendrías que instalarte el cli de Heroku.
Si haces Heroku cli, te saldría esta página.
Dependiendo de tu sistema operativo, pues puedes utilizar macOS, Windows.
Por supuesto, tendrías que crear una cuenta.
Ya os digo, es totalmente gratis.
Os creáis la cuenta.
Si lo queréis deployar a otro sitio, pues otro sitio.
Aquí vamos a ver Heroku porque es sencillo, gratis y lo hacemos en un momento.
Para macOS sería así.
Yo esto ya lo he ejecutado.
Con Windows lo tendríais aquí, Ubuntu lo tendríais aquí.
Tendréis diferentes formas, ¿vale?
Yo ya esto lo he hecho, pero bueno, si queréis lo vuelvo a hacer para ver qué hace.
Pero bueno, ahora mismo no haría nada.
Igual, básicamente lo que hace aquí es, para los que tengáis macOS,
está activando este repositorio para poder instalar paquetes de ahí
y por este punto está instalando el paquete de Heroku.
Este paquete de Heroku solo está en este repositorio.
Por eso tiene las dos cosas.
Así que primero hace una cosa, luego hace otra.
Me da miedo.
Voy a quitarlo porque es que si no igual se tira esto un rato
porque hace tiempo a lo mejor que no lo hago y se vuelve loco.
Ahora, si no me equivoco, ahora que tenemos esto,
tenemos que hacer un cambio bastante importante en nuestro código
antes de que se me olvide.
Y es que, ¿ves que aquí al final, os acordáis de lo del puerto?
Que yo puse aquí 3001 o 3002.
O sea, aquí podemos poner el puerto que queramos.
Vale, en Heroku el puerto no se le puede decir.
Tú no me puedes decir, no, hazlo en el 3001.
No, esto Heroku lo hace automáticamente.
Para esto, el puerto lo utiliza de una variable de entorno que se llama port.
¿Vale?
¿Ves cómo hemos visto lo del port que os he dicho?
Esto es process, es el proceso.
Enf, variable de entorno.
Y el nombre de la variable de entorno es port.
Si no existe esta variable, utilizaríamos 3001, que es el caso de localhost donde lo tenemos.
Pero esto lo necesita Heroku para él poner y usar el puerto que quiera.
¿Vale?
Así que es importante que lo tengáis en cuenta esto.
Ahora que tengo esto, ya hemos creado el repositorio,
hemos añadido todo el código, tengo el puerto.
Me falta crear la aplicación de Heroku.
Heroku create.
¿Vale?
Mira, Heroku create.
Y ahora con esto, lo que debería hacer, esto hace tiempo nuevo,
es crearme una aplicación de Heroku.
Vamos a darle, a ver qué pasa.
¿Vale?
¿Me he creado una app?
Vale, ya me he creado la app.
Si yo intento entrar a esta URL, vas a ver que esto no funciona.
Bueno, funciona, pero no es mi aplicación.
Esto no es lo que yo quiero, no es lo que espero yo.
Ver, si yo le doy aquí a API Notes,
¿Ves?
Esto, o sea, es una aplicación modelo, no tiene nada.
Pero ya es la URL que vamos a utilizar.
Lo interesante es lo que ha hecho aquí.
¿Ves aquí que pone Git, Heroku, no sé qué, no sé cuánto?
Mira, si yo hago Git remote, tengo el origen, el origin, que es el mío, ¿no?
Que he añadido antes, remote, show, origin.
Creo que es show.
Pues al revés.
Sí, no, lo he hecho al revés.
A ver, no, show.
Yo creo que es show, origin.
Sí, vale, lo he hecho bien.
Vale, sí.
Sí, sí, sí.
Es que como estas cosas uno no hace en su día a día.
Vale, lo que me está diciendo es, vale,
la dirección para hacer el fetch del código del repositorio y el push es esta,
que esta es la de GitHub.
Pero lo que ha hecho Heroku es añadirme una suya propia.
¿Por qué?
Porque lo que va a hacer es que cuando tú hagas un push en esto,
en este origen, lo que va a hacer es el deploy.
Así que vamos a hacer una cosa.
Lo primero que vamos a hacer es git all add todo.
Vamos a hacer el git commit menos m y vamos add heroku needed config.
Vale, vamos a hacer git push con alias, perdón.
Al final es git push origin main.
Creo que era así.
Vale.
Ahora que tengo todo pusheado, que si yo voy a mi GitHub, pues tendría aquí,
ves, he debido a hacer hace 16 segundos, he puesto el proc file, el index.
Ahora que tengo esto, ahora es cuando podemos hacer un git push heroku main.
Lo que le estoy diciendo es, pusheame la rama main al origen heroku.
Y de esta forma, si le doy, esto, pushea los cambios que tenemos en la rama main.
Esto debería estar haciendo el deploy, donde vamos a estar haciendo, ves,
ha detectado que es una aplicación de Node.
Usted está utilizando Heroku, cuáles son las variables en torno que está utilizando,
está instalando los binarios.
Ah, esto es súper interesante.
Porque aquí podemos ver que está instalando Node 14, MPM versión 6.
Esto se puede configurar en el package.json.
Mira, está instalando las dependencias, me ha instalado Node Moon,
está haciendo la build, ¿vale?
La está comprimiendo.
Esto es porque...
Mira, ya me dice, release versión 3.
Y me dice que lo ha deployado aquí.
Pues vamos a ver si esto funciona o no.
Vale, voy a la raíz, tengo mi Hello World.
¿Por qué?
Porque aquí en mi código podíamos ver que cuando íbamos a la raíz, salía Hello World.
Ahora, si voy a barra API, barra Nodes,
aquí tengo todas las notas, si recuperamos la primera, pues aquí lo tendríamos.
Y esto funcionaría correctamente.
De hecho, para demostraros que esto funciona correctamente,
pues podríamos ir a nuestra aplicación de las notas.
Vamos a nuestra aplicación de las notas.
Vamos aquí.
Guardamos aquí los cambios.
Y si vamos a la aplicación de las notas, que estaba aquí.
No.
Aquí.
Vamos a la aplicación de las notas.
Pues aquí las tenemos.
Si yo ahora aquí guardo una nota, que por ejemplo sea...
Hola, Midu.
Gracias, Twitch, por estar aquí.
Y vamos a poner otra.
No te olvides suscribirte a HTTPSMidu.tv.
Gracias.
Ahora que tenemos estas notas, si yo voy aquí a mi API que tengo en el servidor de Roku
y miro las notas, puedo ver...
¿Ves?
Que tengo las que he creado desde ahí.
Así que ya tendríamos nuestro backend deployado totalmente.
Ahora, esto es solo el principio.
¿Qué más podríamos deployar?
Hombre, la aplicación del frontend, ¿no?
Así que la aplicación del frontend también la deberíamos deployar.
O sea, deberíamos hacer todavía más cosas.
Pero con esto ya tenemos nuestra API deployada en una URL pública para todo el mundo.
Además, porque hemos puesto el course.
Cualquiera la puede utilizar ahora mismo.
Y totalmente gratis.
¿Y cuánto hemos tardado?
¿Hemos tardado 10 minutos?
¿Qué decía Dana?
¿Hemos tardado 10 minutos?
¿Qué decía Dana, Dana?
No sé si hemos tardado 10 minutos.
Pero mira que lo he hecho poco a poco, ¿eh?
Lo he hecho poco a poco.
Sobre el front no os preocupéis.
Porque en la próxima clase también vamos a deployar, por supuesto, el front.
O sea, esto no lo vamos a dejar así.
O sea, por supuesto.
No lo vamos a dejar a medias.
Lo interesante es que lo vamos a hacer de forma incremental.
Ya hemos deployado el backend.
En la próxima clase veremos cómo deployar el frontend.
Y además veremos persistencia de datos con MongoDB.
Para generar el procfile lo he hecho a mano, ¿vale?
El procfile, no sé si hay un comando.
Ahí me has pillado.
No sé si hay un comando para generar el procfile.
Pero yo lo he hecho a mano, ¿vale?
Lo que he hecho es hacer archivo nuevo, procfile, importante.
Hay que decirle que es un servicio web, dos puntos,
el comando que tengo que utilizar para levantarlo.
¿Por qué hay que decirle que es un servicio web?
Porque necesita tener un puerto asignado, ¿vale?
Y el puerto se lo asigna, se lo pone aquí y automáticamente hace un proxy
que lo que hace es que en la URL irá a este puerto.
Y no te tenés que preocupar tú nada, ¿vale?
A ver, ¿qué más?
Sí, lo creé a mano.
A ver, que os leo.
Lo creo.
Bueno, tenéis que subir el cambio, ¿vale?
O sea, importante.
Lo que vais a deployar a Heroku tiene que estar en la rama que vais a deployar.
Porque cuando pusheáis al origen de Heroku,
le estáis diciendo de qué rama va a tener que recuperar esto, ¿vale?
O sea, que lo tenéis que tener en la rama, tenéis que tener todos los cambios.
Entonces, ¿qué más?
Vercell lo veremos también para deployar cositas en Vercell.
Vercell, al final, es otra alternativa.
Lo que pasa es que Heroku para este tipo de servicios es más interesante.
Con Vercell no sé si lo veremos en el curso, pero si no, yo lo he utilizado en un montón de mis vídeos.
Si, bueno, si ya sabéis dónde ir, midu.tv o me buscáis como midu.dev en YouTube.
Y aquí, pues, en el curso de React lo utilizamos para deployarlo todo, Vercell.
Y es muy interesante, ¿vale?
¿Qué me preguntáis? ¿Qué tal? ¿Cómo lo lleváis todo?
¿Se puede dar un nombre con Heroku?
Buena pregunta. No tengo ni idea.
Al final, no sé si se puede.
Heroku create name.
Vamos a buscarlo.
Vamos a buscarlo.
Yo entiendo que sí.
La verdad es que nunca lo he utilizado.
Pero mira, create example.
Mira, sí que se puede.
Además, te pone aquí el nombre.
O sea que sí.
Yo nunca lo he utilizado porque normalmente, al final, lo que haces con este tipo de servicios en Heroku
es que tú lo dejas en ese dominio, pero luego tú tienes un dominio por delante que va a este,
que te da igual cuál sea el nombre y tal.
Al final, en Heroku te deben salir los nombres.
Bueno, es verdad que he cambiado algún nombre aquí.
Sí, por ejemplo, ¿ves esto de deno happy users y tal?
¿Alguna vez he creado aquí aplicaciones que ya le he puesto el nombre directamente?
Pero nunca lo había hecho directamente desde el click.
Pues mira, nunca te acostarás en saber una cosa más.
Vale, ¿es un Jenkins?
Pregunta.
No es un Jenkins.
¿Vale?
Un Jenkins, en realidad, mira, Jenkins lo utilizamos en nuestra máquina.
Jenkins, como tal, no es un servidor donde puedes hospedar aplicaciones.
Un Jenkins, al final, es una máquina en la que tú puedes hacer continuous integration y continuous delivery.
De hecho, podrías utilizar Jenkins para deployar a Heroku.
Eso sería lo que te haría Jenkins.
Creo que no vamos a ver Jenkins en el bootcamp, pero vamos a ver GitHub Actions,
que nos va a servir de Jenkins, ¿vale?
Por si os interesa, que lo sepáis.
¿Ok?
Conversant se permite Node.js.
Sí, pero de una forma diferente.
No es de esta forma.
De esta forma hemos deployado nuestra aplicación tal cual.
En Vercell hay que prepararlo de una forma, ¿vale?
Nos faltó servir el front, pero no os preocupéis que lo vamos a hacer en la siguiente clase.
Brutal la clase de hoy.
Metagoki dice.
Muchas gracias, hombre.
Me parece increíble la cantidad de conceptos importante que has dado en dos horas.
Bueno, hemos dicho que esto iba a ser un full-stab bootcamp y un full-stab bootcamp está siendo.
O sea, aquí no nos cortamos.
O sea, vamos a saco.
Espero que os haya gustado, hombre.
Muchas gracias a los que me habéis pagado hidratación y no he visto, como Dani Mofletes.
Muchas gracias a Chelorón por suscribirse con Prime.
RevengeHC91 por suscribirse.
A Elena González, que también ha pagado hidratación.
A Vicalle por suscribirse con Prime.
BigPack95 por suscribirse con Prime.
Muchísimas gracias.
Gracias a Mankabrita.
No he podido estar atento porque intento, claro, pensar que el full-stab bootcamp tiene un montón de conceptos
que intento explicarlo lo mejor posible.
El tiempo es el que es.
Hay que ir avanzando.
Y bueno, por eso os quedan las clases para que lo podáis revisar en YouTube tantas veces como queráis.
Lo podáis compartir a la gente y tal.
¿Vale?
Y por eso no puedo estar atento a la gente que se ha suscrito al Prime, pero que sepáis que os lo agradezco infinito.
¿Vale?
Aunque no diga nada, que sepáis que os lo agradezco un montón.
Mankabrita también se ha suscrito con Prime.
Gente que se...
Mira, 69, Mr. Creeper, se ha suscrito dos meses a Prime y me ha dicho que gracias por todo, Midu.
Muchas gracias a ti.
Carrevis se ha suscrito con Prime.
Tom Sonsk se ha suscrito durante tres meses por adelantado.
¡Qué crack!
Muchísimas gracias, Tom Sonsk.
Roberto Sambal se ha suscrito con Prime también.
Pues eso, que muchas gracias.
Ari Reinventada ha alojado 13 de espectadores, que me lo he perdido también porque estaba ahí súper...
Desde Democles ha suscrito con Prime, Witchos también, muchísimas gracias.
Blopa también ha alojado a tres espectadores, gracias.
Biespejo, Chavez, MX...
Bueno, muchísimas gracias a todos los que os habéis suscrito y me encanta que os haya gustado la clase.
AlphaCode dice, increíble, he hecho un curso donde pushear a Heroku era una semana entera.
¿Pero por qué?
Pero si ya hemos visto, ¿no?
¿Por qué va a ser una semana?
No entiendo.
Tardamos 11 minutos.
¡Casi!
Por poco, por poco.
Pensaba que íbamos a tardar 10.
Bueno, he intentado explicar...
Claro, he tardado más porque he estado explicando paso por paso.
Y os he explicado lo del remote, que eso muy poca gente lo entiende.
Os he querido explicar, ¿no?
Que Heroku, la magia de Heroku, es que cuando tú haces el Heroku Create, te está creando
o te está añadiendo un remote en tu repositorio, que es el suyo, que cuando tú pusheas ahí,
pues te hace el deploy, ¿vale?
Desde GitHub Page puedes apuntar a Heroku.
Sí.
Labón dice que es tremendo.
Github Page no vamos a utilizar.
Vercell puede ser, ¿vale?
Sí que puede ser, Alfonso.
Col, cool, bro.
Eh, bro, eres un crack, mi duda es.
Muchas gracias, huichos.
¿Se puede hacer desde la página de Heroku o no?
Sí, se puede hacer.
Desde la página de Heroku puedes crear tu aplicación y tal.
Pero deployar, hombre, deployar es mejor hacerlo desde el comando.
Pero bueno, luego más adelante veremos otras formas.
O sea, no vamos a hacerlo siempre desde nuestra terminal, ¿no?
Que sería un poco coñazo.
Gebo Beta, muy buena clase, como siempre.
Recuerdo que una vez lo creé con un comando.
Eres un crack.
Muchas gracias, Ado Molina.
Gran clase, la González.
Gracias.
¿Qué otro sitio recomiendas para deployar?
Recomiendo Vercell, recomiendo Heroku, ya hemos dicho, Netlify.
A ver, para deployar microservicios de backend, como hemos visto, Heroku es una de las buenas.
Otra sería DigitalOcean, ¿vale?
Esa sería otra.
Esta sería otra.
DigitalOcean.
Esta es bastante interesante también.
Y si no, también está, ¿cómo se llama?
¿Deploy.com?
No.
Hay una que es bastante nueva, app.com.
No.
App.com.
¿Puede ser?
No.
Ya la buscaré.
Pero hay una que es bastante nueva, que es bastante interesante.
Que está ganando bastante tracción.
Hago mentorías, pero ahora las hago en grupo.
Porque no tengo tiempo, ¿vale?
Pero veis, mentoría y asesoría.
Podéis buscar un grupo de gente, tres o cuatro, y os podéis compartir los gastos.
Y, por ejemplo, podemos hablar del bootcamp, podemos hablar de lo que queráis.
¿Vale?
Increíble, dos horas de brutal info.
Sí, dos horas, ¿eh?
A mí se me han pasado volando.
Yo no sé, ustedes.
A mí se me ha pasado, pero volando, volando, ¿eh?
En Vercel es más fácil, Liascat.
A ver, es diferente, ¿eh?
A mí ya me encanta Vercel.
No tengo ningún problema en...
O sea, no es que tenga nada en contra de Vercel.
Lo que pasa es que es diferente lo que deployas o cómo deployas en Vercel.
En Vercel es interesante, sobre todo cuando utilizan más o deployas archivos estáticos o deployas con una estructura más suya.
En este caso, a mí me gusta para el tema de servicios y tal, pero para el tema de este tipo de servicios, Vercel no me gusta tanto.
Bueno, si es para el pack completo, Vercel, si os apuntáis a mi canal de YouTube, lo veremos, porque es muy interesante cómo puedes deployar microservicios.
Y está bastante bien, no necesitas Express y tiene su propia herramienta y está bastante bien.
Yo creo que todo es...
Entonces, no sé, todo tiene sus cosas buenas y sus cosas malas.
¿Qué desventajas le veo a Vercel?
Mira, justo lo he dicho.
Escalabilidad y pricing me preocupa más Heroku que Vercel.
Vercel, la verdad es que en ese caso el pricing es bastante bueno.
Hace poco, ahora he tenido que empezar a pagar Vercel porque lo he petado con el blog.
Tengo un montón de visitas en el blog y, bueno, pues, claro, Vercel me ha dicho, bueno, hasta aquí.
Así que, nada.
Y es barato, son 20 dólares al mes, que teniendo en cuenta el movimiento que tengo yo,
me parece barato.
Y que hago todos mis proyectos, los hago en Vercel, todo.
Este lo tengo en Vercel y este también tiene una de visitas que ni te lo imaginas.
O sea, este no sé si tiene...
Vamos a ver.
Vamos a ver cuántas visitas tiene.
Mirad, hay 20 usuarios, 20 usuarios, ¿vale?
Este mes ha tenido 250.000 visitas.
Bueno, páginas vistas.
O sea, increíble.
250.000 visitas está teniendo esta página al mes.
Y es con Vercel.
Así que, sobre escalabilidad y precio, pues ya ves.
Tengo esta página más mi blog, que tengo otras, no sé si 50.000 o 60.000.
Pues imagínate, escalabilidad.
Pues esto va finísimo.
Esto va finísimo, mira.
Va rapidísimo.
Es verdad que son archivos estáticos.
Pero vaya, que no me preocupa mucho la escalabilidad y el precio.
Pues estoy pagando 20 dólares al mes y me despreocupo un montón.
Fue muy full stack.
Bueno, os dije que le iba a ser full stack.
Full stack y full speed.
Bueno, he intentado ir lo más rápido posible sin dejarme atrás la explicación que yo creo que es lo mínimo que os tengo que explicar.
He intentado seguir el ritmo, pero a la vez no dejar atrás cosas importantes.
De hecho, hay cosas que a lo mejor veis aquí en el full stack que ya veis que no lo he visto.
Me he podido saltar algo, lo revisaré por si me he saltado algo.
Pero he explicado más cosas que aquí no están diciendo.
No se explican los errores.
Sí que son los mismos, pero hay cosas que a lo mejor no explican que yo los he explicado y tal.
Y a lo mejor ellos han explicado otras cosas que yo.
Yo no, porque a lo mejor no he considerado tan interesante.
Excedente clase.
Un gusto tus explicaciones.
Gracias, Wilander.
Un genio.
Mil gracias.
Joder, qué bonito.
Me voy a ir a comer, pero por las nubes.
El mejor que los profes de la universidad.
Las notas nuevas, las que creaste recién desde el front, quedan guardadas.
Nachulina.
Claro, van a quedar guardadas un rato.
¿Ves?
Ah, mira.
Prueba después de borrado todas las notas.
Sí que pueden, mientras el servicio esté levantado.
Mientras esté levantado.
Bueno, esto no sé por qué, pero...
Mientras esté levantado, sí que va a funcionar.
¿Vale?
Mientras esté levantado.
Cuando no esté levantado el servicio o se reseté por lo que sea, pues veréis que vuelven a estar las iniciales.
Eso lo arreglaremos con MongoDB.
Obviamente lo que hemos hecho no está bien.
¿Vale?
¿Por qué?
Porque esto es porque tenemos una sola máquina.
Pero pensad que en la vida real, este tipo de APIs no tienes una máquina.
¿Sabes?
No tienes un servicio de Neroku.
No.
Tienes 24.
¿Para qué?
Para que esto pueda tener mejor escalabilidad.
¿Vale?
No tienes una máquina, tienes un montón.
Y por lo tanto no puedes hacer persistencia en 24 máquinas.
Necesitas algo aparte, como una base de datos, que ahí es donde tengas la persistencia.
¿Vale?
Metagokie.
Sí, de vez en cuando haré podcast.
Lo que no sé cuándo, pero sí voy haciendo podcast.
¿Con qué vídeo de tu canal se puede empezar de cero?
De cero, de cero, de cero no tengo todavía ninguno.
Pero la lista del bootcamp, si ya sabes algo de HTML y CSS, te puede servir.
Pero bueno, sí, me gustaría hacer uno que fuese desde cero.
Me gustaría.
Pero si no con este, aquí sí que enseñamos algo de JavaScript y te puede servir.
¿Vale?
A saber cuántas notas tendrás de aquí a una semana.
Sí, pero se van a ir reseteando.
Firebase es otra opción que está bien, pero no la vamos a ver en este caso porque la idea...
Firebase te quita mucho de este trabajo que hemos hecho nosotros, te lo quita.
Y queríamos que aprenderlo, ¿no?
Así que...
Madre mía, empezaré con los vídeos que me he perdido sobre el bootcamp.
Muchas gracias por la iniciativa.
Nada, Lilian.
Un placer.
Tengo una API hecha con Mongo.
¿Se puede deployar a Heroku sin problemas?
Yo creo que sí, soy Franz.
No debería hacer ningún problema.
¿Cuánto pago por esa analítica?
Pues estoy pagando ahora mismo 28...
No, 16 dólares más o menos.
Sí, sí, tengo gastos, tengo gastos ya.
16 dólares de analítica, 20 dólares de eversell.
Para que veáis que crear contenido no es gratis.
O sea, crearlo no es gratis.
Que cuesta, que cuesta.
¿Escalabilidad verás en YouTube?
Yo creo que sí.
Yo creo que eventualmente.
La pega de tier free de Heroku es que no permite alojar.
Ya.
No puedes alojar archivos, cierto.
Nunca hice mucho con profesores de programación, pero de los que tuve eso es uno de los mejores.
Gracias, hombre.
¿De dónde sacas el tiempo para hacer todo lo que haces, Midu?
Pues bueno, ahora porque estamos de confinamiento, sacrifico...
No sé, a ver, sacrifico.
Es que también es un hobby para mí, ¿no?
Y me gustaría...
Ya lo he dicho muchas veces, ¿no?
Que me gustaría vivir de esto, pero bueno, necesitaríamos llegar a 3.000 suscriptores para vivir de esto, por lo menos.
O 2.500 suscriptores, sería difícil.
Pero bueno, porque me gusta mucho, es que lo disfruto y me encanta hacerlo y por eso es como un hobby.
Y aparte de jugar a la consola, pues hago esto.
Pero además, como ahora estamos confinados, pues tengo más tiempo.
Y me suelo intentar...
Intento organizar muy bien, aunque hay veces que también mi pareja me da libertad también para hacer estas cosas.
Cosa que le agradezco el corazón y le mando un besazo enorme.
Porque es muy comprensiva, me da mucho apoyo y gracias a ella puedo hacer más cosas de las que seguramente podría hacer si no tuviese su apoyo.
Así que, muchas gracias.
La cuarentena ayuda.
La semana que viene.
La semana que viene vemos MongoDB.
Vamos a ver cómo podemos persistir los datos.
Vamos a terminar el deploy, porque lo hemos dejado...
Que a ver, no está nada mal, ¿no?
Hemos deployado nuestro servicio, lo cual está muy bien.
Pero vamos a deployar también la parte esta del frontend, para dejar de utilizar localhost para el frontend.
Vamos a deployar el frontend también.
Vamos a tener eso ya deployado en Heroku perfectamente.
Y vamos a saber qué es MongoDB, qué es esta base de datos, cómo persistimos los datos, cómo lo deployamos, cómo lo hacemos.
Bueno, no sé si lo deployamos.
Sí, hombre.
Yo creo que sí, lo deployaremos.
Bueno, pues eso, con MongoDB, vamos a persistir los datos, vamos a ir más allá, ¿no?
Cuando hagamos estos posts, en lugar de hacer este concat, este, ¿dónde está el concat?
Este, lo que haremos es ir a una base de datos, hacer peticiones, y MongoDB es muy, muy, muy, muy interesante.
Muy interesante.
Creo que es una de las bases de datos más potentes que existen.
No es SQL, así que la tenéis que aprender y para ser full stack hay que dominarla.
Además, yo hace mucho tiempo, sinceramente, que no la uso, hace mucho tiempo, así que esto me obliga también a aprender y revisarme.
A ver si han cambiado muchas cosas, espero que no, que sea el find, el find one, todo esto, que pueda hacer en batch los inserts sin ningún problema, o los upserts, o todas estas cosas.
Pero así podré estudiar y ver qué tal.
Voy por buen camino.
Sí, la verdad es que sí, muchas gracias a los 324 suscriptores que me estáis apoyando.
Os lo agradezco, no sabéis cuánto, de corazón, porque me ayuda un montón y no sabía que es bastante...
O sea, el hacer este tipo de contenido totalmente gratis es algo que dices...
Hay mucha gente que me ha escrito, mucha gente, mucha gente que me ha escrito.
De hecho, hace poco puse el vídeo este que decía, ¿por qué hago el contenido gratis?
Y hay gente que me... Bueno, mucha gente le dio like y fue muy guay, fue genial, pero me ha escrito gente que no le ha gustado.
Hay gente que me ha escrito en privado y no le parece bien.
Dice que, bueno, que estoy haciendo competencia de leal, por un lado, y que estoy matando negocios y que no está bien.
Y que estoy dando una falsa... Como que el nivel que yo puedo dar en Twitch, así, gratis, no es el que se puede dar con una persona que pague 6.000 euros.
De lo cual yo le dije que estoy totalmente de acuerdo, porque si yo diese gratis el nivel de lo que dan en uno de 6.000 euros,
pues entonces la gente que está pagando 6.000 euros tendría un... Bueno, la empresa que está ofreciendo ese servicio tendría un problema.
Bueno, así que sí, es verdad que, bueno, que eso, que es difícil, que es difícil.
Pero sé que hay mucha gente que no le puede chocar, ¿no?
Porque cada semana, dos horas, hacerlo a este nivel es complicado, porque lo sé yo, porque es lo que me pido y tal.
Pero yo pensaba que a lo mejor la gente no respondería tan bien al tema de aportar, de decir, pues estoy dispuesto a suscribirme.
Y hay gente, bueno, pues mis Patreons, que adoro, que son veintipico Patreons, y que hay gente que está pagando 24 euros,
que tiene unas ventajas y tal, y que es genial, que dices... Y que he hablado con ellos, porque ahora cada mes tenemos la posibilidad de hablar, ¿no?
Y estamos una hora hablando, y los conozco, y entonces me explican, y por qué lo hacen y tal.
¿Por qué? Pues porque, joder, es que me ha cambiado la vida, y cómo no, tal.
Y eso está guay, ¿no?
Entonces, no sé. Pero bueno, que entiendo que hay gente que no le guste, y que yo estoy súper contento de que pensaba que no tanta gente a lo mejor lo apreciaría,
y me he encontrado todo lo contrario.
Que hay un montón de gente que lo aprecia, y que, madre mía, que yo encanta, encantadísimo, encantadísimo.
Mira, Mayor dice que, perdona, hice un bookend de 7.000, y te digo de verdad que contigo he aprendido mucho más de lo que aprendí.
Con diferencia y con más calidad.
Pues mira, Mayor, tenía que haber cobrado 3.500.
200 por 3.500, madre mía.
Madre mía.
Madre mía.
Bueno, no sé. Estoy apostando por una forma diferente de acercar la programación, full stack,
de una forma más barata para todo el mundo, y que, bueno, si hay gente que quiere aportar, pues genial.
Si llegan momentos, somos tantos que podemos aportar tanto, pues yo qué sé, pues será increíble.
Y si no, pues espero que, de alguna forma, en algún día que te cambie la vida por esto,
pues que te acuerdes de que Midudev te ayudó en el camino.
Al menos pongas un sticker mío ahí en la laptop.
Pues eso. Bueno, que muchísimas gracias por todo vuestro apoyo y vuestro cariño en el chat.
Espero que os haya gustado mucho la clase.
Ya sabéis que estamos en Discord, ¿vale?
Que somos partners ya en Discord.
Somos más de 2.000 en la comunidad.
He añadido ranking, he añadido un montón de cositas.
Así que si queréis seguir aprendiendo, si queréis seguir comentando cosas de desarrollo web,
programación, full stack, pues que sepáis que en mi Discord ponéis el comando,
que es exclamación Discord.
Ahí seguimos con las conversaciones.
Y mañana tenemos la JavaScript Weekly, que más o menos dura una hora,
a la misma hora que hoy, a las 8, hora península española.
A las 8 empieza y hacemos un repaso de las novedades de JavaScript, ¿vale?
librerías, artículos, igual, pues cacharreamos un poquito con alguna cosa.
Cositas así, ¿vale?
Muchísimas gracias a todos.
Gracias por pasaros por aquí, por acompañarme.
Espero que hayáis aprendido algo nuevo.
Espero que os haya ayudado a subir de nivel.
Y os mando un abrazo enorme.
Espero que estéis muy bien.
Y que tengáis un feliz fin de semana.
Nos vemos aquí, en Twitch, mañana.
Hasta luego.
Y ya sabes, nunca dejes de darle al frontend.
En este caso, desarrollo full stack.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.
Chao.