Desacoplamiento en Práctica

Hola de nuevo, mi nombre es Chad Carlson. Soy el encargado del equipo de DevRel en Platform.SH. Esta es mi segunda Node.Congress, la segunda vez que hago una masterclass. Anteriormente, también hice una versión de esta.

Mi experiencia está principalmente en Python, pero desde que trabajo en Platform, se me asignó hace unos años la tarea de explorar mucho sobre este tema de desacoplamiento en nuestra plataforma. Y muchas veces, o al menos cuando me he encontrado con ello, y lo que mucha gente hace, es que a menudo tienen dos objetivos separados para implementar un front end y un back end de una architecture como esta, ya sea muchos, muchos microservicios o simplemente el back end de un CMS y el front end de un framework como Next.JS o Gatsby, sea cual sea. Por ejemplo, implementar el back end en Netlify, y el front end en Purcell, y luego tener que codificar la relación entre los dos. Y luego tener un verdadero desacoplamiento, tanto en los equipos que trabajan en el front end como en el back end, y también en los flujos de trabajo entre estas dos cosas. Por lo tanto, si genero un entorno de desarrollo para el front end, esa nueva versión del front end está obteniendo datos de producción desde donde sea que se haya implementado el back end en el mundo, y viceversa.

Entonces, lo que hace que Platform sea un poco diferente es que, en primer lugar, somos un proveedor de plataforma como servicio, y no tenemos restricciones en los tipos de frameworks que puede implementar en nuestra plataforma. Por lo tanto, puede ser Next.js, Gatsby, Nuxt, Express, Remix, pero también puede ser Django, FastAPI, Drupal, Magento, todas estas cosas diferentes que pueden pertenecer a varios entornos de ejecución. Por lo tanto, los admitimos a todos. Si está interesado, probablemente estaremos consultando la documentación mientras hacemos las cosas. Aquí están nuestros documentos públicos, y todos los entornos de ejecución, todos los lenguajes de programación que vienen con soporte incorporado en nuestra plataforma.

Como veremos en un momento, si quiero definir una aplicación que use Node18, puedo hacerlo al mismo tiempo, digamos que estoy extrayendo de un CMS backend de Drupal, con el que muchos de ustedes probablemente estén familiarizados, tienes a mi equipo de contenido en la parte posterior, puedo implementarlo con la misma clave pero usando PHP 8.2 en su lugar. Y además de eso, en lugar de tener este soporte agnóstico del lenguaje, también le permitimos seguir agregando recursos a un entorno singular, ya sea producción, preparación o desarrollo para que pueda implementar copias de estos contenedores en cada entorno. Entonces, cuando hablaba de si tengo dos objetivos de implementación diferentes para el front end y el back end, flujos de trabajo separados y equipos separados mientras realizamos cambios en el front end y el back end. Pero en Platform, como veremos, puedo tener en un solo entorno en lo que llamaremos un proyecto para nuestro repositorio de un conjunto completo de aplicaciones implementadas que incluye el front end y el back end en ese entorno único. Y luego, a medida que realizamos cambios, creo una nueva rama, un nuevo entorno. Obtendré copias exactas de ambos contenedores de aplicaciones en cada entorno. Y así, no necesariamente será lo más importante todo el tiempo para desarrollar nuevas funciones. Pero dos razones por las que me he encontrado, esto se vuelve especialmente útil. Uno es el ángulo de seguridad y PII, información de identificación personal. Si tenemos un sitio web de producción en el que los usuarios inician sesión y queremos crear entornos de desarrollo para cualquier cambio en particular. Es muy fácil dentro de este modelo desinfectar la base de datos para excluir, obfuscar o falsificar por completo ese tipo de datos de producción en estos entornos. Todo forma parte del mismo flujo de trabajo. Y luego, lo segundo es si estamos haciendo algún tipo de migración para agregar un front end diferente o agregar un front end secundario para móviles o cualquier otro caso, Y necesitamos no solo realizar cambios en el front end o solo en el back end, realmente estamos lidiando con cambios en ese contrato en el medio de esa API. Por lo tanto, es posible que necesitemos realizar cambios en ambas aplicaciones simultáneamente. Por lo tanto, resulta realmente útil tenerlas en su propio entorno separado para hacer eso.

Entonces, eso es un resumen rápido del proyecto, ¿qué vamos a hacer hoy? Nuestro objetivo aquí es implementar un proyecto de dos aplicaciones en nuestra plataforma en Platform SH, y el proyecto en el que vamos a trabajar se llama food adviser. Estoy seguro de que muchos de ustedes están familiarizados con Next JS, que será nuestro cliente de front end. Y va a consumir datos de un CMS de back end headless llamado strappy. Si no lo ha escuchado, simplemente proporciona una interfaz de usuario para definir colecciones, ya sea una publicación de blog o en este caso, la cosa que estamos implementando es un sitio web de reseñas de restaurantes que incluye blogs, usuarios, reseñas, restaurantes, comida, categorías, cosas así. Strapi facilita bastante la creación de esos tipos de contenido en la interfaz de usuario en el back end, para luego armar esta API de producción que puede ser consumida por algo como Next JS. Y así, incluso para Strapi, que es su demostración principal. Y no me atribuyo ningún mérito en el desarrollo de las aplicaciones en sí, pero podemos echar un vistazo a cómo se juntan para comprender la lógica, especialmente del back end de Strapi. Y luego agregar la configuración de la plataforma a su alrededor para implementar esto en producción. Eso es en lo que nos enfocaremos hoy. Entonces, voy a compartir un enlace con todos ustedes. Este es un repositorio que he configurado para que pasemos por esta masterclass, así que lo agregaré tanto a Discord como al chat de Zoom. Y básicamente es el punto de partida de cómo vamos a construir esta demostración y luego implementarla pieza por pieza. Así que deshagámonos de eso por ahora. Desde este repositorio principal que acabo de compartir. Bien, lo siento. Hagamos las plantillas de usuarios y creemos una nueva en nuestro espacio de nombres. Y vamos a hacer todo eso. Este soy yo. Si tienen alguna pregunta, soy prácticamente Chad W Carlson en todo. Chad Carlson ha tomado prácticamente todo. Así que vamos a clonar este repositorio localmente. Y mientras eso sucede, la forma en que está estructurado es una breve descripción de la masterclass en el archivo de lectura principal, información de licencia para las demostraciones de food adviser en el upstream incluido en esta nota principal, y luego una. Disculpen, estructura de lo que vamos a pasar aquí. Como dije, el objetivo aquí es hablar un poco sobre este back end y cómo se compone. Implementarlo, conectarse al front end. Y luego, si tenemos tiempo, comenzar a hablar sobre lo que significaría comenzar a cambiar a servicios de producción y desarrollar nuevas funciones como agregar soporte de correo electrónico. La mayoría de los pasos estarán dentro de este conjunto de subdirectorios de pasos de ayuda, y luego el cliente es el código de front end al que llegaremos al final. Veamos, ¿está listo? Sí. Bien, así que abramos esto en VS code.

