Remixando un Symfony

Rate this content
Bookmark

A finales de 2020, realicé una prueba de Lighthouse en una página de contenido simple en Harvie, nuestra plataforma de gestión de granjas y aplicación Symfony, y obtuve una puntuación de rendimiento de 31/100. El paquete de JavaScript, las solicitudes de API, las consultas a la base de datos, incluso con una interfaz de usuario mínima para renderizar, tenían una puntuación base en los treinta. Junto con los comentarios de los clientes, esto ayudó a catalizar un compromiso renovado con el rendimiento en Harvie. A través de numerosas discusiones, recorrimos cada paso de la carga de la página, desde la conexión en red hasta el renderizado, e identificamos dónde podríamos mejorar. Después de un año de reescrituras y actualizaciones, nuestro último obstáculo para el rendimiento general era nuestro frontend. Habíamos estado convirtiendo nuestras plantillas de twig de Symfony en componentes de React SPA y caímos en el problema común de crear "cascadas de solicitudes", mientras nuestro usuario tenía que mirar una pantalla de carga. Necesitábamos un cambio, y para nosotros, eso fue Remix. En esta charla, te guiaré a través del viaje de nuestro equipo con el rendimiento y cómo Remix se ha convertido en una progresión natural de eso.

19 min
18 Nov, 2022

Video Summary and Transcription

Esta charla analiza el viaje de rendimiento de Harvey y cómo condujo a la adopción de Remix. El equipo de ingeniería abordó problemas de escalabilidad y rendimiento a través de correcciones en el backend y mejoras en el frontend. El rediseño se centró en cargar productos por categoría y priorizar el rendimiento. La implementación de Remix resultó en una mejora en el rendimiento y una reducción en las solicitudes de API. El enfoque en la escalabilidad a largo plazo es esencial para manejar una lista de productos y una base de clientes en crecimiento.

Available in English

1. Harvey's Performance Journey

Short description:

¡Hola a todos, bienvenidos! Mi nombre es Emily Kaufman. Hoy hablaré sobre el viaje de rendimiento de Harvey y cómo nos llevó a usar Remix. Harvey comenzó como un programa de CSA, pero durante la pandemia se convirtió en una tienda de comestibles completa. Nos enfrentamos a problemas de crecimiento y rendimiento a pesar del cambio a React. La arquitectura subyacente no podía manejar la carga.

