El Amanecer de una Nueva Era para React Fullstack

Ahora, hay dos avances, los llamaré así, en mi opinión, que React trajo. Uno es que facilitó la construcción y el mantenimiento de interfaces de usuario complejas. Y proporcionó una nueva forma de pensar y construir interfaces de usuario que era totalmente nueva en comparación con todo lo que había existido antes. Y otra invención realmente agradable aquí fue el modelo de componentes declarativo. Y así, ya no era necesario usar jQuery para actualizar quirúrgicamente el DOM y todos los lugares que necesitaba cambiar. Así que avancemos un par de años hasta 2015. Ahora, un evento significativo en este año fue que React lanzó el soporte de clases ESX. Hasta este momento, estabas usando React.createClass para crear todos tus componentes. Si no sabes de qué estoy hablando, busca en Google React.createClass y echa un vistazo a algunos fragmentos de código y se ve bastante gracioso. Totalmente diferente a lo que estamos acostumbrados hoy en día. Y hay estas cosas llamadas mixins y todo tipo de cosas locas que, sí. Así que esto fue importante. Y, por supuesto, hemos avanzado más allá de eso en este momento, pero esto fue importante en 2015. Ahora hay otra cosa que fue muy significativa en 2015. Esa fue la introducción de GraphQL por parte de Facebook. Ahora esto es en un momento en el que las aplicaciones de una sola página están comenzando realmente. Y ahora tienes backends separados y frontends separados, y los equipos están empezando Y esta capa de API se está convirtiendo en una pieza muy crucial de la infraestructura de tu aplicación. Y, por supuesto, las personas se encuentran con limitaciones en las API REST, y GraphQL fue una respuesta a eso.

Esto estaba enfocando en esta pieza importante y buscando optimizarla y hacerla mejor y hacer que los desarrolladores sean más productivos. Muy bien. Sigamos adelante al siguiente año, 2016. Este fue un gran año. Porque dos cosas muy importantes fueron lanzadas este año, Create React App y Next.js, en cuestión de meses uno del otro. ¿No es eso increíble? Mirando hacia atrás, parece que uno vino antes que el otro, pero ambos fueron lanzados alrededor del mismo tiempo. Pero se enfocaron en dos cosas diferentes, ¿verdad? Entonces, Create React App se enfocó realmente en la aplicación de una sola página estática. Y, pero Next.js se optimizó para el renderizado del lado del servidor. Y no tenía ninguna optimización estática ni ninguna página estática. Si mi memoria es correcta. Pero esto fue muy importante porque trajo un par de avances. El número uno es que abstraía la configuración de webpack para ti. Ya no tenías que crear tu propia configuración de webpack desde cero. O usar un boilerplate donde tenías esta enorme configuración de webpack dentro de tu proyecto que era aterrador de ver. Y además, Next.js abstraía el enrutamiento y el empaquetado por página. Así que esto fue muy importante para la productividad del desarrollador. Ya no tenías que configurar el enrutador y descubrir qué enrutador usar y cosas así.

Ahora, hubo otra cosa que sucedió en 2016 que creo que vale la pena mencionar en este contexto de construir aplicaciones full stack. Y eso es la introducción de las plataformas de GraphQL backend as a service. Graphcool fue una de las más destacadas que fue creada por la empresa que ahora es Prisma. Y luego, también en 2018, avanzando un par de años, pero en la misma categoría está Hasura. Y esto fue alrededor del mismo tiempo en que Graphcool estaba siendo cerrado. Hasura comenzó. Y ambos son proveedores de GraphQL backend as a service. Y el avance que trajeron es que facilitaron mucho la creación de una backend base de datos y una API de GraphQL. Ahora recuerda, especialmente desde que Graphcool fue lanzado en 2016, GraphQL tenía solo un año de antigüedad. Y aún estaba en sus primeras etapas y aún estaba descubriendo cómo hacer todas estas cosas. Pero realmente impulsaron la productividad inicial. Pero la desventaja es que estás atado a un servicio de terceros. Incluso si lo alojas tú mismo, estás un poco limitado a esa implementación. Y es muy difícil personalizar o cambiar los resolvers e implementación. Pero hay una idea aquí que es realmente poderosa. Y es la capacidad de poner en marcha tu backend rápidamente, sin tener que saber mucho sobre cómo hacerlo.