Y siéntanse libres de, como dije, trataré de estar al tanto de todo, pero si algo no es muy visible. Háganmelo saber. Entonces, ¿por dónde queremos empezar aquí? Si vamos al primer subdirectorio, podemos comenzar. En cuanto a lo que tengo en mi computadora en este momento, estoy trabajando con node 18, la última versión de yarn. Tengo gets, y tengo una cuenta en GitHub, obviamente para crear a partir de esa plantilla, así como los dos protocolos de los que hablé antes.

Creemos una aplicación Strapi. Así que podemos usar yarn para hacer eso. Con esto, yarn crea una aplicación Strapi en un subdirectorio llamado API. Y podemos hacer eso rápido para ver cómo se ve esto. Veamos si esto funciona. Digo eso porque hay un error que aparece con algunas aplicaciones de node que probablemente hayas visto antes en Mac OS, relacionado con Sharp. Si notas un error en esta etapa o en otro momento, puedes exportar esta variable de entorno y eso generalmente solucionará el problema. Si por alguna razón no puedes generar el proyecto, lo haremos dos veces en este taller.

Bien, parece que estamos bien. Entonces, si entro en ese subdirectorio API, debería poder ver lo que tenemos. Sí. Estamos en desarrollo, ejecutaremos mis scripts del servidor de desarrollo. Y construirá la interfaz de usuario del backend, y podremos ver eso en 1337 no cinco, siete. Aquí es donde podemos comenzar. Y desde aquí, como te imaginarás, crea una cuenta rápida para que podamos hacer un recorrido. Así que ahora he creado una cuenta de administrador, parece. Cualquier cosa relacionada con complementos se encuentra aquí. Realmente no vamos a lidiar con eso, la configuración de mi servidor está incluida aquí. Obviamente, cualquier cosa que se cargue, como imágenes y demás, va aquí. Aquí es donde puedo gestionar mi contenido para la colección existente. En este caso, lo único que viene preconstruido, al igual que en muchos otros frameworks, es el modelo de usuario. Y luego tengo este espacio que puedo editar porque estoy en modo de desarrollo, donde puedo crear nuevas colecciones. Entonces, desde aquí, creemos una. En este caso, una muy básica es que quiero crear artículos o blogs. Se generará automáticamente dónde terminará en la API, que puedo editar. Pero por ahora, si voy a obtener un artículo, es article, de lo contrario, articles. Quiero un par de campos diferentes para esto, como título con texto corto. Quiero otro campo, que es el cuerpo. Veamos. Definitivamente quiero que sea obligatorio. Y eso está bien por ahora. Así que voy a guardar esos campos. Muy bien. Se reinició. Ahora tengo artículos dentro de la sección de administrador de contenido de mi backend. Asegurémonos de que no me falte nada. Así que creemos algo. Esto será solo mi primer artículo. Y hagamos algo como... Creo que lo incluí en los pasos allí este feed de Loren Ibsen, que uso todo el tiempo. Lo voy a poner en mi cuerpo y lo voy a guardar. Muy bien. Así que hemos guardado el artículo, lo que significa que podemos hacer cosas como verificar qué está sucediendo con la API ahora que tenemos esta colección y algo de contenido en ella. Como vimos antes, debería ser API articles.

Y el primer mensaje que recibimos es que no tenemos permiso para ver eso. Así que eso probablemente significa que nuestros permisos no están configurados correctamente. Supongo que no es bueno.

Bien, cuando construí mi contenido, no hay nada realmente para los permisos. Tendré que ir a la configuración y roles. Y estamos haciendo una solicitud pública. Así que dentro de mi público para usuarios no autenticados, veremos esa nueva colección aquí definida, hay un artículo y realmente solo estoy tratando de averiguar todos los artículos, en lugar de solo uno. Así que puedo permitir que los usuarios públicos accedan a esto, encontrar la acción en el punto final. Así que si guardo eso, bien, si vuelvo al punto final y actualizo, ahora veo que no estoy prohibido, pero no tengo nada aquí a través de esta matriz de datos. Así que si luego vuelvo a mi administrador de contenido, veo que en realidad tengo esto en estado de borrador. Así que ahora, si adelanto y publico el artículo, luego vuelvo a golpear el punto final, puedo obtener el artículo completo. Y ya tiene un ID adjunto. Tiene mis campos de atributos personalizados que configuré. Así que mi título y cuerpo y luego algunos incorporados, como cuándo se creó y actualizó, el tamaño de la página y demás. Así que ahora estamos construyendo una API a partir de cosas bastante básicas. Si quisiera obtener información sobre los usuarios que se registran en esta API de backend, puedo hacer lo mismo y podemos construir muchos otros tipos de colecciones para construir esta API. Pero esto es el funcionamiento básico de cómo Strapi te ayuda a hacer eso.

Ahora que nos hemos familiarizado un poco con cómo funciona esto, voy a eliminar lo que he hecho aquí de este subdirectorio de API y tú puedes hacer lo mismo. Asegurémonos de estar aquí. Ya no necesito esto. De acuerdo. Así que ya tenemos un repositorio inicializado, por lo que podemos omitir la mayoría de estos pasos aquí, ya que comenzamos desde una plantilla. Y creemos una nueva aplicación con el mismo nombre. Y creemos una nueva aplicación con el mismo comando que hicimos antes. Así que eso fue yarn createStrapiApp llamado API. En este caso, las únicas otras banderas que se incluyen aquí son Quickstart, que simplemente configura la misma colección de usuarios predeterminada, y NoRun, por lo que no se ejecutará automáticamente ese servidor de desarrollo. Y lo que haremos después de que termine es construir todas las colecciones que se incluyen en esta aplicación de demostración. Es una - se llama FoodAdvisor. Es un sitio de reseñas de restaurantes. Así que, como dije, voy a tener algunas colecciones basadas no solo en publicaciones de blog, sino también en los autores de esas publicaciones de blog y las relaciones entre ellos. Voy a tener colecciones para los propios restaurantes y las reseñas dejadas por, nuevamente, usuarios, categorías para esos restaurantes y algunas más. Así que empecemos a hacer eso. Traté de incluir todos los comandos necesarios aquí, así que vamos a través de ellos. El primero es, oh, cierto. Esto es solo para limpiar algunas cosas. Por defecto, vamos a obtener estos dos directorios configurados para nosotros. Así que vamos a eliminarlos porque vamos a mover algunas cosas aquí. Así que eso elimina el subdirectorio predeterminado de API y extensión, pero los llenaremos con algunas cosas. Y ahora, dentro de, hagamos esto un poco más grande, dentro de help, tenemos esta especie de primera etapa, que trata de generar esta API. Y lo que quiero hacer es mover algunas cosas aquí. Así que ese primer comando va a mover la API. Bueno, supongo que debería mostrarte eso la primera vez, pero ahora podemos echarle un vistazo. Si ejecuto ese comando, lo que ha hecho es construir un nuevo subdirectorio de API. Así es como Strapi maneja este esquema para esta API. Por defecto, la base de datos misma va a estar en SQL light, y vamos a entrar en eso. Pero luego, al representar esos tipos de contenido. Esto es muy similar al artículo que configuré anteriormente, diremos que este tipo de contenido artículo tiene una definición de lo siguiente. Se llama artículos, aquí están esas diferencias de punto final que terminan construyendo esa API. Queremos que las piezas de contenido incluidas en este tipo de contenido tengan un horario de borrador y publicación. En este caso, tenemos algunos otros atributos que se incluyen aquí, los mismos que los que definí antes, tiene un título, un slug, un slug para la URL, que usaremos para extraer el NextJS, tiene una imagen, el contenido principal del cuerpo y algunos otros bloques que se definen que veremos. Tiene una categoría, que en este caso es una relación con un tipo de contenido diferente, así que diremos que hay un tipo de contenido diferente.