[♪ Música reproduciéndose ♪ ¡Hola a todos, bienvenidos! Mi nombre es Emily Kaufman. Soy una ingeniera de software con sede en Pittsburgh, Pensilvania. De hecho, di esta charla en la- fui una oradora suplente en la primera conferencia de Remix, así que si ya la viste, esto puede sonar bastante familiar. Pero mi charla de hoy tratará sobre el viaje de rendimiento que ha experimentado Harvey, la empresa donde trabajo, en los últimos años y cómo eso finalmente nos llevó a Remix.

Muy bien, Harvey es un servicio de entrega de comestibles, donde todos nuestros productos provienen de granjas y productores locales. Así que comenzó, creo que hace unos diez años, como un programa de agricultura apoyada por la comunidad, si estás familiarizado con eso. Es un CSA. Básicamente, pagas a la granja una cierta cantidad de dinero al año y luego cada semana o cada dos semanas, recibes una caja con lo que hayan producido en ese tiempo. Es una forma realmente excelente de apoyar a los productores y granjas locales. Entonces, lo que hizo Harvey es proporcionar una plataforma para que realmente pudieras personalizar lo que recibías en tu caja. Hasta hace unos tres años, dos años y medio, eso era todo lo que hacía Harvey. Teníamos varias granjas en la plataforma de diferentes lugares y proporcionábamos la forma para que los clientes ingresaran, vieran el contenido de su caja, hicieran adiciones si querían cambiar cosas y luego esperaran su entrega.

Y luego llegó la pandemia. Entonces, tal vez recuerdes que al principio el mundo comenzaba a cerrarse. Muchas personas en el área de Pittsburgh recurrieron a Harvey como su principal fuente de comestibles, para evitar tener que ir a una tienda de comestibles. Y por otro lado, todos estos productores que solían ir a mercados de agricultores, instalar puestos en algún lugar para que pudieras venir y hacer compras, ya no tenían realmente un lugar adonde ir. Así que comenzaron a unirse a Harvey como productores para poder mantenerse en el negocio. Entonces, como puedes imaginar, tuvimos esta gran afluencia tanto de clientes como de productores y Harvey comenzó a crecer y evolucionar desde este programa de CSA hasta convertirse en una tienda de comestibles completa.

Por supuesto, durante cualquier tipo de crecimiento a gran escala en un corto período de tiempo como este, vas a experimentar algunos problemas de crecimiento y nosotros definitivamente los tuvimos. Esta es una prueba de Lighthouse que realicé a finales de 2020, y era simplemente una página de contenido simple en Harvey, que es una aplicación Symfony, y obtuvimos esta puntuación de rendimiento. Este era el paquete de JavaScript, las solicitudes a la API, las consultas a la base de datos, incluso con la interfaz de usuario mínima para renderizar en esta página de contenido básica, teníamos una puntuación base en los 30. Así que esto no estaba correcto. Algo no cuadraba. Esto, junto con algunos clientes molestos, algunos comentarios de los clientes, ayudó a catalizar este renovado interés y compromiso con el rendimiento en Harvey. La página del catálogo, donde puedes ver todos los productos, se había convertido recientemente, creo que un año antes de eso, de la combinación Symfony, jQuery, Twig en parte de una nueva aplicación de una sola página de React. Y esto fue lo más afectado. El cambio a React abordó muchas preocupaciones de experiencia de usuario que teníamos. Modernizó nuestra pila tecnológica, pero aún se quedaba corto en términos de rendimiento. Así que la arquitectura subyacente simplemente no podía manejar el peso de todos los nuevos productos. Tomaba varios segundos agregar algo a tu carrito o quitar algo o hacer un intercambio.

2. Fixes for Scaling and Performance

Short description:

Muchos miembros abandonaban el sitio debido a problemas de escalabilidad causados por el aumento significativo de productos ofrecidos. El equipo de ingeniería clasificó los problemas en soluciones rápidas, correcciones involucradas y planes de rediseño futuro. La infraestructura y la red fueron manejadas principalmente por servicios y herramientas. Las correcciones en el backend incluyeron la optimización de imágenes, el almacenamiento en caché y la actualización de puntos finales y consultas a la base de datos. Las mejoras en el frontend se centraron en reducir el tamaño del paquete y eliminar paquetes de localización innecesarios.

Y así, muchos miembros simplemente abandonaban por completo el sitio. Pero debemos recordar que hemos pasado de ofrecer quizás 30 a 40 productos hace un par de años a probablemente más de 600 en este momento. Y por lo tanto, la página simplemente no se estaba escalando correctamente. Entonces, cuando pensamos en soluciones para esto, nuestra primera iteración fue una especie de modo de crisis. Nuestro equipo de ingeniería se reunió y nos preguntamos qué podíamos hacer a corto plazo para solucionar algunos de estos problemas.

Así que pasamos unas horas sentados alrededor del panel de red en la pestaña de performance y revisamos cada paso de la carga de la página y organizamos lo que vimos en algunos grupos según quién los resolvería realmente. Así que teníamos DevOps y redes. Teníamos el backend, que incluía la API y la database, y luego teníamos el frontend. A partir de ahí, tomamos lo que encontramos y clasificamos esto en soluciones rápidas y fáciles, correcciones involucradas, y esto podría ser parte de un rediseño futuro.

Para DevOps y redes, no tuvimos que hacer mucho aquí porque en su mayoría eran manejados por servicios y tooling. Pero valió la pena sentarse y revisarlo y asegurarnos de que no hubiera cuellos de botella. Para la API del backend, tuvimos varios problemas con la carga de imágenes en el sitio. Tenemos un banner principal en casi todas nuestras páginas, y por alguna razón tardaba como siete segundos en cargarse y parecía bloquear la primera pintura. Así que hicimos mucho trabajo en torno a la optimization de imágenes y el almacenamiento en caché, y eso redujo segundos reales en el tiempo de carga de nuestra página. No puedo hablar de todo lo que hicieron mis compañeros de backend, pero las correcciones más involucradas incluyeron la actualización de los puntos finales y las consultas a la database para asegurarnos de que solo estamos consultando lo mínimo necesario, tratando de evitar operaciones innecesarias y computacionalmente costosas. Un ejemplo de esto es cualquier cosa que tenga que pasar por un proveedor externo. Por ejemplo, si estuviéramos verificando la información de la tarjeta de crédito de un usuario, podríamos hacer esto solo en una o dos páginas. Entonces no debería estar en un componente de nivel superior como el diseño principal porque entonces estaría sucediendo mucho más de lo necesario. En general, todas estas actualizaciones surgieron simplemente porque nos sentamos como equipo y nos quedamos mirando el panel de desarrollo durante unas horas e identificamos problemas.

Para el frontend, también conocido como mi problema, porque soy el único desarrollador frontend en Harvey, esto es cuánto tiempo tarda en descargar el contenido, qué tan grande es el script, testing conexiones más lentas y todo eso. Identificamos varias soluciones fáciles que sabíamos que requerirían un esfuerzo de desarrollo relativamente pequeño pero que aumentarían drásticamente la experiencia del usuario. Así que comenzamos por ahí. Por un lado, el paquete era simplemente demasiado grande, era demasiado grande. Había tanto código que un usuario tenía que descargar antes de poder interactuar con la página. Y utilizamos el plugin Webpacks. Utilizamos el plugin Webpacks Bundle Analyzer, si estás familiarizado con él, y esto nos ayudó a identificar muchas áreas problemáticas que pudimos abordar. Una de ellas fue nuestro uso de paquetes de localización de Moment.js. Así que estamos principalmente en el área de Pittsburgh. Tenemos granjas en todo el país, pero principalmente en los Estados Unidos. Entonces había muchos paquetes de localización que no eran realmente relevantes para nosotros en este momento, así que los eliminamos, estableciendo el objetivo de cambiar eventualmente a algo diferente que no sea Moment.

3. Mejoras de rendimiento en el frontend

Short description:

Revisé todas las dependencias en el package.json y eliminé las innecesarias. Teníamos una gran cantidad de elementos en la página de catálogo, lo que causaba problemas de rendimiento. Agregamos carga perezosa y dividimos nuestro código en proyectos separados para reducir el tamaño del paquete. La compresión de texto y la minimización de scripts de terceros también tuvieron un efecto positivo. Mover las llamadas costosas a la API mejoró la carga de la página y las interacciones.

Revisé todas las dependencias en el package.json y traté de entender por qué estaban allí, si aún eran necesarias, si podían actualizarse. Y pudimos eliminar una buena cantidad de ellas.

Así que tengo esta captura de pantalla divertida y estresante de la pestaña de performance. Esta es nuestra página de catálogo. Uno de los mayores problemas que teníamos en el frontend, especialmente en la página de catálogo, era simplemente la gran cantidad de elementos que teníamos. Como dije antes, en un momento dado, tal vez teníamos 40 tarjetas de productos, cada una con una imagen y algunos botones, ya sabes, cosas normales de comercio electrónico. Y ahora tenemos casi 600. Entonces, incluso sin todas las optimizaciones que estamos haciendo ahora, hace dos años, esta página funcionaba perfectamente, funcionaba bien. Porque recuerda, Harvey nunca fue pensado para ser más grande que un pequeño programa de CSA. Entonces, una de las primeras cosas que hicimos aquí, después de ver esto, fue agregar carga perezosa a la página, y de inmediato dejó de bloquearse, lo cual tiene sentido. Pero puedes ver en la captura de pantalla que básicamente estamos tratando de cargar 500 imágenes a la vez.

OK, no me adentraré demasiado en todo lo que hicimos en el frontend, porque solo tengo 20 minutos, pero tengo una lista no exhaustiva aquí. Mejor división de código. Esto podría incluso ser una división de código más reflexiva. Realmente tomarse el tiempo para pensar en qué necesita cargarse realmente en cada ruta. Entonces, con nuestra aplicación de una sola página, no dedicamos mucho tiempo a considerar qué modules realmente necesitaban estar en cada página. Entonces, una de las cosas que esto llevó a hacer fue dividir nuestro código de miembro y administrador en dos proyectos separados con sus propias compilaciones, y luego hice una biblioteca de componentes donde ambos podían compartir. Entonces eso redujo mucho el tamaño del paquete. Comenzamos a usar compresión de texto. Agregamos esto a todos nuestros archivos de JavaScript. Y creo que nuestro CSS usando Gzip, y eso tuvo un efecto positivo. Minimizar y diferir scripts de terceros. A veces esto puede parecer una batalla constante con el marketing. Esto incluye cosas como Zendesk, Hotjar, Analytics, cualquier cosa que, ya sabes, tal vez el marketing esté usando para rastrear eventos en tu sitio web. Entonces revisamos esto y nos aseguramos de que todos los que estábamos usando todavía fueran necesarios, e intentamos identificar lugares donde pudiéramos diferirlos cuando fuera posible. Minimizar llamadas costosas a la API. Toqué esto antes, pero mucho de esto fue simplemente mover dónde estábamos haciendo estas llamadas, fuera de un diseño y dentro de un componente o una ruta. Solo para que no se hicieran todas en cada página. Entonces todos estos cambios que mencioné llevaron a una diferencia sustancial en términos de carga de página, y especialmente en dispositivos móviles. Y ayudaron en cierta medida con las interacciones de la página después de la carga, como agregar, eliminar, intercambiar elementos de la tarjeta.

4. Rediseño y Compromiso con el Rendimiento

Short description:

Nuestro rediseño se centró en cargar productos por categoría en lugar de cargar cada producto individual en la página. Movimos partes de la tarjeta de producto a una página de detalles y eliminamos funcionalidades que no aportaban suficiente valor para el cliente. Este compromiso con el rendimiento como un principio de diseño esencial llevó a un diseño más ligero. Aunque el rediseño mejoró el tiempo de carga, la puntuación de Lighthouse se mantuvo baja. A principios de 2020, compré una licencia de Remix.

Pero sabíamos que nuestro diseño actual simplemente no iba a soportar el nuevo modelo de negocio, el modelo de supermercado más grande que estábamos tratando de lograr. Y así sabíamos que era hora de un rediseño.

Una cosa que hicimos, esta es nuestra página rediseñada aquí. En lugar de cargar cada producto individual en la página, los cargamos por categoría. Así que ya no teníamos tantos elementos en la página. Una nota divertida sobre esto, sin embargo. Nuestras categorías están creciendo lo suficiente como para que ahora estemos empezando a considerar la paginación o algo así, debido al crecimiento.

Eliminamos partes de la tarjeta de producto, la descripción, la información del productor, y las movimos a una página de detalles para que no tuviéramos que cargar todas esas cosas para cada producto en el catálogo. Generamos múltiples tamaños de imagen para cada una de ellas, así que teníamos una miniatura, que puedes ver en la parte inferior de esta imagen aquí. Teníamos una vista de detalles, que es esta más grande, la vista de tarjeta, y coincidían con cómo se mostrarían en la página. Eliminamos algunas funcionalidades, como el botón de intercambio. Solíamos tenerlo para que, si estabas en tu carrito de compras, pudieras intercambiar. Por ejemplo, si no querías brócoli, podías cambiarlo por zanahorias. Pero simplemente no estaba aportando suficiente valor para el cliente para el problema de rendimiento que estaba causando, así que decidimos deshacernos de él.

Y eso llevó a esta forma de pensar. Como cuando incluyes un compromiso con el rendimiento como un principio esencial del diseño, entonces cuando estás pensando en el rendimiento cada vez que estás construyendo una nueva funcionalidad, el diseño se volverá más ligero. Así que me encuentro haciendo esto mucho. Entonces diremos, oh, deberíamos agregar esto al sitio. Esto haría esto. Sería realmente genial. Y luego nos damos cuenta de que va a haber un impacto en el rendimiento. Y es como, ¿realmente vale la pena agregar tanto tiempo a la carga de las páginas? ¿Vale la pena recibir ese golpe? Y muchas veces la respuesta es no.

Bien, veamos si esto carga. Así que nuestra página rediseñada estará a la izquierda y la página existente estará a la derecha. La página rediseñada se carga considerablemente más rápido que la página existente. Pero aún no es suficiente. Quería deshacerme de todos los indicadores de carga. Y a pesar de que nuestro tiempo de carga era mucho mejor, nuestra puntuación de Lighthouse seguía siendo bastante baja, lo cual fue sorprendente.

Bien, vamos a remix. A principios de 2020, me compré una licencia de remix como regalo de cumpleaños para mí mismo.

5. El Poder de Remix para el Rendimiento

Short description:

He estado probando Remix en proyectos de hobby y me di cuenta de su potencial para resolver nuestros problemas de rendimiento. Implementamos con éxito Remix en nuestras nuevas páginas de comestibles, lo que resultó en un mejor rendimiento. Remix minimiza la cascada de solicitudes, reduciendo las solicitudes de API y mejorando la experiencia del usuario. Planeamos migrar más páginas a Remix y priorizar el rendimiento y la escalabilidad en todos nuestros lanzamientos. Nuestras listas de productos en crecimiento y nuestra base de clientes requieren un enfoque en la escalabilidad a largo plazo.

Y he estado probándolo en varios proyectos de hobby, simplemente testing lo que podría hacer y en general pasando un buen rato. Fue para mí. Y me di cuenta de que la colocación de las solicitudes de carga de página con los componentes, con el diseño, podría ayudarnos a salir de este problema de giro nuevamente que estamos teniendo, como lo llama el equipo de remix. Así que todavía no tengo nada desplegado públicamente, por mucho que quiera, pero pude poner en marcha nuestras nuevas páginas de comestibles con remix. Y creo que los resultados hablan por sí mismos.

Ejecuté este informe de Lighthouse solo para tener una idea de si, sabes, va a marcar alguna diferencia para nosotros. Y sí, puedes verlo. Entonces, uno de los puntos fuertes de remix es que minimiza la cascada de solicitudes. Y ese fue el caso para nosotros en algunas partes de la aplicación. Estábamos haciendo múltiples solicitudes de API al cargar la página y simplemente teníamos ese spinner en la interfaz de usuario. Veamos este video. ¿Está reproduciéndose? Lo haré de nuevo. Tan rápido. Ahí vamos.

Bien, este video está ligeramente sesgado porque la aplicación existente tiene más integraciones de terceros como un widget de soporte y algunas características más en general. Pero aún puedes ver esa segunda ola de solicitudes que se dispararon en los efectos de uso en el componente. Así que eso es en nuestra página existente. Si cambio a Remix, esta es la misma cascada pero en la versión de Remix. Entonces, en la versión de Remix, tenemos un tiempo de carga de documento más largo pero un número mínimo de solicitudes adicionales. Y como solo cargamos lo necesario para esa página, este JavaScript que se carga es mucho más pequeño. Así que todo esto sin aprovechar al máximo algunas de las características como el enrutamiento anidado en el que estamos empezando a trabajar ahora. Pero sí, fue una mejora inmediata para nosotros. Fue realmente emocionante.

Entonces, en el futuro, nuestro plan es seguir moviendo estas páginas existentes que actualmente están en nuestro código orientado a los miembros a nuestra aplicación de Remix hasta llegar a un punto en el que tengamos suficiente para implementarlo y que sea público. Pero el uso del framework se ha convertido en una progresión natural de nuestro viaje de performance en Harvey, y definitivamente ha valido la pena el esfuerzo, y ayuda que realmente disfruto trabajando en él. Entonces, si hemos aprendido algo en los últimos dos años, es que el rendimiento y la construcción para la escala no son negociables cuando estamos lanzando nuevas características. Tiene que estar integrado en todo lo que hacemos y verificar constantemente si hay regresiones. Entonces, nuestras listas de productos, nuestra base de clientes, siguen creciendo a un ritmo rápido. Y sí, tengo confianza en que lo que estamos haciendo ahora va a respaldar cómo se ve el negocio tal vez dentro de cinco a diez años. Así que es un momento emocionante. Muy bien. Gracias por escuchar. Nuevamente, mi nombre es Emily Kaufman. Si tienes alguna pregunta, puedes encontrarme en Twitter o puedes leer la publicación del blog detrás de esta presentación en mi sitio web. Así que gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
Remix Conf Europe 2022Remix Conf Europe 2022
156 min
Build and Launch a personal blog using Remix and Vercel
Featured Workshop
In this workshop we will learn how to build a personal blog from scratch using Remix, TailwindCSS. The blog will be hosted on Vercel and all the content will be dynamically served from a separate GitHub repository. We will be using HTTP Caching for the blog posts.
What we want to achieve at the end of the workshop is to have a list of our blog posts displayed on the deployed version of the website, the ability to filter them and to read them individually.
Table of contents: - Setup a Remix Project with a predefined stack- Install additional dependencies- Read content from GiHub- Display Content from GitHub- Parse the content and load it within our app using mdx-bundler- Create separate blog post page to have them displayed standalone- Add filters on the initial list of blog posts