Bien, pasemos a 2019. A principios de 2019, se lanzaron oficialmente los React hooks en una versión estable de React. Así que este fue un gran año. Esto fue cuando, bueno, muchas personas ya habían estado utilizando hooks en las versiones alfa, pero este fue el momento en que los usuarios más cautelosos pudieron decir: sí, ahora está listo para producción, comencemos a usar los hooks. Y esto realmente cambió la forma en que escribimos aplicaciones de React.

Hoy en día, dos años después, los hooks son una parte fundamental de casi todos nuestros flujos de trabajo diarios. Lo segundo en 2019 que fue muy significativo fue la introducción de las rutas de API en Next.js. Antes de esto, Next.js solo manejaba páginas. Pero en 2019, alrededor de junio, agregaron las rutas de API. Esto es muy significativo en el contexto de construir aplicaciones full stack de React. Porque ahora, por primera vez, podías tener un solo servidor que sirviera tus componentes de React y tus rutas de API en un paquete integrado realmente agradable.

Fue en el otoño de la conferencia React Rally cuando recuerdo haber escuchado a alguien que estaba... Ahora estaban utilizando Next.js para todas sus aplicaciones. Y fue como una idea progresiva. Pero pensé, wow. Como que hay algo en esto. Y hubo personas que lo vieron desde el principio, que Next.js iba a ser clave para construir aplicaciones full stack.

Ahora llegamos a 2020. Y a principios de 2020, la perspectiva para los desarrolladores de React full stack era muy sombría. Han pasado siete años desde que se lanzó React y todavía no tenemos nada remotamente comparable a Rails o Laravel. Al comenzar un nuevo proyecto, tienes un millón de decisiones que tomar. Pero incluso con todas las opciones, ninguna parece realmente genial y en parte porque son difíciles de hacer que funcionen juntas y hay una parte de los desarrolladores de React que están abandonando React por completo y volviendo a las aplicaciones tradicionales de Ruby on Rails con renderizado del lado del servidor porque son más rápidas en eso debido a la complejidad de las aplicaciones de React y la capa de API y hacer que todo funcione correctamente.

Pero luego llega el 17 de febrero de 2020. Y un desconocido llamado Brandon Bear anuncia un nuevo y revolucionario framework full stack para React llamado Blitz.js. Los desarrolladores de React de todo el mundo se emocionaron mucho porque finalmente habría una solución para sus problemas full stack. Y Blitz trajo una serie de avances. En primer lugar, el hecho de que ahora había un framework completo, como Rails o Laravel para React. Esto fue increíble. Fue muy emocionante. Y en segundo lugar, Blitz trajo una capa de datos de API cero que abstrae la API en un paso de compilación.

Esto nos devolvió a una experiencia de desarrollo similar a la del enfoque tradicional de Rails renderizado en el lado del servidor. Porque, con el flujo de trabajo tradicional de Rails, no hay una API, por lo que es muy simple y rápido de desarrollar, porque no tienes esa pieza adicional de architecture en tu aplicación.

Y eso es lo que Blitz aporta a React. Brinda esa misma experiencia de desarrollo súper rápida a las aplicaciones de React porque no tienes que lidiar o pensar en REST o GraphQL. Simplemente abstrae todo eso. Y esto es un impulso masivo para la productividad.

Además, Blitz se basa en Next.js, el framework muy querido en este momento que es un framework híbrido y puedes hacer muchas cosas con él, pero aún es bastante minimal y lo que te ofrece de serie. Y al hacer esto, Blitz crea efectivamente una distribución personalizada de Next.js, similar a una distribución de Linux.

Pero sorpresa, solo un mes después, el 20 de marzo, hay otro gran anuncio sobre Redwood.js, otro framework full-stack para React. Y Redwood busca resolver los mismos problemas que Blitz, pero adopta un enfoque totalmente diferente. En lugar de abstraer la API como lo hace Blitz, Redwood la conserva y busca optimizar con una capa de GraphQL y una integración muy buena entre el front-end y el back-end.

Y los avances, en mi opinión, para Redwood, es que te brinda una experiencia de desarrollo similar a la de GraphQL o Hasura, pero donde tienes la capacidad de personalizar el código porque tienes propiedad sobre el stack. No hay dependencia de un servicio de terceros. Y esto realmente, creo, es una versión refinada de esa idea de GraphQL y Hasura, pero en un paquete mucho mejor y un framework en este nivel de abstracción.

