Consideramos qué es IaC (Infraestructura como Código) y por qué deberíamos invertir nuestro tiempo/dinero en ello. Será una charla estilo masterclass y al finalizar, tendrás una infraestructura completa como código para una aplicación React en AWS escrita en TypeScript
This talk has been presented at React Advanced Conference 2021, check out the latest edition of this React Conference.
FAQ
Denys Artyukhovic es el líder del equipo en The Zone, una empresa que transforma la manera en que los fanáticos se involucran con los deportes. Originalmente es de Bielorrusia y actualmente está basado en Londres.
The Zone está cambiando la forma en que los fanáticos se involucran con los deportes, desde la distribución de contenido hasta ofrecer experiencias inmersivas en tiempo real con datos aumentados para las transmisiones de video. Están disponibles en más de 200 países y en varios tipos de dispositivos.
La infraestructura como código es crucial para The Zone debido a la necesidad de manejar frecuentes cambios en la infraestructura, a veces varias veces al día, lo que sería muy estresante y propenso a errores si se hiciera manualmente.
Terraform es un software de código abierto desarrollado por HashiCorp que permite gestionar la infraestructura mediante código. The Zone lo utiliza para administrar su infraestructura de manera eficiente y soporta TypeScript a través de CDK (Cloud Development Kit).
Usar TypeScript en la infraestructura como código ofrece beneficios como evitar aprender un nuevo lenguaje, aprovechar la potencia y las características de TypeScript como autocompletado y tipos, y facilitar la estructuración y el mantenimiento del código.
The Zone utiliza Terraform para manejar los cambios en su infraestructura, lo que permite actualizar y modificar componentes de manera controlada y sistemática, reduciendo la posibilidad de errores y aumentando la eficiencia.
Esta charla cubre la infraestructura como código utilizando Terraform y CDK. El orador demuestra cómo construir la infraestructura para una aplicación React, incluyendo un bucket S3 y la conexión a un dominio real. También se discute la configuración del comportamiento de la caché, CloudFront y los backends remotos. TypeScript se destaca como un lenguaje poderoso para la infraestructura como código, y se enfatiza la importancia de la automatización y el código bien documentado para infraestructuras a escala global.
Vamos a hablar de infraestructura como código. Mi equipo en The Zone está cambiando la forma en que los fanáticos se involucran con los deportes. Tenemos una amplia gama de infraestructura. Para evitar errores manuales y garantizar la escalabilidad, necesitamos utilizar la infraestructura como código. Hay dos paradigmas de programación: imperativo y declarativo. Terraform, un software de código abierto, admite miles de proveedores y nos permite administrar la infraestructura con código, incluido TypeScript.
Genial. Sí, como dije, ahora vamos a hablar de infraestructura como código. Pero antes, permítanme presentarme y darles un poco de contexto sobre por qué lo necesitamos. ¿Qué está pasando? Genial. Mi nombre es Denys Artyukhovic. Soy el líder del equipo en The Zone. Originalmente, soy de Bielorrusia, pero ahora estoy basado en Londres. Y en The Zone, estamos cambiando todos los aspectos de cómo los fanáticos se involucran con los deportes, desde la distribución de contenido hasta una experiencia verdaderamente inmersiva en tiempo real donde puedes ver datos aumentados para las transmisiones de video. Estamos disponibles en más de 200 países y en varios tipos de dispositivos, incluidos televisores inteligentes, tabletas, computadoras portátiles y, por supuesto, Xbox, PS5 y otras consolas de juegos. Y creo que puedes imaginar la cantidad de infraestructura que tenemos. Y mi equipo ha construido características que son multiplataforma. Están disponibles en la web y en los televisores. Entonces, la respuesta ahora, probablemente sea obvia, pero consideremos el flujo normal de desarrollo de sus aplicaciones. Comenzamos con una característica, o digamos un servicio, luego una nueva y brillante idea llega al escenario y tenemos una característica más, y luego boom, cientos de ellas. Y en nuestro caso, podemos esperar cambios en nuestra infraestructura incluso varias veces al día, y creo que puedes imaginar lo estresante que podría ser si todo fuera manual, porque necesitas replicar algunos cambios manuales, ¿y qué pasa si algunos de los desarrolladores olvidan actualizar la documentación? ¿O qué pasa si la interfaz de usuario misma ha cambiado en nuestro proveedor de la nube, como AWS, y hacemos clic en la casilla de verificación incorrecta y Facebook no está disponible durante unas horas? Así que puede ser realmente estresante, ¿verdad? Para evitar esta situación y solucionar este problema y nunca tener un problema así, nuevamente, necesitamos aprovechar la infraestructura como código. Pero antes de comenzar a hablar sobre la infraestructura en sí, consideremos estos dos paradigmas de programación, ya que son bastante relevantes cuando hablamos de codificación para la infraestructura. Por un lado, tenemos el enfoque imperativo, que se basa en instrucciones explícitas para todo literalmente. Por lo general, nos referimos a algunos scripts de shell, y de hecho, la instrucción explícita es la mayor ventaja de este enfoque. Pero al mismo tiempo, es la mayor preocupación, porque debes mantener todo tú mismo y no es realmente escalable a lo largo del tiempo. Por otro lado, tenemos el enfoque declarativo, que se basa en describir el resultado y dejar que el proveedor haga el resto del trabajo, lo cual es mucho más fácil y mejor para escalar. Entonces, sí, nuevamente, con el enfoque imperativo, eres inteligente y siempre culpas al sistema de que no funciona como esperas, porque escribiste tantas líneas de código. Cuando con el enfoque declarativo, simplemente no te importa hasta que los proveedores inteligentes se encarguen de todo por ti. Y la buena noticia es que Terraform, en realidad, es un software de código abierto. ¿Quién ha trabajado con Terraform antes? Permítanme hacer esta pregunta primero. Sí. Ok. Algunas personas. Increíble. Entonces, Terraform es un software de código abierto que fue desarrollado originalmente por HashiCorp, y admite miles de proveedores diferentes, y nos permite administrar nuestra infraestructura con código, y lo que es más importante para hoy es que también admite TypeScript. O mejor dicho, CDK, que significa
2. Construyendo Infraestructura con Terraform y CDK
Short description:
Para implementar infraestructura, antes necesitabas aprender un nuevo lenguaje. El lenguaje de Terraform no es complejo y creo que es un cambio de juego. En los próximos 30 minutos, construiremos una infraestructura lista para producción para una aplicación de React, paso a paso. Comenzaremos creando carpetas e instalando CDK. Luego, usaremos React Create App para crear una aplicación básica de React con TypeScript. A continuación, inicializaremos el proyecto con CDK-TF, especificando una plantilla de TypeScript y un backend local. Si encuentras errores de TypeScript, agrega la bandera skip-loop check al archivo ts-config de Terraform.
El Kit de Desarrollo de la Nube, CDK, admite TypeScript. Y realmente creo que es un verdadero cambio de juego porque anteriormente, para implementar infraestructura, probablemente necesitabas aprender un nuevo lenguaje. Con el lenguaje de Terraform de HashiCorp, que no es malo, no es complejo, probablemente un poco más complejo que los archivos JSON o YAML, pero ya sabes, somos desarrolladores. Realmente me gusta el poder de los lenguajes de programación y he estado programando durante muchos años, y eso es con lo que me gustaría crear mi infraestructura, y sí, por eso creo que es un verdadero cambio de juego. Entonces, en los próximos 30 minutos, lo que vamos a hacer, quiero decir, probablemente un poco menos, vamos a construir la infraestructura lista para producción para nuestra aplicación de React, para ser honesto, incluso para cualquier aplicación de JS que elijas. Y sí, lo haremos paso a paso, será como una clase magistral, puedes seguir con las laptops, pero no te preocupes si necesitas tomarte tu tiempo, al final de la charla compartiré contigo todos los ejemplos de código y habrá un enlace al repositorio de GitHub para que puedas seguir más adelante, y estoy bastante seguro de que esta charla será grabada. Ok, así que podemos empezar. Entonces, déjame hacer esto porque es un poco extraño. Genial. ¿Puedes ver mi pantalla? Y solo un segundo, lo haré escalable para poder controlarlo. Ok, lo siento mucho. Acabo de desordenar las cosas. Pero todo bien ahora. Genial. Sí, el primer paso, lo que vamos a hacer, vamos a usar React Create. Espero que todos. Sí. Entonces vamos a usar React Create App solo para crear la aplicación básica de React con TypeScript y vamos a ejecutar este comando para hacerlo y después de esto tendremos esta aplicación bonita y brillante lista. Pero hasta ahora nada está relacionado con la infraestructura en sí. Ahora vamos a empezar creando algunas carpetas para nuestra infraestructura. Y como requisito previo, necesitamos instalar CDK. Puedes instalarlo a nivel global en tu máquina o puedes instalarlo por proyecto. Tú decides. Pero básicamente, tan pronto como tengamos CDK-TF, podemos crear una carpeta de proyecto y comenzar a configurar nuestra infraestructura. Para esto, voy a usar un comando que es CDK-TF init. Voy a pasar la plantilla como TypeScript, de manera similar a lo que hemos hecho para la aplicación de React, y voy a especificar un backend local. Si sabes lo que significa un backend local en términos de Terraform, genial. Si no, no te preocupes. Lo cubriremos un poco más adelante durante la charla. Después de la inicialización, es posible que veas errores relacionados con TypeScript y la razón de esto es porque estoy bastante seguro de que Terraform los abordará en breve, pero hasta ahora necesitas agregar skip-loop check porque realmente no espera que haya otro proyecto de TypeScript en el mismo proyecto. Tan pronto como agreguemos skip-loop check
3. Implementando Infraestructura con S3 Bucket
Short description:
Vamos a comenzar a implementar nuestra infraestructura utilizando el archivo main.ts. Más adelante, se puede refactorizar. Agregamos el proveedor de AWS a la configuración CDKTF.json y definimos nuestras necesidades de infraestructura. Lo primero que necesitamos es almacenamiento, específicamente un bucket de S3. Creamos el bucket con la configuración deseada, incluido el acceso de lectura público. Después de realizar los cambios necesarios, construimos y sintetizamos los cambios.
verifica la bandera check en el archivo ts-config de Terraform, todo estará bien. Y vamos a poder ver que hay un archivo TS que se genera para nosotros con el Stack Principal. Se llama main.ts. Y este archivo es básicamente lo que vamos a usar como punto de partida y donde comenzamos a implementar nuestra infraestructura. Por supuesto, porque es TypeScript, más adelante puedes crear, digamos, una carpeta de origen, estructurarla de la manera que prefieras, dividir todo en funciones reutilizables. Ahora lo haré todo en un solo archivo, pero más adelante se puede refactorizar de la manera que prefieras. Genial. Antes de comenzar, necesitamos agregar un proveedor de Terraform. Como dije, hay miles de proveedores disponibles para ti. Todos son de código abierto y puedes crear tu propio proveedor. Vamos a usar el proveedor de AWS, así que lo agregamos a la lista de proveedores en la configuración de CDKTF.json, y después de eso, estamos listos para continuar. Pero ahora necesitamos definir cómo se verá nuestra infraestructura, qué necesitamos realmente para nuestra aplicación frontend.
Y lo primero que podemos necesitar es almacenamiento, ¿verdad? Necesitamos almacenar nuestra aplicación en algún lugar. No sé cuántos de ustedes han trabajado con buckets de S3 en AWS, pero es solo un simple servicio de almacenamiento que tiene una gran disponibilidad, 99.99%, lo cual es genial, pero para nosotros, lo importante es que lo vamos a usar para almacenar nuestros activos estáticos, ¿de acuerdo? Entonces, para esto, podemos importar el proveedor de AWS y el bucket de S3. Esa va a ser una infraestructura simple que puedes imaginar, y es muy sencilla. Como va a estar lista para producción, más adelante planeo conectar un dominio real y por eso creo que podemos llamar al bucket con el nombre del dominio solo porque es más explícito. Vamos a crear un proveedor. Puedes usar cualquier región que prefieras. Yo voy a usar US-East-1. Solo un dato, para tu bucket, por ejemplo, puedes usar una región europea y EU Central-1, lo que sea. Eso está perfectamente bien, pero ACM, que vamos a usar para los certificados SSL más adelante, requiere la región US-East-1. No tiene nada que ver con cómo codificamos la infraestructura, solo está relacionado con cómo AWS opera. Ellos lo necesitan en sus requisitos. Si vas a crear otra región, simplemente crea la segunda más adelante para ACM. Genial. Estamos creando el bucket de S3, pasando solo el nombre del bucket, pasando el proveedor. Estamos diciendo que será un sitio web con index.html como documento raíz. También estamos especificando la lista de control de acceso como lectura pública, porque ¿a quién le importa la seguridad? Estoy bromeando, lo arreglaremos más adelante. Por ahora, déjalo como público. Tan pronto como hagas estos cambios, solo necesitas construirlos y ejecutar el comando YARN syns
4. Implementando una Aplicación React en un Bucket de S3
Short description:
Para implementar nuestra aplicación React en el bucket de S3, podemos usar Terraform o el comando AWS S3. Después de la implementación, el sitio estará disponible en la URL del bucket. Sin embargo, para que esté listo para producción, necesitamos conectarlo a un dominio real.
para sintetizar esos cambios. Después de esto, todo será transpilado. Se generará una carpeta CDKTF out en la que puedes ingresar y ejecutar comandos en el siguiente orden. Debes ejecutar Terraform init. Solo necesitas este comando la primera vez, porque estamos comenzando con Terraform. Después de esto, puedes ejecutar un plan. El plan es opcional. Es solo para ver qué se planea aplicar en nuestra infraestructura. Y después de eso, puedes ejecutar apply. Y si sigues estos pasos, verás una salida similar en tu terminal, que te dirá qué se creó. Lo verás en el sitio web y en el punto. Y ahora, podemos construir nuestra aplicación React con el comando Yarn build y implementar esta aplicación React en el bucket de S3. La implementación es un poco complicada. Puede ser manejada con Terraform cuando creas que está relacionada con tu infraestructura. Con el mundo del frontend, diría que no está estrechamente acoplada a la infraestructura porque vas a crear la infraestructura. No quieres esperar cambios en tu infraestructura todo el tiempo cuando estás actualizando la versión de React y agregando nuevas características. Por lo tanto, la implementación probablemente será separada en tu CI. Así que lo voy a hacer manualmente ahora usando el comando AWS S3. Estoy pasando la carpeta de salida que se ha construido y estoy pasando el nombre de mi bucket de S3 que acabo de usar. Y, nuevamente, estoy especificando ACL como lectura pública. Y después de esto, si lo descargas, podrás ver que tu sitio está disponible en esta URL, bucketname.s3. Amazon.AWS.com. Y también podemos comenzar a compartirlo con nuestros, no sé, amigos, QA, SPOs, lo que sea. Pero por supuesto, aún no está listo para producción, ¿verdad? Al menos necesitamos conectarlo con el dominio real. Entonces, sí, celebremos que hemos logrado algo.
5. Conectando al Dominio Real
Short description:
Para conectarnos al dominio real, utilizamos Route 53, el servicio DNS de AWS. Las solicitudes de los usuarios pasan a través de la infraestructura de AWS y son interceptadas por Route 53, que las redirige al bucket de S3. Especificamos la zona de Route 53, la creamos y creamos un registro para los subdominios, configurando nuestro bucket como un alias. Después de ejecutar el comando Terraform Apply y esperar la validación, todo estará creado. El dominio se redirigirá a nuestro bucket de S3, pero aún no es seguro y no está listo para producción. Para mejorar el rendimiento, utilizaremos CloudFront y ACM. CloudFront redirige a los usuarios desde Route 53 a la ubicación de borde más cercana, y ACM emite un certificado SSL asociado con nuestro dominio.
Primero, consideremos cómo conectarnos al dominio real. Para conectarnos, utilizaremos Route 53, que es el servicio DNS proporcionado por AWS. Ahora, nuestro flujo se verá así. Los usuarios que envían la solicitud pasan a través de la infraestructura de AWS, que es interceptada por Route 53, que redirige a los usuarios al bucket de S3. Para lograr esto, necesitaremos realizar algunos cambios. Especificaremos la zona de Route 53, la crearemos y utilizaremos nuestro dominio principal, ya que me gustaría crear la infraestructura para el subdominio. Crearé un registro para los subdominios y pasaré mi zona de alojamiento y la configuración de nuestro bucket como alias, lo que significa que todos los que accedan a este registro serán redirigidos al bucket. Nuevamente, ejecutamos los comandos de construcción, navegamos a la carpeta, planificamos y aplicamos. Ahora, si lo ejecutas, verás que, permíteme rebobinar esto, estoy un poco consciente del tiempo, verás que habrá un problema en el último paso. Veamos qué se ha creado en realidad. Vamos a la consola de AWS para Route 53 y veremos que se ha creado la zona de alojamiento y habrá incluso un registro, ¿entonces qué ha fallado? La cosa es que lo hice intencionalmente. Compré el dominio con un proveedor diferente porque creo que es un caso de uso común cuando tienes un dominio comprado en un proveedor diferente a AWS, y necesito conectarlos de alguna manera, así que para esto necesito copiar los servidores NS que ahora se generan en AWS y conectarlos a mi proveedor de dominio, ya que mi proveedor de dominio no tiene proveedores para Terraform, así que lo haré manualmente. Puedes hacerlo con Terraform también, pero sí, esto es algo que se hace una vez, así que mi proveedor de dominio está en Rusia, por eso ves la interfaz en ruso, pero tan pronto como lo conectemos, necesitamos esperar de 5 a 10 minutos hasta que se actualicen los NS y ahora ejecutamos el comando con Terraform Apply y esta vez veremos, permíteme rebobinar esto un poco, después de la validación que toma, no sé, unos minutos como máximo, veremos que todo se ha creado, sí, se ha creado un recurso, nada se ha destruido, nada ha cambiado, y ahora, si intentamos acceder a este dominio, veremos que se redirige a nuestro bucket de S3 y podemos ver nuestro sitio web, que nuevamente es realmente genial. Pero aún no es seguro y aún no está listo para producción, ya que estamos almacenando nuestro bucket de S3 en algún lugar de Estados Unidos, por lo que probablemente el tiempo de respuesta para nuestros clientes será lento, y necesitamos aprovechar todas las ubicaciones de borde, por lo que probablemente queramos utilizar un servicio CDN, también probablemente queramos utilizar HTTPS para conexiones seguras, así que hagamos estos cambios. Para estos cambios, utilizaremos CloudFront y ACM. CloudFront es un servicio CDN disponible en AWS. ACM, por otro lado, es el Administrador de Certificados. Para nosotros, es interesante porque emitirá un certificado SSL asociado con nuestro dominio. Bien, veamos ahora nuestro diagrama de infraestructura un poco más complejo. Ahora, el flujo será que el usuario comienza desde Route 53 y, en lugar de ir directamente al bucket de S3, será redirigido a la ubicación de borde más cercana. Y nuestro CloudFront será responsable de recuperar objetos para almacenar en caché solo en casos en que la caché se invalide o si es el primer intento de acceso y aún no se haya creado una caché. Genial, y ACM se utilizará para el certificado SSL. Creamos el certificado ACM de la siguiente manera. Utilizamos el proveedor ACM. Nuevamente, pasamos la configuración especificando un comodín para nuestro dominio principal, ya que me gustaría usarlo para todos los subdominios en el futuro, no solo para uno. Por eso hay este signo de asterisco. Crearé el registro de validación del certificado. Es solo un registro más para nuestro dominio que se utilizará para la validación. Y crearé la validación en sí, pasando el certificado ACM y el registro de validación del certificado. Entonces, nuevamente, necesitamos crear la distribución de CloudFront. Y por favor, no
6. Configurando el Comportamiento de la Caché y Corrigiendo ACL
Short description:
No los entiendo completamente. Es solo la forma final de configuración de nuestro estado que estamos tratando de lograr. Vamos a cubrir los métodos get, head y options para el comportamiento de la caché. Pasaremos nuestro certificado SSL y haremos el cambio final en Route 53. Ahora, nuestro sitio se carga más rápido y es más seguro. Necesitamos corregir nuestra ACL de lectura pública utilizando una identidad de acceso de origen. Este es el diagrama de infraestructura final listo para producción.
No te asustes si ves y piensas que hay muchas líneas de código. No los entiendo completamente. En realidad, son líneas muy sencillas cuando sabes cómo funciona AWS. Pero si trabajas con un proveedor de nube diferente, los aprenderás desde allí. Si no los conoces, no te preocupes. Solo ve a su sitio web del proveedor de Terraform y lee y comprende lo que representan. Pero es solo la forma final de configuración de nuestro estado que estamos tratando de lograr. Entonces, básicamente, aquí estoy especificando que el comportamiento de caché predeterminado será redirigir a HTTPS. Vamos a cubrir los métodos get, head y options porque no creo que necesitemos ningún método postal u otros para nuestro frontend. Vamos a establecer el TTL predeterminado como un día y no voy a especificar ninguna restricción o ningún orden para el comportamiento de la caché. Pero si quieres especificar un orden de comportamiento de caché, son excepciones. Por ejemplo, una carpeta específica que deseas cachear solo durante cinco minutos o como no deseas cachear el índice html en absoluto. Puedes especificarlo en el orden de comportamiento de caché, eso es lo que representa. Entonces, vamos a pasar nuestro certificado SSL, que acabamos de emitir con el certificado ACM. Y ahora, necesitamos hacer el cambio final en Route 53. En lugar de nuestro nombre de bucket, vamos a pasar el nombre de dominio de la distribución de CloudFront. Entonces, Route 53 no redirigirá al bucket de S3. Ahora, se redirigirá a la distribución de CloudFront y solo estamos cambiando el nombre y la zona alojada. Necesitamos ejecutar nuevamente yarn build, yarn scenes, ir a la carpeta CDK TF out, ejecutar plan y apply. Y después de que se complete la aplicación, veremos que ahora tenemos una conexión segura, pero además, nuestro sitio se carga más rápido. Y la razón de esto es porque ahora está disponible en todas las ubicaciones de borde. Así que hemos cubierto el CDN aquí. Y eso es muy genial. Pero recuerda, como dije al principio, ¿a quién le importa la seguridad? Ahora es el momento de pagar por ello. Y ahora es el momento de configurarlo. Entonces, ahora necesitamos corregir nuestra ACL de lectura pública. Y vamos a usar una identidad de acceso de origen para ello. Entonces, nuestro diagrama de infraestructura será un poco más complejo. Pero este es el final.
7. Configurando CloudFront y Backends Remotos
Short description:
Vamos a tener a Route 53 dirigiendo a ubicaciones de borde previamente. Ahora, vamos a tener CloudFront que va a recuperar objetos para caché. Pero lo que va a cambiar es que en esta ocasión, el bucket de S3 va a tener algunas políticas de bucket específicas asociadas. Y esta política de bucket específica va a verificar que solo las identidades de acceso de origen específicas puedan acceder a ella. Entonces, en este caso, nuestro CloudFront debe tener una identidad de acceso de origen asociada para acceder al bucket de S3. Y, por supuesto, después de este cambio, nuestro bucket no estará disponible públicamente. Para lograr esto, vamos a cambiar el ACL del bucket a privado, crear una identidad de acceso de origen, especificar el documento de política, crear la política del bucket y asociarla con el certificado ACM. Luego podemos eliminar todo del bucket y volver a implementarlo, utilizando el ACL privado predeterminado. El dominio de S3 ya no estará disponible, pero CloudFront y Route 53 funcionarán como se espera. Finalmente, hablemos de los backends remotos. Terraform tiene un concepto de backends, que se utilizan para almacenar el estado de salida. Hay varias opciones de backends, pero dado que estamos utilizando AWS, tiene sentido crear un backend de S3. Necesitamos especificar un bucket, una clave y una región. Una vez que hayamos hecho esto, podemos ejecutar init y elegir copiar el estado existente al backend remoto.
Uno. Este es el último listo para producción. Vamos a tener a Route 53 dirigiendo a ubicaciones de borde previamente. Ahora, vamos a tener CloudFront que va a recuperar objetos para caché. Pero lo que va a cambiar es que en esta ocasión, el bucket de S3 va a tener algunas políticas de bucket específicas asociadas. Y esta política de bucket específica va a verificar que solo las identidades de acceso de origen específicas puedan acceder a ella. ¿De acuerdo? Entonces, en este caso, nuestro CloudFront debe tener una identidad de acceso de origen asociada para acceder al bucket de S3. Y, por supuesto, después de este cambio, nuestro bucket no estará disponible públicamente. Genial. Entonces, para lograr esto, lo que necesitamos hacer es cambiar el ACL del bucket a privado. Vamos a crear una identidad de acceso de origen. Y después de esto, vamos a especificar el documento de política. Nuevamente, es solo la configuración que AWS quiere que pongamos. Aquí estoy diciendo que queremos tener acceso a los objetos y que vamos a tener acceso para obtener la lista de estos objetos. Y así de simple, luego creamos la política del bucket, pasando el ID del bucket y el documento de política en sí. Y asociándolo con el certificado ACM, esta identidad de acceso de origen para que nuestro CloudFront lo tenga. Ahora, por razones de simplicidad, la opción más simple es simplemente eliminar todo lo que hemos puesto en nuestro bucket y volver a implementarlo, sin especificar el ACL, y usar el predeterminado que será privado. Y tan pronto como lo hayamos hecho, podemos comprobar que el dominio de S3 ya no está disponible. Vamos a ver esta brillante página de error proporcionada por AWS por defecto, que dice que se denegó el acceso. Mientras tanto, CloudFront y Route 53, por otro lado, funcionarán perfectamente bien y eso es exactamente lo que estábamos tratando de lograr. Y déjame felicitarte, si estás sudando ahora como yo, te prometo que no hay más cosas relacionadas con la infraestructura que necesitamos codificar, pero hablemos de un par de ellas. Estamos cerca del final de esta presentación, pero aún quiero cubrir los backends remotos porque hasta ahora todo lo que hemos hecho lo hemos hecho en una máquina y localmente, y no funcionará si empezamos a compartirlo con nuestros compañeros de equipo. Entonces, puedes pensar que probablemente podemos subir nuestro estado de Terraform, el estado de Terraform, no sé, tal vez incluso a GitHub, pero es una mala idea, te lo prometo, porque se almacenarán información confidencial, y para esto, Terraform tiene un concepto de backends y esos backends, en realidad, hay muchos de ellos. Puedes usar diferentes bases de datos, por ejemplo, DynamoDB, puedes usar almacenamiento S3, puedes usar el almacenamiento de Terraform, no recuerdo cómo se llama, pero hay muchas opciones. Creo que, dado que nos quedamos con AWS, tiene sentido crear nuestro backend en AWS también, y creo que esto es algo bueno de hacer, y perdón, para aclarar, el backend es solo nuestro estado de salida. Básicamente, es un archivo JSON que proporciona información sobre qué recursos se han creado y cuál es el estado actual de nuestra infraestructura. Entonces, vamos a crear un backend de S3. Para esto, necesitamos pasar un bucket. Este es en realidad un bucket separado creado manualmente, por lo que puedes pasar cualquier bucket. Por lo general, en las empresas tienes algunos buckets privados que no están disponibles en ningún otro lugar. Y sí, vamos a pasar una clave, que es el nombre de nuestro archivo, y vamos a pasar una región, que puede ser cualquier región. Una vez que lo hayamos hecho, necesitamos ejecutar init, y esta vez, cuando lo ejecutes en tu terminal, verás que te pregunta si quieres
QnA
TypeScript y Infraestructura como Código
Short description:
TypeScript es más poderoso que el lenguaje de configuración de hash core, proporcionando autocompletado, tipos y otras ventajas. Permite una mejor estructuración y compartición de código, lo que lo hace relevante tanto para desarrolladores frontend como backend. También se puede gestionar la infraestructura de herramientas de monitoreo como New Relic y Sentry con Terraform. Ten en cuenta que, aunque Terraform está maduro, CDK aún está en beta. Los ejemplos de código y recursos adicionales están disponibles en los repositorios proporcionados.
Vamos a copiar el estado existente para eliminar el backend. Y si tu respuesta es sí, todo lo que se copie se transferirá al bucket de S3 y se eliminará de tu máquina local. Genial, ahora hablemos de por qué usamos TypeScript. ¿Por qué usamos TypeScript para la infraestructura como código? Creo que es genial que no haya un nuevo lenguaje que aprender, a pesar de que el lenguaje de configuración de hash core que mencioné anteriormente no es tan malo, pero la mayoría de nosotros conocemos TypeScript y no necesitamos agregar nada más. Además, TypeScript es sin duda mucho más poderoso que el lenguaje de configuración de hash core. Tenemos autocompletado, tenemos tipos, tenemos todas las ventajas de un lenguaje maduro. Puedes pensar en los métodos que tienes para mapas, reducciones, ciclos, estructuración con diferentes modelos. No puedes lograrlo realmente con el lenguaje de configuración de hash core. Necesitas almacenar todo en una carpeta y no hay una conexión clara de qué está referenciado a qué, y en mi opinión, es un completo desorden. Pero ahora tenemos más opciones para la estructuración del código y nuevas formas de compartir, y aquí estoy hablando de que antes podíamos crear módulos o complementos de Terraform por separado, pero eran cosas completas y estaban completamente separadas del frontend. Ahora podemos usar NPM y compartir nuestro código con NPM, e incluso podemos implementar pruebas para nuestra infraestructura también. Además, quiero destacar, porque es muy importante, que intenté que esta charla se centrara en los desarrolladores frontend, porque veo que muchos desarrolladores backend conocen el concepto de infraestructura como código cuando no es exactamente así en el mundo frontend. Pero creo que es bastante relevante para ambos mundos, no solo para crear la infraestructura de tu propia aplicación, sino también para la infraestructura de tu monitoreo. Por ejemplo, tienes New Relic y quieres especificar algunas alertas o crear paneles de control, o digamos que tienes Sentry para este propósito. Nuevamente, todo se puede gestionar y, en mi opinión, debería gestionarse con proveedores de infraestructura como código, en este caso, Terraform. Por lo tanto, puedes manejar la gestión de incidentes con pager duty y nuevamente crear la infraestructura para esto con Terraform. Solo un comentario aparte, Terraform en sí mismo ya se utiliza ampliamente en producción en todo el mundo, pero CDK aún no. Actualmente está en fase beta, por lo que puedes esperar algunos cambios en CDK, así que ten cuidado con eso, y sí, no sería justo no mencionarlo. Y ahora, como prometí, todos los ejemplos de código están disponibles en este repositorio que puedes ver en la diapositiva. Intenté seguir la historia de Comet durante la charla, para que puedas seguir esta charla. Y muchas gracias, eso es todo, y hay otro repositorio, Terraform TypeScript Frontend Infrastructure, que tiene una estructuración ligeramente más avanzada y un poco más de ejemplos, así que si estás interesado, también puedes echarle un vistazo. Y ahora creo que tenemos una sesión de preguntas y respuestas si todavía hay tiempo, ¿verdad? De nada. Gracias. Sí. Bueno, toma asiento, ahora podemos relajarnos. ¿Te gustaría algo de beber? Oh, no, estoy bien. Aplaudiré para la audiencia remota, probablemente estén aplaudiendo en casa, y... gritando a su pantalla, suena un poco negativo, pero de manera positiva. Así que quiero pasar a las preguntas, y como recordatorio, aún puedes hacer preguntas si estás aquí, también estoy usando Slido, y al final Denise seleccionará la mejor pregunta y le daremos una camiseta de React Advanced al ganador. La primera pregunta es de Bruno Palino, la infraestructura de sitios estáticos es increíble, pero ¿qué pasa cuando necesitas servidores reales e implementaciones de aplicaciones con bases de datos, puedes manejar todo esto con Terraform? Sí, absolutamente, quiero decir, para eso está Terraform, para manejar todo esto, incluidas las bases de datos, incluyendo la infraestructura variada que puedas imaginar para tus microservicios o aplicaciones monolíticas o lo que sea, así que creo que es bastante popular entre todos los ingenieros de DevOps y backend y lo usamos bastante extensamente. Genial, okay, la siguiente pregunta es de Anónimo, así que Anónimo no recibirá una camiseta, podemos, oh, esto es incorrecto, esto no debería estar aquí, estoy leyendo las preguntas en voz alta, eso no debería ser preguntas.
Discusión sobre Infraestructura y Escala Global
Short description:
La mayoría de nuestras infraestructuras en Dazone se crean con Terraform, pero usamos Azure Corp Configuration Language en lugar de TypeScript. Somos una empresa global con millones de clientes, por lo que la automatización y el código bien documentado son cruciales para nosotros.
Entonces, ¿todo lo que nos mostraste son cosas que también usas en Dazone? Sí, claro, en realidad, la mayoría de nuestras infraestructuras se crean por supuesto con Terraform, pero usamos Azure Corp Configuration Language en lugar de TypeScript, estamos comenzando a adoptar TypeScript, pero como dije, todavía está en fase beta, por lo que debes tener cuidado con esto y debes tener en cuenta las preocupaciones relacionadas con la mantenibilidad si hay cambios significativos relacionados con ello, así que debería ser una llamada de atención.
Eres una empresa global y cualquier cambio es un gran cambio, supongo que es realmente difícil probar cosas a tu escala. Sí, absolutamente, quiero decir, estamos disponibles para millones de clientes en todo el mundo, por lo que para nosotros es cada vez más crucial automatizar todo lo que podamos y documentarlo bien con código, así que pongámoslo así.
Bien, como no tenemos más preguntas en este momento, creo que terminaremos la sesión de preguntas y respuestas o actualizaré si ha habido alguna pregunta en el ínterin. Si recibo algún data. Disculpen a todos los que estaban en línea y tuvieron problemas de audio, no fue desde mi computadora portátil, algo sucedió. Sí, se solucionó en los primeros minutos. Mi data es realmente mala aquí en Londres. Y necesito moderar las preguntas antes de que aparezcan allí y allá. Oh, no te preocupes. Y no tengo data. Pero, sí, Deniz, muchas gracias. Y pasaremos al siguiente ponente entonces. Sí, muchas gracias. Así que todos, un aplauso más para Deniz.
NPM workspaces help manage multiple nested packages within a single top-level package, improving since the release of NPM CLI 7.0. You can easily add dependencies to workspaces and handle duplications. Running scripts and orchestration in a monorepo is made easier with NPM workspaces. The npm pkg command is useful for setting and retrieving keys and values from package.json files. NPM workspaces offer benefits compared to Lerna and future plans include better workspace linking and adding missing features.
Today's Talk focuses on React's best types and JSX. It covers the types of JSX and React components, including React.fc and React.reactnode. The discussion also explores JSX intrinsic elements and react.component props, highlighting their differences and use cases. The Talk concludes with insights on using React.componentType and passing components, as well as utilizing the react.element ref type for external libraries like React-Select.
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
DevOps is a journey that varies for each company, and remote work makes transformation challenging. Pull requests can be frustrating and slow, but success stories like Mateo Colia's company show the benefits of deploying every day. Challenges with tools and vulnerabilities require careful consideration and prioritization. Investing in documentation and people is important for efficient workflows and team growth. Trust is more important than excessive control when deploying to production.
Daniel Rowe discusses building a TypeScript-first framework at TypeScript Congress and shares his involvement in various projects. Nuxt is a progressive framework built on Vue.js, aiming to reduce friction and distraction for developers. It leverages TypeScript for inference and aims to be the source of truth for projects. Nuxt provides type safety and extensibility through integration with TypeScript. Migrating to TypeScript offers long-term maintenance benefits and can uncover hidden bugs. Nuxt focuses on improving existing tools and finds inspiration in frameworks like TRPC.
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.
¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.
¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
TypeScript no es solo tipos e interfaces. Únete a esta masterclass para dominar características más avanzadas de TypeScript que harán tu código a prueba de balas. Cubriremos tipos condicionales y notación de inferencia, cadenas de plantillas y cómo mapear sobre tipos de unión y propiedades de objetos/arrays. Cada tema se demostrará en una aplicación de muestra que se escribió con tipos básicos o sin tipos en absoluto y juntos mejoraremos el código para que te familiarices más con cada característica y puedas llevar este nuevo conocimiento directamente a tus proyectos. Aprenderás:- - ¿Qué son los tipos condicionales y la notación de inferencia?- ¿Qué son las cadenas de plantillas?- Cómo mapear sobre tipos de unión y propiedades de objetos/arrays.
TypeScript tiene un sistema de tipos poderoso con todo tipo de características sofisticadas para representar estados de JavaScript salvajes y extravagantes. Pero la sintaxis para hacerlo no siempre es sencilla, y los mensajes de error no siempre son precisos al decirte qué está mal. Vamos a profundizar en cómo funcionan muchas de las características más poderosas de TypeScript, qué tipos de problemas del mundo real resuelven, y cómo dominar el sistema de tipos para que puedas escribir código TypeScript verdaderamente excelente.
¿Eres un desarrollador de React tratando de obtener los máximos beneficios de TypeScript? Entonces esta es la masterclass para ti.En esta masterclass interactiva, comenzaremos desde lo básico y examinaremos los pros y contras de las diferentes formas en que puedes declarar componentes de React usando TypeScript. Después de eso, pasaremos a conceptos más avanzados donde iremos más allá de la configuración estricta de TypeScript. Aprenderás cuándo usar tipos como any, unknown y never. Exploraremos el uso de predicados de tipo, guardias y comprobación exhaustiva. Aprenderás sobre los tipos mapeados incorporados, así como cómo crear tus propias utilidades de mapa de tipo nuevo. Y comenzaremos a programar en el sistema de tipos de TypeScript usando tipos condicionales e inferencia de tipos.
I'll introduce the audience to a concept where they can have end-to-end type systems that helps ensure typesafety across the teams Such a system not only improves communication between teams but also helps teams collaborate effectively and ship way faster than they used to before. By having a custom type system, teams can also identify the errors and modify the API contracts on their IDE, which contributes to a better Developer Experience. The workshop would primarily leverage TS to showcase the concept and use tools like OpenAPI to generate the typesystem on the client side.
Imagine developing where frontend and backend sing in harmony, types dance in perfect sync, and errors become a distant memory. That's the magic of TypeScript Nirvana! Join me on a journey to unveil the secrets of unified type definitions, the key to unlocking frictionless development. We'll dive into: - Shared language, shared love: Define types once, share them everywhere. Consistency becomes your BFF, errors your worst nightmare (one you'll rarely see).- Effortless coding: Ditch the manual grind of type checking. TypeScript's got your back, freeing you to focus on building awesomeness.- Maintainability magic: With crystal-clear types guiding your code, maintaining it becomes a walk in the park. More time innovating, less time debugging.- Security fortress: TypeScript's type system shields your app from common vulnerabilities, making it a fortress against security threats.
DevOps.js Conf 2022
React Day Berlin 2023
React Advanced Conference 2022
TypeScript Congress 2023
React Summit US 2023
Node Congress 2024
React Summit 2024
JSNation 2024
Comments