Veremos que hay una colección de categorías aquí. Y tiene una relación de muchos a uno. Un artículo puede pertenecer a muchas categorías. Y eso es lo que hace esta definición aquí. Tiene publicado por autor. Lo mismo. En este caso, es de muchos a uno en la dirección opuesta, donde un autor puede haber escrito muchos artículos. Y ese es el atributo allí. Y eso es todo lo que vale la pena revisar. Y eso es todo lo que vale la pena revisar. Todos estos son realmente incorporados controladores para esta colección, pero podemos ver eso moviendo lo que teníamos en esa ayuda. En realidad, creé bastantes colecciones: artículo, blog, página, categoría, etc. Pero aún no hemos terminado. Así que eso solo configura la parte del código de eso. Así que voy a mover los componentes que vimos en ese esquema, que harán cosas como componentes. Esos eran los bloques que vimos, así que si quiero tener un fragmento del bloque del sitio web dedicado a mostrar artículos relacionados en una publicación de blog. Eso es lo que se configura y luego se puede incluir en un atributo asociado a esa publicación de blog que estamos viendo actualmente, CTA, FAQ, muchos de estos bloques que se reutilizarán en el backend de la API, configurando ese modelo. Haremos lo mismo con otra carpeta llamada extensiones. Y en esta carpeta. El tipo de contenido son los permisos de usuario. Entonces, simplemente estamos diciendo que cualquier usuario que haya iniciado sesión. Tienen todos los atributos asociados a un usuario normal. Pero ¿se les permite comentar un artículo o dejar una reseña en un restaurante, básicamente, según su tipo de permiso? Incluimos eso en la extensión de permisos de usuario, que viene con Strapi. Y luego lo último que voy a hacer es copiar los scripts que nos permitirán construir esta base de datos. Entonces, si lo miramos ahora, la estructura es básicamente cómo se configura el servidor, un lugar para las migraciones, un directorio público donde podemos cargar imágenes y luego dónde se encuentran nuestras APIs. Así que si muevo esto, obtengo un script de inicialización, que va a extraer de un archivo data, que también está dentro de este directorio de ayuda, y veremos cuáles son las consecuencias de ejecutar eso. Y supongo que vamos a seguir adelante y copiar ese archivo zip fuera del directorio de ayuda. Y ahora veremos ese archivo zip aquí dentro de API o Strapi está configurado. Y luego lo último que necesitamos hacer es simplemente darnos algunas dependencias que nos ayudarán a ejecutar realmente este script de inicialización como dependencias aquí arriba. Bien, eso es todo. Así que veamos cuáles son las consecuencias de eso. Vamos a ejecutar el comando de inicialización. Bien, ahora debería tener dos cosas. Debería tener mi base de datos SQLite inicializada aquí en dot tmp. Y también debería tener. O deberías tener una colección de estas imágenes cargadas dentro de public/uploads. Y eso realmente debería ser todo lo que necesitamos. Y podemos seguir adelante y ejecutar. Vamos a ejecutar aquí, yarn develop. De acuerdo. Y si volvemos a localhost:1337, aquí está el mismo panel de administración que vimos antes. En este caso, sin embargo, la base de datos se ha inicializado con el usuario de administrador. Ojalá esa fuera mi URL. Si pudiera obtener chad.com. Y así esas credenciales se incluyen en este archivo readme, como admin en strapi demo. Y esta contraseña ficticia. He estado en strapi demo calm. Bueno, el otro es, sí, podemos seguir adelante e iniciar sesión. Así que se ve exactamente igual que antes, pero el recorrido muestra que ya no necesitamos hacer ninguno de estos pasos, ya los hemos completado.

Entonces, volvamos a generar la API. Oh, hola, ya tenemos 23 personas. Hola a todos, más que en mi última comprobación. Sí, nuevamente, siéntanse libres de dejar un mensaje en el chat de Discord o en el chat principal de Zoom, y trataré de responder si tienen alguna pregunta o tal vez quieran que vaya más despacio.

De acuerdo, así que guardemos estos cambios, porque en realidad no vamos a desplegar y hacer cosas. Entonces, hagamos eso ahora. Y strap. Ahora eso debería actualizarse aquí. Sí, aquí está nuestro subdirectorio de la API que acabamos de crear. Intenta pensar si hay algo que valga la pena mencionar. No creo. Vamos a desplegar esto.