Y en segundo lugar, Redwood brinda una experiencia de desarrollo monolítica similar a Blitz, pero con Redwood, es una implementación monolítica opcional. Por lo tanto, puedes implementarlos juntos como un monolito, o puedes implementarlos en lugares totalmente separados si así lo deseas. Y así, de repente, en aproximadamente un mes, nos lanzamos a una nueva era para el full stack de react. Fue un momento muy emocionante.

Entonces retrocedamos, echemos un vistazo a Blitz y Redwood, y veamos cuáles son las similitudes y tratemos de entender hacia dónde vamos con el full stack de react. En primer lugar, ambos son full stack de JavaScript y TypeScript. Y así, ya no tienes un lenguaje separado en tu servidor y en tu front-end. Y este es un punto muy importante para mí personalmente, y muchos otros también lo saben, que te ralentizas mucho al tener, por ejemplo, Ruby en el back-end y luego JavaScript en el front-end. Y además, tienes el problema de la tipificación. con TypeScript de pila completa, puedes compartir código y tipos de extremo a extremo y obtener seguridad de tipos de extremo a extremo. Esto es increíble. Y es difícil. El beneficio que aporta a tu productividad y depuración y todo eso es difícil de exagerar.

En segundo lugar, ambos son frameworks incluidos en las baterías como Rails y Laravel. Y esto es increíble. Has tenido cosas similares en el mundo de JavaScript, pero no para React.

La mayoría de ellos se renderizan en el lado del servidor. Y así sigue siendo JavaScript de pila completa, pero no era un framework incluido en las baterías con React. Y eso es lo que Blitz y Redwood aportan.

En tercer lugar, ambos brindan una experiencia de desarrollo monolítica. Esto te permite desarrollar tu aplicación como una cosa cohesiva, y es mucho más simple de entender.

En cuarto lugar, ambos son opinionados, en diversos grados. Y esto es realmente bueno porque te brinda un conjunto de convenciones, configuraciones, patrones e ideas predeterminadas. Es como decir, deberías hacerlo de esta manera. Y si no sabes qué hacer, entonces, ya sabes, sigue esa opinión. Por supuesto, puedes cambiar y puedes ir en contra de las opiniones. Es bastante fácil en ambos casos, pero te brinda un buen punto de partida.

Y por último, ambos buscan optimizar la productividad de pila completa. Hasta ahora, la mayoría de las cosas se han centrado en optimizar el frontend o solo el backend, pero no ambos juntos. Y este es un problema realmente difícil de resolver. Pero es un problema que vale la pena resolver.

Entonces, ¿qué esperamos? ¿Qué creo que viene para Full Stackreact?

En primer lugar, va a ser cada vez más fácil para los desarrolladores frontend hacer pila completa. Hay muchos más desarrolladores frontend que desarrolladores backend. Y tiene mucho sentido facilitar el desarrollo del backend para los desarrolladores frontend y proporcionarles una experiencia de desarrollo realmente buena y así todos se benefician. Por lo tanto, esta será definitivamente un área de enfoque para Blitz y Redwood en los próximos años.

En segundo lugar, vamos a seguir viendo un aumento en laproductividad para el desarrollo de pila completa. Y esto es muy importante para los desarrolladores solitarios que solo están haciendo proyectos secundarios, desarrolladores solitarios que están construyendo un negocio desde cero. Esto es muy clave. Y también para equipos pequeños que tienen un presupuesto y están tratando de trabajar juntos y les permite hacer más con menos personas. Por lo tanto, esta también será un área de enfoque.

A continuación, másbackend arquitectura ypatrones. Blitz y Redwood son muy minimalistas en este momento en cuanto albackend. No proporcionamos ninguna API o recomendación. Es bastante, deja mucho al lector para que descubra, en este caso, el programador. Pero definitivamente queremos mejorar esto. Y llegaremos allí.