De acuerdo, lo siguiente que queremos hacer. Creo, así que vamos a desplegar esto. Como dije, Platform.SH es un proveedor de plataforma como servicio. No está específico para ningún tipo de runtime. Hoy vamos a hablar de JavaScript, pero podría ser lo mismo para cualquier otro lenguaje utilizado para construir ese back-end. Pero por ahora, lo que vamos a hacer es usar Platform para desplegar inicialmente esta aplicación de JavaScript. Así que hagámoslo. Voy a crear un nuevo proyecto con este comando. Probablemente no tendrás la misma estructura inicial de la organización, pero si la tienes, selecciona tu propio nombre de usuario. Y esto se llamará Node Congress 23. Luego tengo algunas opciones de dónde en el mundo quiero poner este servidor. Por lo general, les digo a las personas que lo pongan lo más cerca posible de donde creen que los visitantes solicitarán su sitio o lo más cerca de ustedes, si eso tiene más sentido. Así que estoy eligiendo una ubicación en Charleston. Ya que estoy en Florida. Quiero que sea un repositorio remoto para mi repositorio, y estoy de acuerdo en pagar $0. Muy bien, así que Platform va a crear este proyecto para nosotros. Este será el objetivo final al que vamos a desplegar estas aplicaciones. Muy bien, veremos eso cuando termine. Ahora tengo un proyecto en esta región de Estados Unidos, parece que está en Charleston. Tiene un ID de proyecto asociado, que veremos aquí, y una URL de git. No necesitamos esa URL de git porque ahora tengo un origen configurado llamado platform que está utilizando esa URL de git, vamos a seguir empujando a git pero ya se ha configurado para nosotros. Muy bien, echemos un vistazo a esta URL, que es el resultado de crear el proyecto. Haz clic derecho en la pestaña y hazlo. Esto cambiará en un minuto, esto es solo un hash de mi nombre de usuario. Ahí vamos. Si te das cuenta, está un poco pequeño en tu pantalla, pero esto simplemente dice console.platform.sh, que es la interfaz principal para tratar con proyectos y despliegues en nuestra plataforma. En este caso, tienes la opción de organizar proyectos en organizaciones, que puede ser lo mismo para ti que una organización de GitHub, o si eres una agencia que crea proyectos para muchos clientes diferentes. Podría ser, por ejemplo, el equipo de PHP o el equipo de Next versus el equipo de Express, que pueden existir en su propia organización, pero proporciona esa pequeña flexibilidad adicional para organizar tus proyectos, y luego ese mismo ID de proyecto. Si en algún momento lo necesitas, ese ID de proyecto también está disponible en este menú desplegable de tres puntos en la esquina superior derecha, pero esta es la consola de administración. Entonces, si voy a este enlace del proyecto, obviamente, mi trabajo es desplegar estas cosas todo el tiempo, así que tengo muchos, muchos, muchos proyectos en este espacio. Probablemente solo tendrás uno a menos que hayas tenido la oportunidad de jugar con esto antes de que comenzáramos. Pero luego un proyecto singular que existe aquí para que trabajemos desde allí. Me falta un mensaje aquí. No parece que haya. De acuerdo. Entonces, ¿qué se está configurando aquí? Lo que queremos hacer es tomar nuestro repositorio de GitHub e integrar este proyecto con él para que se convierta en un repositorio espejo de ese repositorio de GitHub para que podamos continuar con el proceso de revisión y las solicitudes de extracción y las acciones de GitHub para nuestra integración continua y permitir que esto realmente sea el aspecto de despliegue continuo de cómo tratamos tanto la producción como nuestros despliegues en esas revisiones. Ahora he seleccionado mi rama predeterminada como main porque eso es lo que coincide con mi repositorio actual. Y realmente solo necesitamos configurar esta integración. Así que hagámoslo.

Estábamos en la sección de implementación O2 de esta masterclass. Muy bien. Lo primero que debo hacer es generar un token de GitHub. Puedo hacerlo con este enlace aquí. Lo he incluido aquí. Pero llámalo como quieras si vas a mantener el repositorio que acabamos de usar, el que compartí en el chat, como una plantilla, necesitamos al menos los permisos de repositorio público y gancho de repositorio de administrador para que esta integración funcione. Y eso debería ser suficiente para comenzar a enviar cosas a Platform.

Dentro de este readme también se encuentra lo que necesitas para configurar esto para un repositorio privado. Así que adelante y utiliza este enlace para crear un nuevo token. No voy a hacer eso porque, ¿quién quiere un token por ahí? Y vamos a usar este comando para configurar la integración. Así que ingresémoslo, y luego lo ingresaré en secreto para hacerlo realmente. Entonces vamos a usar la CLI para agregar una integración de tipo GitHub utilizando el token que acabas de crear para vincularlo al repositorio con el ID del proyecto. ¿De acuerdo? Así que podemos hacer eso en partes ahora mismo, si quieres.

Veamos aquí. Integración cálida. Y tipo. GitHub. Proyectos. Como dije, si voy a ese proyecto, puedo obtener el ID del proyecto justo aquí. Proyectos, luego debería haber un repositorio, que puedo obtener de aquí. No necesito incluir el github.com porque tenemos el tipo allí, solo necesito el nombre de usuario y el repositorio. Y creo que eso fue todo. ¿Correcto? Tipo token repo proyecto. Muy bien, ahora. Entonces, nuevamente. Secreto. Muy bien, esto es lo que va a preguntar. Va a hacer algunas preguntas sobre cómo quieres que Platform maneje la integración. Entonces, la primera es si quiero construir una solicitud de extracción. Sí, quiero. Solicitudes de extracción en borrador. Claro. Después de la fusión, no, quiero que esté en el estado del commit actual. Clonar data. Así que veremos un poco las consecuencias de esto. Pero de la manera en que veremos cómo los entornos se relacionan desde una rama o una solicitud de extracción a un entorno en Platform. Parte de cuando entramos en la configuración de estos containers de la aplicación es que Platform se encarga de gran parte de cómo se maneja data entre los entornos. Así que no necesitamos un proceso separado para asegurarnos de que un entorno de preparación de nuestra API contenga los mismos data y puntos finales que la producción. Vamos a hacer mucho de una herencia por ti. Así que voy a decir verdadero porque quiero ver ese comportamiento. Quiero conocer todas las ramas en GitHub. Pero quiero eliminarlas cuando se eliminen en GitHub. Y queremos sincronizar. Así que vamos a continuar. Y si vuelvo al proyecto, deberíamos ver algunas cosas sucediendo. De hecho, vemos un error. Aquí estaba en mi vista de proyecto. Ahora estoy en mi vista de entorno para el repositorio que tiene solo una rama principal. Así que este es ahora el entorno asociado con esa rama.

Si continúo y reviso esa actividad donde GitHub empujó mi proyecto, veré un error que se ve así, que es lo que esperamos. No hemos hecho nada. Platform no tiene idea de qué hacer con eso. Disculpa. Entonces, ¿qué falta? En este momento, dice que no tengo un archivo platform app yml. Así que no tengo nada que diga qué lenguaje de programación es, ¿cómo se debe compilar? ¿cómo se debe desplegar? ¿cómo se debe iniciar? Así que necesitamos ese archivo. Y también me falta un archivo root.yml, que va a decir cuando alguien solicite este entorno. ¿A dónde va? ¿A qué contenedor de aplicación va? Así que definitivamente necesitamos esos dos archivos. Así que vamos a escribirlos. Así que salgamos de aquí. Vamos a crear una nueva rama. La vamos a llamar platformified. Muy bien. Así que ¿dónde estoy en API? Así que quiero crear un nuevo archivo en api.platform.yml. Y en realidad quiero crear un nuevo directorio compartido llamado platform en roots. En realidad, ya lo hicimos cuando configuramos la integración. Así que si por alguna razón no lo creó por ti, créalo. Y quiero crear un nuevo archivo en ese directorio llamado roots.yml. OK, ahora tenemos dos archivos con los que tenemos que hacer algo. Tenemos app.yml y roots.yml. Así que si volvemos al readme, creo que he incluido algunos pasos sobre cómo hacer esto aquí. En realidad voy a duplicar esto. No quiero estar saltando de un lado a otro. Muy bien. Así que creamos la integración del proyecto. Aquí vamos. Entonces, nuevamente, esto es cómo debería verse tu estructura en este punto. App.yml anidado dentro de API de Strapi que acabamos de crear y roots dentro de este directorio dot platform. Muy bien. Primero, si entramos en roots, esto es cómo se ve nuestra configuración. Y la idea aquí es que tengo dos claves de nivel superior para esas raíces principales. Si empezamos desde abajo, en realidad, quiero que las solicitudes que van al subdominio API vayan directamente a una aplicación que definiremos en el otro archivo llamada Strapi. Eso es realmente todo lo que está haciendo. Y luego quiero una ruta emparejada con esa ruta ascendente, que va a manejar una redirección. Así que en este caso, cualquier cosa que vaya a www se redirige a la misma ruta que definimos aquí arriba. Y así que una cosa a tener en cuenta aquí en este archivo de configuración es este marcador de posición predeterminado que vemos tres veces aquí en este archivo. Y esto realmente solo dice, para nuestra rama principal, por ejemplo, cuando finalmente lo pongamos todo junto y lo configuremos en Platform, Platform-SH va a crear, va a generar una URL para ese entorno. Va a ser algo como main-biglonghash.US4, que es la región que elegimos,.platform-SH-site o algo así. Pero cualquier nueva rama que creemos a partir de entonces, se creará una URL generada similar. Lo que hace esta configuración, lo que es lo suficientemente inteligente como para descubrir, es que cuando creo una nueva rama en la que me voy a enfocar solo en Strapi o en el front-end eventualmente, quiero que esta misma configuración se aplique, y así que este predeterminado se convierte en el lugar donde se sustituye esa URL generada aquí. Genial, así que esa es nuestra configuración de roots.