Entonces, las cosas que necesitas en el backend son cosas como el procesamiento en segundo plano, trabajos programados, colas, correos electrónicos, carga de archivos, ese tipo de cosas. Y Blitz se va a enfocar en esto, agregando, ya sabes, recomendaciones, bibliotecas, APIs para estas cosas. Por ejemplo, como Nest, si conoces Nest.js, es un framework muy pesado de backend. Y así que estamos viendo Nest y viendo qué patrones podemos llevar a Blitz para hacer todo esto aún más fácil de lo que es ahora.

El número cuatro es serverless. Ahora, si bien tanto Blitz como Redwood admiten implementaciones serverless desde el principio, las aplicaciones de pila completa sin servidor todavía son un territorio desconocido. Hay dragones, ten cuidado. Creo que en los próximos años veremos mejoras masivas en la experiencia de desarrollo para aplicaciones de pila completa sin servidor. Y no solo se trata de implementaciones sin servidor realmente buenas, sino también de bases de datos sin servidor, procesamiento en segundo plano sin servidor y colas, y una integración perfecta de todas estas cosas juntas. Y así que todavía es el sueño de muchas personas tener este flujo de trabajo sin servidor donde no tienes servidores que administrar, donde el escalado automático se reduce a cero. Y así que es muy económico si no tienes mucho tráfico. Así que definitivamente es un área para estar atentos. Y estoy muy emocionado de ver qué viene en el futuro.

La otra área en la que debemos estar atentos actualmente es la integración de aplicaciones móviles en la experiencia de desarrollo de pila completa developer experience. Actualmente, Blitz y Redwood se centran principalmente en la experiencia web de pila completa, pero cada vez más las aplicaciones móviles son algo muy común. Y así que queremos llevarlas a esta experiencia de desarrollo de pila completa. Entonces obtienes, como, ¿de qué sirve, verdad? Si tienes una buena experiencia web de pila completa, pero luego tu experiencia de la aplicación móvil es solo como si estuviera abandonada, como, como vamos a llevar eso a toda esta pila completa cosa. Y luego es aún más fácil para todos, ¿verdad? Como que simplemente tiene sentido. Así que Blitz va a agregar soporte de primera clase para React Native. Y lo que queremos hacer es llevar la experiencia de cero API a las aplicaciones de React Native. Y así que no tienes que lidiar con Raster GraphQL. Simplemente importas tus funciones de servidor de Blitz en tu código de React Native, y luego se compilará, igual que ahora, en una llamada a la API. Así que esto es algo que será muy emocionante, espero que sea en algún momento más adelante este año.

Y eso concluye mi presentación. Gracias por su atención. Si quieres estar al tanto de lo que estoy trabajando, puedes seguirme en FlyBear en Twitter. Y si estás interesado en aprender más sobre Blitz.js, ve a blitzjs.com y la documentación está allí. Es muy fácil comenzar. Además, en la página de inicio, el primer video que aparece es, creo que es un video de una hora que cubre todas las áreas clave de Blitz, las características clave y muestra cómo puede aumentar tu productividad. Así que definitivamente échale un vistazo.

Y por último, pero no menos importante, si quieres pegatinas gratuitas, pegatinas gratuitas de Blitz.js, ve a blitzjs.com barra diagonal stickers, ingresa tu nombre y dirección, y te enviaremos pegatinas de Blitz gratis. Son realmente geniales. Así que échales un vistazo. Nuevamente, gracias.

Volviendo a la pregunta sobre los teclados mecánicos, voy a abrirlo en mi teléfono para ver cómo ha estado respondiendo la gente. Quiero escuchar tu opinión. ¿Eres un gran fanático de los teclados mecánicos? Aún no, pero estoy esperando. Voy a pedir el Keychron K3 tan pronto como vuelva a estar disponible. ¡Oh, wow! Bueno, pareces saber mucho sobre ellos, aunque no te interesen. Siento que me estoy interesando en ellos, sin embargo. Sí, sí, sí, construí este yo mismo.

El 52% dice que son increíbles, el 27% dice que me intrigan, pero nunca he probado uno. El 16% no está interesado y el 6% dice que no es para mí. Así que no sé. Me gusta tener el teclado elegante. Probé algunos interruptores nuevos en Target el otro día y me gustó la diferente sensación al hacer clic. Así que supongo que ese es mi consejo para cualquiera ahí fuera, probar diferentes niveles de clic y ver si te gustan los diferentes tipos.