Ahora, si continúo y voy a mi configuración de la aplicación, no tengo nada aquí, pero tengo un fragmento incluido en el readme. Así que veamos qué es y qué hace. Entonces, como mencioné en el archivo root.yml, quiero que todas las solicitudes vayan a una aplicación llamada Strapi. Veremos esa clave coincidida aquí en los atributos de nombre. Este archivo, puede que haya mencionado su propósito, es decir, necesito un contenedor de aplicaciones que ejecute JavaScript para construir esta aplicación backend. Eso es lo que está haciendo. Entonces, quiero que se llame Strapi, tiene que ser un nombre único dentro del entorno. Y quiero que use node 18, Platform hará ciertas suposiciones si así lo deseas sobre cómo te gustaría que las aplicaciones se construyan y desplieguen.

Uno de esos lugares es este build flavor. Si echas un vistazo a la documentación. Ve a JavaScript. O está appy no está ahí. Ten paciencia. No puedo escribir tampoco. Aquí vamos. Entonces lo que vemos aquí son estos atributos de build flavor. Entonces, lo que Platform hará automáticamente si esto no estuviera aquí, es que revisará mi NPMRC y ejecutará npm install cuando se construya esto. Pero aquí queremos usar yarn en lugar de npm. Entonces, build flavor none anula esa suposición. Quiero usar la última versión de yarn y tenerla disponible. Quiero construir una versión de producción de este backend. Y luego quiero construirlo. Así que en este caso lo estoy construyendo usando yarn. Quiero que mi construcción sea. Sí, quiero que mi construcción sea repetible en todos los entornos. Y eso será importante porque cuando comencemos a hacer cosas de ramificación. Realmente quiero que todo sea lo más estático posible hasta que haga una diferencia explícita. Algunos usan esta marca de archivo de registro congelado para asegurarse de eso. Y luego voy a construir el backend antes, localmente solo estábamos ejecutando el servidor de desarrollo pero vamos a hacer realmente una construcción y comenzar aquí en el entorno.

De acuerdo, así que vamos a construir la aplicación Strapi del backend. Y en este caso para los comandos de inicio. Tengo que proporcionar la ruta pero no quiero ocultar ninguna exportación, pero eso es realmente todo lo que está haciendo. Así que está ejecutando yarn start como mi comando de inicio. De acuerdo, así que eso configurará mi imagen de construcción para esta aplicación Strapi. Y el objetivo de este archivo, además de construir y desplegar la aplicación, es tratar de crear una imagen de construcción reutilizable. Así que cuando creo un nuevo entorno, puedo mantener esa imagen de construcción en la creación del nuevo entorno, porque ese es nuestro objetivo principal en Platform es, en el acto de ramificación, crear automáticamente entornos de preparación reales. Así que eso son dos partes. Eso es cómo construimos imágenes. Así que veremos aquí que muchas de estas suposiciones se hacen para que Platform se encargue de mover imágenes de construcción en lugar de usar un servicio externo. Y el otro es cómo se maneja data. Así que en este caso todavía no estamos lidiando con ningún servicio. Solo estamos lidiando con la base de datos, que como dije antes, va a estar en este punto TNP, que se refleja aquí. Y así queremos que data también se herede. Pero data es diferente al código, como queremos que sea escribible en tiempo de ejecución, es un ejemplo importante. Y eso entra en conflicto con nuestro objetivo de construcciones repetibles. Entonces, lo que esta parte del archivo está diciendo es todo lo que está arriba de aquí va a ser una imagen de construcción estática asociada con el estado de este repositorio en este punto en el tiempo. Todo lo que está aquí es algo que puede verse afectado en tiempo de ejecución. Así que en este caso, quiero poder cargar imágenes y quiero poder cambiar la base de datos. Entonces, cómo se heredan en los diferentes entornos va a ser un poco diferente. Pero una vez que esto se despliega, todo el sistema de archivos es de solo lectura excepto por las cosas que definimos explícitamente aquí. Así que en este caso, las cargas públicas es donde teníamos las imágenes. Así que mantengamos eso como escribible y sigamos siendo capaces de escribir en la base de datos.

De acuerdo, eso es casi todo. Lo otro que necesitamos está dentro del subdirectorio API se crearon dos archivos cuando creamos ese proyecto. Y este es realmente el importante. Entonces este archivo .env dijo, queremos servir desde este puerto, esta es la base de datos que queremos usar y configuró algunas claves, sales y secretos iniciales que se utilizan internamente en la aplicación. Así que necesitamos replicar esto dentro del entorno porque si los configuramos como variables de entorno adecuadas, estos no se utilizarán o este no se generará porque .env no está y por una buena razón no se hace commit. Así que creemos un nuevo archivo aquí llamado .environments y copiemos lo que se incluye en ese archivo leído allí.

¿Cómo se ve esto? Tiene algunas claves de aplicación genéricas que probablemente podamos hacer más seguras si queremos pero por ahora esta línea sigue siendo la misma pero puedo extraer del entorno y hacer algunas cosas. Así que tengo dos sales y dos secretos que se extraerán de variables que ya están expuestas por el uso de la plataforma dentro del entorno. Entonces uno es este valor de entropía que será único para este proyecto solo un gran hash largo que puedo usar para estos tres valores. Y luego otro que está asociado con el hash de confirmación actual. Es para el aspecto de árbol de Git en lugar de la confirmación en sí. Pero es otro valor aleatorio que realmente cambiará entre despliegues pero es algo que podemos usar aquí. De lo contrario, necesito dos conjuntos que quiero seguir usando SQLite y que quiero que se mantenga en la misma ubicación en la que existía localmente. Y creo que deberíamos estar bien aquí, sí.