Bien, vamos a responder algunas preguntas que son un poco más relevantes para tu charla. Fue una charla increíble, por cierto, aprecié mucho el recorrido por React. Y también la introducción a Blitz y Redwood, especialmente me gustó el regreso a los días pre-ES6 de React. Eso fue cuando empecé a escribir React en los días de las clases de Crete. Así que la primera pregunta que recibimos, y recibimos algunas que son similares, pero esta es de poplingay, ¿los frameworks están listos para producción y hasta qué punto? Tanto Redwood como Blitz están en versión preliminar, pero hay personas que los están utilizando en producción. Y en el caso de Blitz específicamente, sé que hay, creo que hay más de cien aplicaciones de Blitz en producción que se están ejecutando en negocios reales. Y una de las más grandes es mr-gamble.com, que es un jugador mediano-grande en el espacio de los casinos en línea. Se cambiaron de Next y Sanity a Blitz porque tenían problemas de rendimiento con Sanity. Y sí, están utilizando Blitz en producción desde el otoño pasado y les encanta. Y hay un montón de startups que lo están utilizando. Así que Blitz está en beta. Y lo que estoy diciendo es que ahora es un buen momento para comenzar una aplicación en producción.

Aún no es la versión 1.0, pero hay cambios mínimos y cosas que rompen. Y también la base es Next.js. Así que la base ya está muy probada en batalla. Y lo que agregamos encima también está bastante probado en este punto. Así que esperamos que la versión 1.0 sea probablemente en un par de meses, como mayo o junio. Oh, se acerca, muy emocionante. Oh, mayo es el próximo mes. Así que es muy pronto.

Y una continuación de eso de rman, ¿estaríamos hablando de algo que estaría listo para producción para una empresa con 200 ingenieros? Sí. Sí, seguro. Sí, eso es hacia lo que estamos trabajando o lo que estamos... Sí, está dirigido a equipos de todos los tamaños.

Genial, creo que mencionaste esto un poco tanto en tu charla como hasta ahora en esta sesión de preguntas y respuestas, pero esto es de Alex. ¿Hay una hoja de ruta sobre cuándo podríamos esperar que algunas de las futuras arquitecturas backend lleguen a Blitz, como procesamiento en segundo plano, correos electrónicos, carga de archivos y más? No hay una hoja de ruta. Así que todavía no tengo una empresa en torno a esto o al menos todavía no. Y por lo tanto, todavía es muy de código abierto. Así que no puedo decir realmente una hoja de ruta de como, va a estar aquí y allá, pero puedo decir que en este momento, personalmente me estoy enfocando en llegar a la versión 1.0, lo que significa solucionar errores y cosas. Así que no estoy planeando agregar nuevas características yo mismo, pero cualquiera más puede venir y como que, ya sabes, sumergirse y ayudar a agregar nuevas características. Y todavía estamos teniendo nuevas características siendo agregadas por otras personas, pero es solo si alguien está motivado y eres bienvenido a venir a ayudar. Nos encantaría.

Increíble, increíble. Así que eso es un llamado a la comunidad. Si quieres ver una característica, agrégala. Entonces, cuando React fue presentado por primera vez, fue apreciado porque era solo una biblioteca Blitz.js y Redwood.js parecen angularizar React. ¿Y crees que la idea de que React es solo una biblioteca y puede disminuir con el tiempo? Y esto es de Jayrock94. Creo que React en sí mismo se está convirtiendo más en un framework, especialmente con suspense y modo concurrente, fuera de Blitz y Redwood. Pero sí, y luego como Blitz y Redwood, ellos son muy definitivamente un framework. Y así, está construido sobre ese concepto de React, ya sea que lo llames biblioteca o framework, Blitz y Redwood son definitivamente un framework. Sí, más uno a eso, el nombre biblioteca versus framework siento que ni siquiera es muy claro ahora porque quiero decir que React decide cómo estructurar tu código de front-end. Como que es un framework, incluso si lo llamamos una biblioteca.

Otra pregunta. Esta es de poplingay. ¿Y cómo elegir entre Redwood o Blitz? La pregunta real es, ¿quieres trabajar con GraphQL o no? ¿Te gusta lidiar con APIs o no? Si lo haces, si quieres usar GraphQL y APIs, usa Redwood. Si no, usa Blitz porque Blitz abstrae esa capa y te permite importar directamente tu código de servidor en tu frontend. Y así, Blitz, como uno a uno Blitz es mucho más rápido para implementar una característica porque no tienes esa capa adicional de API. Y así, hay un nivel de compresión conceptual que Blitz proporciona, por eso mucha gente lo elige. Y luego, la otra cosa también es, Blitz se basa en Next.js y Redwood no. Redwood utiliza un framework personalizado, básicamente, de React. Es como su propio framework. Así que si realmente te gustó la experiencia de Next.js entonces elige Blitz. Pero si prefieres algo un poco más como listo para usar, probando cosas nuevas, entonces prueba Redwood.

Genial, genial. Otro y este es de Tech4Everyone. ¿Hay algún framework de testing disponible o preconfigurado de fábrica en Blitz.js? Sí. Sí, usamos Jest como configuración predeterminada. Y así tenemos un conjunto de pruebas de Jest donde todo está configurado de antemano. Te proporcionamos un archivo de test-utils que tiene los proveedores, como los proveedores de enrutador y otras cosas ya configuradas para ti. Así que está listo para usar de fábrica con Jest. Y agregaremos recetas de Blitz para Cypress y tal vez Playwright para las pruebas de extremo a extremo. Pero aún no tenemos eso, pero llegaremos allí.

Oh, eso es increíble. Eso es realmente genial. Y luego un par más. Así que enfatizaste la productividad de pila completa. ¿Tienes una idea aproximada de cuánto aumenta Blitz tu productividad? Lo que la mayoría de la gente dice es que es como entre 5 y 10 veces más productivo con Blitz que antes. Es significativo. Es como cuando la gente usa Blitz en un proyecto paralelo y luego vuelve al trabajo y piensa, esto es horrible. Como, quiero usar Blitz en todas partes. Así que sí, eso es bastante genial.

Eso es increíble. Eso es increíble. Esta pregunta es de Drake Yoon. ¿Tienen planes de ser más abiertos y permitir todo tipo de frameworks o ser más opinativos? Esto es algo que genera tensión entre las personas, algunas personas quieren ser más flexibles, otras más opinativas. En este momento estamos más del lado de la flexibilidad y las personas están dando comentarios de que quieren ser un poco más opinativos. En general, se trata más de los valores predeterminados. No hay muchas cosas que vamos a imponer, a diferencia de Rails que impone muchas cosas. Y así, Blitz es más flexible que eso. Pero sí, estamos tratando de encontrar el mejor equilibrio posible. ¿Esa convención versus configuración, verdad?

Genial. Esta es de Radoslav. Siempre es divertido decir los nombres de usuario en voz alta. ¿Cómo abstrae Blitz la API? ¿Qué hacemos cuando queremos cargar data dinámicamente? Hay una API en runtime. Blitz simplemente abstrae en una etapa de compilación. Y así, en tiempo de construcción, Blitz inserta una capa de API. Y así, por defecto, cuando cargas data en tus páginas a través de tus consultas de Blitz y luego cambias data a través de mutaciones, se está utilizando una API. Así que es dinámico. Se renderiza en el lado del cliente. Blitz no es de lado del servidor por defecto, pero puedes optar por eso página por página, igual que Next.js.

Genial. Genial. Hablamos un poco sobre cómo traer más arquitectura del backend y patrones a Blitz. ¿Están tomando inspiración de algo más para esto? Uno de los principales es Nest.js. No Next, sino Nest, N-E-S-T. Y eso es confuso. Pero algunas personas están usando Nest con Blitz en este momento. Como una solución temporal. Así que tomaremos algo de inspiración de eso. Y esto es algo en lo que nos encantaría tener más aportes y contribuciones para ayudar a desarrollar nuestros patrones y APIs del backend. Increíble.

Increíble. Me gusta llamarlos las bibliotecas Nstarjs porque es como Next, Next, Nest. Muy confuso.

Increíble. Bueno, muchas gracias. Nuevamente, esta fue una charla increíble. Si te gustó, ve y dirígete a Slido. Y nuevamente, el código para eso es 1415. Y puedes darle 5 estrellas a la charla de Brandon. Y puedes unirte a Brandon en su sala de discusión, que trata sobre desarrollo de aplicaciones full-stack en spatial.chat. Así que gracias nuevamente, Brandon.