De acuerdo. Así que volvamos aquí. Veremos que estos tres archivos han cambiado. Vamos a platformificar. Oh, no le gusta eso. No puedo exclamar en mis mensajes de confirmación. Espera, ¿qué pasó? Ni siquiera está en mi historial. Eso está bien. Entonces, en lo que era mi rama, platformificar. Push origin platformificar. Muy bien. Entonces primero veamos qué sucede aquí. Así que he agregado mi configuración. Vuelvo a mi proyecto. No veo ningún cambio allí. Pero veo esa nueva rama disponible para una solicitud de extracción. Entonces lo que vemos aquí es que tengo lo que se llama un entorno inactivo. Entonces la rama está rastreada pero no se activa no intenta construir y desplegar esa configuración que acabo de hacer. Pero si creo la solicitud de extracción basada en cómo configuramos la integración. Y agrega rutas de aplicaciones y configuración de variables o. Muy bien, creemos esa solicitud de extracción. Muy bien, así que deberíamos ver en este caso que he creado el token, así que es mi cara la que aparece aquí. Pero ahora debería estar activando ese entorno que veremos aquí. Veamos. Puede tomar un segundo para que aparezca en el diagrama de la rama. Ahí está. Puedo filtrar los entornos inactivos y ir al entorno de la solicitud de extracción. Así que démosle un segundo, pero puedo ver los registros también mientras esto sucede. Así que vemos que estoy construyendo una aplicación Strapi y estoy construyendo con node 18 en esta caché única que caracteriza el estado actual del entorno. Y lo que hará es pasar por lo que he colocado en ese archivo de configuración. Así que en este caso, va a instalar las dependencias por un momento. Y si te fijas aquí dentro, tengo la salida de mi construcción. Pero también tengo esta sección aquí que simplemente dirá que Platform va a aprovisionar certificados de Let's Encrypt automáticamente para este entorno. Muy bien, ahí vamos. Entonces el entorno debería haber terminado su despliegue ahora. Y tenemos un fallo. Entonces, ¿por qué tenemos un fallo aquí? Supongo que es porque no tenemos ningún data. Así que vamos a cargar esos data. Tengo algunos comandos adicionales de la CLI. Van a tomar lo que ya hemos configurado aquí, dentro de las cargas públicas y .tmp. Así que voy a ejecutar esos comandos ahora. Así que voy a cargar todo desde las cargas públicas a esa montura de cargas públicas.

Oh, correcto. Pero necesito incluir el entorno en este caso. Así que configuraremos todas esas imágenes ahora. Y luego haremos lo mismo para esa database que tenemos localmente. Lo olvidé de nuevo. Entonces, en este caso, Entorno PR1. Y subir ese archivo. Y veremos que se ha hecho eso. Si continúo y también puedo conectarme por SSH a ese contenedor o al entorno PR1, veremos que tengo. Entonces, si voy, digamos, .tmp, ahí está mi database y ahí están todas mis imágenes. Salgamos de ahí. Lo que quiero hacer ahora es volver a implementar ese entorno. Ahora que he realizado esos cambios, sí lo hago. Ahí vamos. Ahora que he subido los data, todo parece estar bien. Debería poder verificar que todos esos data sigan aquí. Algo está pasando aquí. ¿Qué está pasando? Quiero investigar. Puedo entrar en mensajes de cada sesión y verificar los registros. ¿Cuál es el problema? ¿Qué me golpeó? A esto en su lugar. Salgamos de aquí e intentemos ejecutar esto desde cero de nuevo. Iniciar una semilla de nodo directa. Muy bien, parece que está teniendo problemas para encontrarlo. Entonces, voy a hacer commit de eso en su lugar. Muy bien, sí, intentemos hacer commit de este archivo, porque no estoy seguro de por qué está teniendo tanto problema aquí. Todavía muestra uno rápido para que hagas eso. Oh, ahí vamos, solo necesitaba hacer commit, supongo. Entonces no creo que necesite hacer eso entonces. Volvamos a encontrar nuestras credenciales. Solo porque no recuerdo cuáles son. Y es stratified.com no parece que nuestras imágenes estén conectadas correctamente, así que voy a ejecutar esto. Veamos. Entonces debería ejecutar scripts seed. Hmm. Intentemos volver a subir estas imágenes tal vez. Ah, vale, solo necesito volver a subirlas. Aquí está todo el data que teníamos localmente y todos los tipos de colección que ahora estamos testing en este entorno PR1 asociado con esta solicitud de extracción. Entonces, si podemos actualizar este estado aquí, ha pasado nuestra verificación. Obviamente, podemos incluir muchas más pruebas que se realizan antes y en respuesta al sitio implementado. Por ejemplo, podríamos hacer una verificación como, ya sabes, ¿cuántos artículos tenemos en el punto final de los artículos, pero todo parece estar bien para lo que queremos probar aquí. Quiero fusionar esto en producción porque hemos hecho lo que queremos hacer aquí. Así que sigamos adelante y fusionemos esos cambios. Y ya no necesito esa rama. Y veremos que ahora estoy eliminando y desactivando ese entorno. Y si vuelvo a la vista del proyecto, ahora tengo un nuevo commit que se está empujando a la rama principal una vez que hayan terminado esos dos eventos de apagar ese entorno anterior. Y así podemos configurar esto en nuestro entorno de producción antes de pasar al siguiente paso de poner realmente un front-end frente a esto. Voy a.

Entonces logramos configurar esto. Tenemos los data como antes, pero probamos lo que necesitamos hacer aquí. Una cosa a tener en cuenta antes de hacer eso es si miramos esa actividad para ese push a la rama principal, veremos los tres commits, los dos regulares y los commits de fusión, y veremos esa misma línea de construcción de la aplicación que vimos antes.

Pero en realidad veremos esta línea, como mencioné antes. El propósito de esta configuración es definir claramente qué se debe hacer, qué variables deben estar presentes en el momento de la construcción y qué se hace después, como el comando de inicio y veremos el gancho de implementación en un segundo para crear una imagen de construcción. Y así, en ese entorno aislado para la solicitud de extracción, creamos una imagen de construcción con toda esta configuración. Y luego, cuando lo fusionamos, el estado de producción ahora está en ese estado único que previamente se había apartado en ese entorno de solicitud de extracción que está asociado con este hash. Y como no hay cambios y ya tenemos una imagen de construcción asociada con este valor que ahora está en producción, puedo reutilizar esa imagen de construcción.

Entonces, si echas un vistazo a nuestro sitio web o documentation, verás cosas que dirán desplegar el viernes. Esta es una razón por la que escribimos eso. Básicamente, si hago una revisión de mi sitio y lo promociono a producción, incluso un viernes, puedo sentirme bastante seguro de que nada se romperá porque ya he probado esta imagen de construcción en condiciones lo más cercanas posibles a las de producción, según nuestro flujo de trabajo. No vemos el mejor ejemplo de eso ahora porque necesitamos arreglar los data, pero como dije, descubrimos qué hacer aquí y esta imagen de construcción se reutiliza. Entonces. ¿Qué necesito hacer aquí? Necesito subir esas cosas nuevamente, puedo simplemente copiar esos pasos. Así que podemos volver a la sección de despliegue y deberíamos poder. Replicar esos, primero voy a hacer la database y ver si eso soluciona el problema de la imagen de antes. Así que ya debería estar en main, voy a. mover la database. Sí. Y luego quiero hacer lo mismo con mis imágenes. Hacer. Y vamos a desplegar esto para medir. Una vez hecho esto, vamos a. Ver cómo vamos y ver si necesitamos volver a ejecutarlo como lo hicimos en el entorno de PR.

Así que tenemos la API, tenemos nuestros sitios de producción y lo hacemos. Así que vamos a subir nuevamente la database. Creo que tenía un commit, así que hagamos algo simple. Agreguemos otra variable o rebuild es true y adelante y hagamos push. Rebuild commits solo para ayudar a nuestra migración aquí. Así que vamos a reconstruir eso y eso debería permitirnos recoger esos data migrados recientemente. Muy bien, genial. Ahora tenemos nuestros entornos de producción, um, y si tenemos todos nuestros data migrados, y verifiquemos rápidamente que no necesitemos volver a subir las imágenes como lo hicimos la última vez. Uh, lo haremos si es necesario. Uh, así que fue admin en strapi demo.com. Uh, y nuestros medios se ven bien. Bien. Ahora estamos completamente migrados. Así que tenemos un, um, plantilla ya. Hombre, difícil. Más difícil. Tenemos el repositorio en el que estamos trabajando. Acabamos de fusionar las solicitudes de extracción para migrar esta aplicación localmente a la plataforma. Aquí están nuestros entornos de producción. Um, solo tenemos un entorno visible ahora porque eliminamos ramas. No tenemos ninguna solicitud de extracción abierta en nuestra aplicación de producción. Tenemos esa API que configuramos inicialmente localmente. Um, okay. Um, okay. Creo que está tomando la URL incorrecta. Sí. Está tratando de ir conmigo. Uh, y lo tenemos aquí. Así que en nuestro sitio de producción podemos verificar qué artículos están disponibles. Podemos verificar qué restaurantes, todas las cosas que hicimos localmente ahora están en nuestro sitio de producción. Genial. Ahora queremos pasar a la siguiente parte, que no es tan genial, solo este front-end, uh, vamos a

Entonces, veremos que esto está codificado en base64. Entonces, si hago esta rápida plataforma roots, base64, decodificar y pasar por una herramienta incorporada llamada jq que está en el contenedor, puedo ver que la información sobre el entorno actual está disponible aquí. Para mi entorno de producción, podría obtener la ubicación de mi backend para que no solo pueda extraer de este backend para construir el frontend, sino hacer algo muy similar en múltiples entornos.

Entonces, si echas un vistazo dentro de. Si echas un vistazo dentro del subdirectorio del cliente que vino en el repositorio. Deberías ver un archivo que ya está allí, al igual que el backend llamado environment. Y lo que va a hacer es exactamente eso. Va a decir, define este valor de variable, lo siento, me estoy yendo pequeño por el momento, pero la siguiente URL de la API pública que estaba en este archivo de variable de entorno de desarrollo. Y lo hará en este archivo now.environment, que se carga en tiempo de ejecución para extraer de las rutas de la plataforma y hacer la misma decodificación en base64 y JQ. Y lo que vamos a buscar en ese objeto largo, algo con el ID API, que es posible que no hayas notado dentro de esta configuración de ruta CMO que está justo aquí en mi definición de ruta upstream.

Así que puedo tomar un momento aquí para probar esto. Así que adelante y copio este valor y lo pego aquí. Lo único que hace este archivo es lo mismo que hice antes, simplemente eliminar esa barra diagonal al final, básicamente. Pero en cualquier caso, con esta línea aquí en este archivo de entorno, puedo obtener la ubicación actual del backend. Así que tenemos eso. Tenemos un archivo de entorno para el frontend que acabamos de construir localmente. Y luego, también dentro de este subdirectorio del cliente, tengo un archivo de ignorar YAML que va a tomar el lugar de mi archivo platform.app.YAML, por lo que podemos renombrarlo como tal. Entonces, si echamos un vistazo como hicimos antes, ¿qué está haciendo esto? Ahora es un Next.js, es un contenedor Node, es un contenedor JavaScript que se llamará Next.js porque es un nombre único.

Quiero tener dos dependencias diferentes disponibles durante la compilación. Nuevamente, no quiero usar NPM, quiero usar yarn. Así que aquí está yarn, y también quiero usar PM2 como un tipo de administrador de procesos para las implementaciones. Cuando una aplicación se ha implementado y otra aún no se ha implementado, quiero poder recuperarme de manera bastante fluida cuando esta aplicación del frontend esté en ejecución. Así que vamos a usar PM2 para ejecutar este servidor del frontend. Esto aquí es una configuración que intenta manejar el hecho de que Nexus.js necesita bastante memoria cuando se está compilando. Y en realidad vamos a retrasar el momento en que se compila esta aplicación del frontend hasta un poco más adelante en el proceso de lo que normalmente haríamos. Así que no vamos a compilar Next en tiempo de compilación, en realidad lo vamos a compilar efectivamente en tiempo de ejecución porque estos contenedores de aplicaciones se implementan en paralelo a lo largo de esta canalización de compilación e implementación.

Todo lo que tengo que hacer, tengo un gancho de compilación que instala mis dependencias usando yarn. Y luego voy a retrasar mucho tiempo en un gancho de implementación posterior para compilar ese sitio del frontend. Y así aprovechará esa URL del backend que se define en el archivo de entorno. Y construirá ese sitio cuando sepamos con certeza que el backend ya se ha implementado y está en ejecución. Podemos echar un vistazo al comando de inicio de este sitio de Next en el que veremos que el nombre de la aplicación se extrae del archivo package JSON. Voy a usar PM2 para luego iniciar esa aplicación en otra variable de entorno integrada, PORT. Y justo antes de hacer todo eso, voy a hacer otra compilación de yarn. El comando de inicio se ejecuta después de la fase de compilación en el momento de la implementación, así que básicamente esto seguirá intentando compilar la aplicación hasta que el backend esté disponible. Y luego, igual que antes, NEXT requiere estos dos directorios, así que los haremos escribibles en tiempo de ejecución. PM2 también necesita algo almacenado para su almacenamiento en caché, así que los haremos escribibles en tiempo de ejecución. Y así se convierte en nuestra configuración para ejecutar el sitio del frontend junto con el backend. Se ejecutarán en un solo entorno. Lo único que queda por definir es esto aquí y podemos simplemente copiar esto. Así que tengo un conjunto de rutas configuradas para el backend. No necesito un ID. Quiero que esté en el dominio principal, en la raíz del dominio. Así que voy a eliminar esos subdominios. Y no quiero que apunte a Strapi, quiero que apunte a dex.js, que es el nombre que le dimos aquí. Y antes de hacer push, déjame revisar que no haya dejado nada aquí. No, no. De acuerdo, genial. Así que configuración de la aplicación, configuración de rutas y luego algo que nos permitirá extraer esa URL del backend. Entonces, Muy bien, volvemos y podemos crear una nueva solicitud de extracción para esa URL en particular. Muy bien, volvemos y podemos crear una nueva solicitud de extracción para ese cambio. Y podemos probar esta migración de agregar este nuevo frontend. Y deberíamos obtener un nuevo entorno donde veremos el mismo código de estado que vimos antes en la fusión para esa aplicación de backend Strapi. Entonces, en este caso, se descubrió el mismo hash para Strapi en el nodo 18. Así que se reutilizará toda esa imagen de compilación. Así que ya estamos empezando a construir una réplica exacta de esta API de producción en este espacio aislado simplemente creando la nueva solicitud de extracción. Entonces, este frontend se va a compilar. Y luego podemos jugar con asegurarnos de que la comunicación entre los dos funcione antes de promover esto a producción. Y luego, otra cosa a tener en cuenta aquí es de la misma manera que se detectó la imagen de compilación al crear el nuevo entorno de nuestra API de producción, lo mismo ocurre con todos los datos. Así que estoy creando un nuevo entorno. Tiene una imagen de compilación clonada. Pero también va a hacer una copia de seguridad de los datos que están actualmente en producción. Así que si recuerdas en este caso, ese es el base de datos SQLite dentro de .tmp y luego todas nuestras imágenes cargadas. Así que se tomará una instantánea de ellas. Y luego heredarán a este entorno para que podamos trabajar y probar este nuevo frontend. Y aquí veremos la compilación del frontend por primera vez. Muy bien. Parece que esto se compiló. Muy bien.

Y luego lo otro que queremos hacer es si abro esto rápidamente y creo que va a estar en este último, no, este, no este, supongo que ninguno de ellos. Necesitamos seleccionar complementos. Configurar complementos. También necesitamos otro archivo. Va a ser un archivo de configuración de API config plugins.js. Vamos a echarle un vistazo rápido. Y se verá así, que va a extraer esas variables de entorno del entorno y usar un proveedor llamado Node Mailer para configurar nuestro correo electrónico. Y lo incluyo aquí como algo interesante para explorar, porque si echamos un vistazo, bueno, vamos a verificar esto. Sí, nuestra migración a producción salió bien. Pero lo que estaba diciendo es que, si vamos a la configuración de nuestro proyecto, o lo siento, a la configuración de nuestro entorno para el entorno principal, los correos salientes están habilitados de forma predeterminada, lo cual tiene sentido, pero si empiezas a jugar con esto en un entorno de desarrollo, eso no es así, necesitas activarlo, así que eso es típicamente algo más que haremos en una masterclass como esta, activar esa bandera, configurar el correo con el proxy de SendGrid incorporado y comenzar a restablecer ese nombre de usuario y contraseña para las cuentas. Así que eso es uno, el otro que es potencialmente más interesante es que tenemos esta aplicación migrada a producción, aún no tenemos un dominio asociado a ella, pero está completamente migrada de lo que estábamos haciendo localmente antes, excepto que está utilizando SQLite como una database, lo cual obviamente no es totalmente ideal para nuestro sitio de producción. Pero si vas a nuestra documentation, verás una sección completa aquí sobre agregar servicios. Así que voy a seguir adelante y... Lo que puedo hacer es incluir también ese problema. Aquí está el enlace a esa parte de la documentation. Y de manera similar a la forma en que Platform se encarga de, no fue necesario que yo entendiera cómo armar un contenedor de Node 18, 14, 16 tanto como lo sería para mí armar un contenedor de Python 3.9, PHP 8.2. Lo mismo ocurre con los servicios. Así que si quisiera agregar un contenedor de producción de Oracle MySQL, Postgres, MariaDB a este clúster, no tengo que entender cómo armar ese contenedor. Puedo incluir, digamos, para hacer Postgres. Si quiero usar Postgres, agrego un archivo separado llamado services.yaml en ese directorio compartido. Y luego voy a hacer algo que se ve así. Así que voy a crear un nuevo servicio que es de alguna versión importante que es mantenido por Platform. Y luego le voy a dar a ese servicio un nombre. Así que este es su propio contenedor de servicio único que existe en el clúster. Y ese nombre, al igual que con la relación principal se replica aquí en la configuración de mi aplicación al definir una relación. Así que tengo variables de entorno en mi aplicación Strapi que dicen que quiero usar SQLites. Y la ubicación de SQLite está en este archivo .tmp. Pero en su lugar puedo incluir un archivo que se ve en mi paso cuatro. No estoy creando un nuevo problema aquí. Usar database de producción. Y esto estará nuevamente en API config database.js. Y se verá así. Así que nos permitirá aprovechar ese mismo comportamiento predeterminado de que por alguna razón, estamos ejecutando un servidor local y no nos importa mucho si SQL está bien. Aún lo hará si tenemos esa variable establecida, pero luego podemos configurar todas estas variables de entorno, que deberían tener un archivo .env correspondiente, que se ve así. Actualiza el entorno. Así que puedo hacer algo como decir, cliente de database como Postgres, y de la misma manera en que obtuve la ubicación de la URL actual del backend. Puedo aprovechar otra variable de entorno incorporada llamada platform relationships para obtener credenciales basadas en el nombre de servicio que definimos. Entonces, en la documentación, el ejemplo que mostré aquí fue que el database de Postgres era el nombre de una relación. Así que aquí sería que el nombre de la relación es simplemente database. Y así, a partir de esta línea aquí, obtengo una nueva variable de entorno para el nombre del host del puerto, nombre de usuario, contraseña. Eso extrae de esta relación de database esos valores para que sean accesibles para algo como este script para este archivo de configuración. Y a partir de aquí, simplemente puedo decir que quiero que mi tipo sea Postgres, tal vez no quiero que sea Postgres, pero quiero que sea Oracle MySQL MariaDB. Ahora tengo una forma de hacer eso. Y entonces la pregunta simplemente se convierte en, ¿queremos ahora construir todos nuestros nuevos data desde cero? ¿Queremos usar un convertidor para tomar lo que hemos configurado en SQL lite y ponerlo en la sintaxis correcta para migrarlo a MySQL o PostgreSQL? Eso sería el nuevo desafío a superar allí para un paso como ese. A menudo lo hacemos en una masterclass como esta. Así que voy a abrir ese problema también e incluirlo. Lo que probablemente haré es volver a vincular estos en el repositorio base pero estos son los que están en mi espacio de nombres para empezar. Muchas gracias por venir. Me quedaré un rato. Si tienes alguna pregunta o simplemente quieres charlar de lo contrario, espero que todos tengan un gran día. Gracias.