El Futuro Stack de la Revisión de Código

Rate this content
Bookmark

De alguna manera, la revisión de código tenía los mismos chistes y proceso mientras el mundo del desarrollo de software cambiaba a diario. Únete a nosotros para aprender cómo adaptar este proceso a las pilas modernas y hacer de la revisión de código una fiesta de eficiencia.

22 min
05 Jun, 2023

Video Summary and Transcription

La Charla discute los desafíos de las revisiones de código y la necesidad de redefinir el proceso de revisión de código a la luz de los cambios en el desarrollo de software. Enfatiza la importancia de la colaboración, la seguridad, el rendimiento y el código limpio en el nuevo stack de revisión de código. La Charla también destaca los beneficios de automatizar los comentarios de revisión de código y optimizar el proceso de revisión de código. En general, la Charla tiene como objetivo construir un mejor proceso de revisión de código que promueva la colaboración y mejore la calidad del desarrollo de software.

Available in English

1. El Revisor de Código Molesto

Short description:

Hoy quiero presentarte a la persona molesta en cada equipo a la que nadie quiere que haga una revisión de código. Siempre tienen comentarios que interrumpen el trabajo y arruinan tu mundo. Lidiar con 20 comentarios como 'Parece bien para mí' puede ser un problema.

Así que, hola, soy Gabriel y hoy quiero presentarte a una persona que todos conocemos porque existen en cualquier equipo, y esta es la persona molesta a la que nadie quiere dejar hacer una revisión de código, ¿verdad? La revisión de código siempre se ve mejor, tienen comentarios como 'No lo haría así', y luego se vuelve más personal, pero está bien porque el jefe les dice que interrumpe el trabajo, y luego se vuelve más largo y tiene todos esos comentarios que no significan nada y solo arruinan tu mundo, ¿verdad? Así es como funcionan las revisiones de código, y luego aprendes a hacer el LGTM. Parece bien para mí, pero el problema siempre es ponerlo como un problema. Así que tienes que lidiar con 20 comentarios como LGTM.

2. La Evolución de las Revisiones de Código

Short description:

Experimenté un problema similar con un revisor de código molesto en mi equipo. Después de años de evitar sus revisiones, comencé a reflexionar sobre cómo ha evolucionado el stack de software. Desde un servidor monolítico en Java hasta microservicios que se ejecutan en la nube, las herramientas y técnicas para las revisiones de código han permanecido iguales. Recurrí a Twitter en busca de opiniones y encontré ideas sobre mejoras, mentoría y calidad.

Entiendo tu problema porque también experimenté a una persona así en mi equipo. Y después de seis años conviviendo con esa persona a la que hago todo lo posible para evitar que revise mi código, comencé a reflexionar. Y eché un vistazo a cómo ha cambiado el stack de software a lo largo de los años. Comencé a trabajar en el mismo lugar en 2016. Solíamos tener un servidor monolítico en Java que resolvíamos como una máquina virtual junto con Oracle database. Hacíamos una escala vertical, es decir, instalábamos la misma imagen 50 veces y lanzábamos el software cada seis meses.

Luego nos mudamos a algunos microservicios en 2018. Creamos una puerta de enlace para cargar la pieza de software balanceada en lugar de un balanceador de carga de hardware. Avanzamos aún más en 2020. Teníamos microservicios en varios lenguajes. Estábamos completamente en la cloud. Hacíamos una escala horizontal y así sucesivamente. Ahora gastamos en microservicios cada semana. Enviamos nuestro software en minutos, pero las revisiones de código siguen siendo las mismas. Durante los últimos 20 años, las herramientas han permanecido iguales. Los comentarios siguen siendo los mismos. La forma en que las personas hacen revisiones de código, las técnicas que te dicen que debes hacer en las revisiones de código siguen siendo las mismas.

Y todo eso me parece extraño. Y cada vez que algo me parece extraño, recurro a Twitter. Sé que no es lo correcto, ir a Twitter y pedir opiniones a la gente. Pero así soy yo. Hice esa pregunta y realmente te recomiendo, hay un enlace a continuación para ver el tweet en sí. Realmente te recomiendo que vayas a ver qué respondió la gente, pero también echemos un vistazo aquí y veamos algunas palabras. Así que veamos aquí. Por ejemplo, Karen dijo que se trata de mejorar y eso es correcto. Queremos mejorar como desarrolladores. Queremos que nuestro producto mejore. Y por eso hacemos revisiones de código. Boris habla sobre la mentoría y llegaremos a eso más adelante. Vemos a Lia hablar sobre calidad y así sucesivamente.

3. El Cambiante Paisaje de la Revisión de Código

Short description:

Así que recojo todo y luego empiezo a pensar qué podemos hacer para redefinir. Redefinir la revisión de código, encontrar la manera de progresar de la misma forma en que progresamos con el stack de software también en el proceso de revisión de código. Ahora tenemos mucho más que proteger, ya que gestionamos la implementación desde el mismo código y tenemos dependencias entre servicios. Otro cambio es que ahora somos políglotas, desarrollando software en varios lenguajes. La IA también nos está reemplazando, por lo que nuestro trabajo como desarrolladores es comprender la plataforma y la aplicación que estamos desarrollando. El ciclo de vida del desarrollo de software está automatizado, lo que facilita la implementación de nuevas características en producción.

Así que recojo todo y luego empiezo a pensar qué podemos hacer para redefinir. Redefinir la revisión de código, encontrar la manera de progresar de la misma forma en que progresamos con el stack de software también en el proceso de revisión de código.

Mi nombre es Gabriel y soy el director de Deverell en Permit.io. Permit.io es una startup que resolvió un problema crítico en el control de acceso. Desarrollamos un sistema que permitía a los desarrolladores implementar autorización en su sistema en poco tiempo. Con solo unas pocas líneas de código puedes obtener todo un sistema de autorización en tu aplicación.

Y como parte de mi trabajo, siempre estoy observando a los desarrolladores, ¿verdad? Estoy viendo cómo trabajan los desarrolladores, estoy desarrollando herramientas para desarrolladores. Y me pregunto, ¿qué ha cambiado? Si miramos el stack de software desde la perspectiva de la revisión de código, ¿qué ha cambiado en todos estos años? Entonces, lo primero es que ahora tenemos mucho más que proteger. Si miramos, por ejemplo, la prevención de errores en 2015, en 2010, necesitábamos prevenir errores en el código de la aplicación. Teníamos una aplicación y esta aplicación podía tener errores potenciales en la lógica del propio código y queríamos protegerla. Pero hoy en día tenemos mucho más que proteger porque también gestionamos la implementación desde el mismo código. También tenemos un problema de performance simplemente porque tenemos dependencias entre servicios. Gestionamos muchas cosas a través del código y tenemos mucho más que proteger cuando inspeccionamos la calidad.

Y otra cosa que también ha cambiado. Ahora somos políglotas. Ya no soy un desarrollador de JavaScript. Soy un desarrollador full stack. Así es. Mi lenguaje materno es JavaScript, pero programo para Node.js. Programo para D-Nodes. También puedo programar para web assembly, para navegadores, para aplicaciones nativas, para aplicaciones de escritorio. Ya no programamos en un solo lenguaje. Desarrollamos software. Y cuanto más avanzamos, y otro cambio, ahora la IA nos va a reemplazar, ¿verdad? Como desarrolladores, nuestro trabajo hoy en día es simplemente comprender la plataforma, comprender la aplicación, los dominios para los que estamos desarrollando software. Programo con Copilot. Ya no necesito ser experto en JavaScript. Debo ser experto en el software que estoy tratando de entregar. De esta manera puedo obtener aplicaciones mucho mejores. Y además, si observamos el ciclo de vida del desarrollo de software, todo está automatizado. Hoy, cuando quiero implementar una nueva característica en producción, no hago nada más que abrir una solicitud de extracción.

4. El Futuro Stack de Revisión de Código

Short description:

Después de automatizar CI/CD y desplegar mi software, es importante tener en cuenta estos cambios en la revisión de código. Sin embargo, la sabiduría humana y la colaboración siguen siendo esenciales. Las revisiones de código pueden obstaculizar la velocidad, por lo que necesitamos un nuevo stack que aborde los cambios en nuestro stack de software y se centre en la colaboración, la seguridad, el rendimiento y el código limpio.

Después de eso, tengo flujos de GitOps, tengo CI y CD automatizados. Todo sucedió de alguna manera y mi software acaba de ser desplegado. Debemos tener en cuenta todos estos cambios en la revisión de código, ¿verdad? Pero también hay cosas que no cambian. Por ejemplo, la necesidad de la sabiduría humana. Todavía necesitamos el pensamiento único del cerebro humano sobre cómo entregamos la aplicación. Es cierto que las computadoras están ejecutando nuestras aplicaciones, pero otras personas necesitarán leerlo, otras personas necesitarán gestionarlo, otras personas necesitarán tomar decisiones comerciales. Y esta sabiduría humana, esta conexión entre las personas no ha cambiado. Este es un principio fundamental que queremos mantener en el futuro stack de revisión de código. Y otra cosa que nunca cambió es que las revisiones de código son enemigas de la velocidad. Si queremos ver, si echamos un vistazo a cualquier tablero Kanban o de cualquier manera en que gestionemos nuestro mundo, siempre veremos que el obstáculo más grande que detiene nuestro software del progreso es la forma en que hacemos las revisiones. Tenemos una tarea manual que se interpone en medio de todas las tareas automatizadas y ralentiza nuestra velocidad.

5. Definiendo el Nuevo Stack de Revisión de Código

Short description:

Necesitamos definir el nuevo stack de revisión de código basado en los diferentes entornos, despliegues e lenguajes utilizados por cada equipo. Los aspectos clave del nuevo stack incluyen aumentar la velocidad, mejorar la legibilidad del código, mejorar la seguridad y el rendimiento, mantener un código limpio, fomentar la colaboración y garantizar la escalabilidad. Comprender las responsabilidades de la revisión de código, incluyendo verificar el código, probar la aplicación y considerar la plataforma, es crucial para implementar revisiones de código efectivas.

Entonces ahora necesitamos definir cuál es el nuevo stack de revisión de código. Veamos las revisiones de código y construyamos juntos un nuevo stack. He creado una lista aquí, pero creo que el aspecto más importante de esta lista es el número ocho, lo que aportas como el nuevo stack de revisión de código, porque cada equipo hoy en día piensa diferente, cada equipo funciona en diferentes entornos, cada equipo gestiona los despliegues de manera diferente, cada equipo escribe en múltiples lenguajes para múltiples plataformas. Así que solo puse mi stack principal de equipo, pero tú también puedes agregar tu stack. Y ese es el punto de la charla. Quiero que comencemos en el nuevo código, el nuevo stack de revisión de código como algo que implementamos en nuestras necesidades de software. No solo un estándar general que necesitamos para entregar software, sino un estándar que se ajuste a nuestro software.

Entonces veamos lo que he enumerado aquí. Quiero aumentar la velocidad utilizando la revisión de código. No quiero que me frene. Quiero que me ayude a mejorar la velocidad. Quiero que el código sea más legible porque los humanos leen el código, aunque las máquinas lo ejecuten. Quiero obtener una mejor seguridad. Ese es un aspecto crítico que se puede lograr a través de la revisión de código. Y también quiero obtener un mejor rendimiento. Y quiero mantener un código limpio, pero el significado general de código limpio. Por ejemplo, quiero mantener los principios sólidos en mi código, y quiero fomentar la colaboración con mi equipo. Y quiero asegurarme de que el código, tanto en los aspectos micro como macro, sea realmente escalable.

Al observar esta lista, he creado una lista de las mejores prácticas que podemos obtener para la revisión de código. La primera es comprender las responsabilidades de la revisión de código. Tenemos tres puntos cuando analizamos cada pieza de software. Primero está el código. Esta es la parte micro de nuestro software. El código en sí se puede verificar con LinkedIn. Se puede verificar con análisis estático. Todos ellos verificarán que cada función, cada fragmento de código, cada pequeño fragmento de código que escribimos cumpla con los estándares. También tenemos las pruebas en nuestra aplicación. El aspecto más amplio de nuestro software. Y luego la plataforma en la que lo ejecutamos. Y luego podemos utilizar herramientas para prevenir errores. Todas estas responsabilidades juntas son la razón de la revisión de código.

6. Optimizando el Proceso de Revisión de Código

Short description:

Para la revisión de código, es importante comprender las responsabilidades y enfocarse en el 20% que realmente importa. Optimizar el proceso de revisión y priorizar las solicitudes de extracción puede mejorar los plazos. El uso de herramientas como ESLint para el linting, análisis estático y pruebas unitarias puede garantizar la confiabilidad del código. Automatizar los comentarios de revisión de código con herramientas como ESLint puede ahorrar tiempo y fomentar una cultura de calidad de código.

Para cada uno de ellos por separado, podemos utilizar herramientas automáticas. Puedo usar ESLint para mantener todo limpio en mi código. Pero cuando el código en sí se superpone con nuestra arquitectura de aplicación y la plataforma en la que se ejecuta, es ahí donde necesitamos un ojo humano. Un ojo humano que comprenda el panorama general y piense en las cosas importantes.

Entonces, la primera mejor práctica cuando hago una revisión de código es conocer las responsabilidades. Y luego, como líder técnico, quiero que solo el 20% de la responsabilidad humana recaiga en la revisión de código. Piénsalo como un principio de Pareto. Las consecuencias de los errores que encontraré provendrán principalmente de la revisión automática, ¿verdad? De las pruebas, de todo eso. Pero el humano encontrará cosas importantes, pero solo el 20% del esfuerzo. Quiero que el humano invierta su tiempo en escribir código. La revisión es importante, pero solo en el 20% que realmente importa.

También quiero obtener una mejor línea de tiempo para la revisión de código. No quiero que las personas comiencen a revisar el código en el momento en que se publique. Una de las razones de esto es el cambio de contexto. Cuando estoy revisando código, no estoy escribiendo código. Eso me desconecta de la tarea en la que estoy trabajando actualmente. Quiero establecer un flujo de trabajo en el que las personas ingresen a la fase de revisión solo después de asegurarme de que la solicitud de extracción cumpla con todos los estándares. Primero quiero priorizar la solicitud de extracción. Tal vez sea solo una pequeña corrección de CSS. Y pronto hablaremos sobre herramientas que pueden indicarte si es solo una pequeña corrección de CSS, si no, tal vez no necesite una revisión de código. Quiero hacer el linting correcto y luego el análisis estático desde la perspectiva de seguridad y también desde la perspectiva del código. Y solo después de una prueba unitaria, quiero que los ojos humanos lo revisen porque ahora puedo asegurarme de que el código sea confiable para llegar a producción. Luego me ocuparé de las pruebas de extremo a extremo, que llevan tiempo. Pero lo que sé ahora es que una persona está perdiendo su tiempo en una revisión solo después de asegurarse de que sea confiable.

Luego está una mentalidad que queremos fomentar. La pregunta es, ¿puedo automatizarlo? Esta es una pregunta que me hago por cada comentario que hago en una revisión de código. ¿Puedo automatizarlo para que la próxima vez el desarrollador lo encuentre antes que yo? No es difícil lograrlo porque tenemos una herramienta muy cómoda para el linting de JavaScript, ESLint. Podemos escribir reglas personalizadas para ESLint. Esto es en realidad una cultura que queremos implementar en la organización. Queremos que las personas entiendan que ESLint debe funcionar para ellos.

7. Automatizando Comentarios de Revisión de Código

Short description:

Si ves comentarios repetitivos en las revisiones de código, escribe una regla automatizada para encontrarlos. Creé un complemento de ESLint que prohíbe el uso de 'localhost' en el código. Automatizar los comentarios de revisión de código ahorra tiempo y fomenta una mentalidad de automatización. Si un comentario no se puede automatizar, reconsidera su necesidad. Nuestro código es diverso y la legibilidad es subjetiva. Sigue los principios pero respeta las preferencias personales. En lugar de instruir, comienza conversaciones preguntando 'por qué'.

Si ven que se atasca en el trabajo o que algunos comentarios repetitivos vuelven una y otra vez en las revisiones de código, deberíamos escribir una regla automatizada que lo encuentre la próxima vez. Y esto en realidad no es tan difícil. Veamos qué tan fácil puedo escribir un fragmento de código que verifique problemas en mi código.

Entonces, aquí, por ejemplo, creé un complemento personalizado de ESLint. Y mi problema aquí es esta función. Alejémonos por un momento de las mejores prácticas y entendamos qué está sucediendo aquí. New permit es en realidad nuestro SDK. Y aquí hay alguna configuración para el SDK. Uno de ellos es el punto de decisión, un servidor al que el software debe ir. Y aquí podemos ver un local host. Pero las mejores prácticas indican que no se debe poner local host aquí. Después de que me di cuenta de que estaba comentando a alguien que no deberíamos entregar código con local host, puedo automatizarlo. Puedo crear un complemento de ESLint aquí que diga que no se permite usar local host. Y eso es bastante fácil porque lo que necesitas es comprender cómo se ve el código. Y puedes leer las instrucciones, no estamos aquí para aprender cómo escribir reglas de ESLint. Pero puedes ver aquí que si el valor de PDP es local host, estoy devolviendo un error y podemos ver que funciona aquí. Entonces, si vas, por ejemplo, a la terminal y ejecuto ESLint en mi programa, puedo ver que obtengo un error. Y, por supuesto, si tus usuarios trabajan con el IDE correcto, lo recibirán justo a tiempo. Y esta es una mentalidad que debemos fomentar. Si tienes un comentario que no se puede automatizar, piénsalo de nuevo. Tal vez sea solo tu opinión. Tal vez sea algo que no debas incluir. Nuestro código ahora es diverso. La legibilidad se basa en sentimientos subjetivos. Tenemos principios que seguir, pero nadie debe rastrear tus preferencias personales. Continúa con las mejores prácticas. Queremos ser un equipo. Queremos ser buenas personas cuando hacemos revisiones de código.

Entonces, primero quiero tener una conversación en lugar de dar instrucciones. En lugar de decirles a las personas que no deben hacerlo de esta manera, tal vez pregúntales por qué.

8. Construyendo un Mejor Proceso de Revisión de Código

Short description:

Queremos pensar como un equipo y fomentar la colaboración. Evita ser minucioso y mantén el proceso de revisión de código simple. Trata las revisiones de código como características del producto y analiza su impacto. Utiliza métricas para identificar patrones y mejorar la experiencia. Gestiona las prioridades de revisión de código con herramientas como GitStream. Construyamos nuestro software y creemos un mejor producto con desarrolladores más felices.

O, creo que debería hacerse mejor, pero estaré encantado de recibir una explicación de por qué lo hiciste. Porque probablemente si lo hiciste, hiciste algo bien. Tal vez al final no esté de acuerdo con eso, pero así es como nosotros, como personas, nos comunicamos. Y queremos pensar en equipo en lugar de individualmente. No pienses en alguien del equipo que está haciendo el trabajo solo y que necesitamos afectarlos de alguna manera. Somos un equipo, estamos trabajando juntos. Todos somos responsables de nuestro software. Y queremos fomentar la colaboración en lugar de la competencia. No competimos entre nosotros, somos miembros del equipo que debemos trabajar juntos para hacer lo mejor y simplemente crear un mejor software.

Y queremos evitar ser minuciosos. Si veo un comentario minucioso en una revisión de código, eso significa que alguien está tratando de perder mi tiempo. No me importa ser minucioso, podrías iniciar una conversación sobre tu minuciosidad y luego puedo responder y tal vez al final esté de acuerdo contigo. Y también mantengámoslo simple. Una de las cosas que veo en las revisiones de código e incluso puedes verlo en un proyecto de código abierto grande es que las personas intentan complicar las cosas, las personas intentan hacer el mensaje complicado, las personas intentan hacer complicada la revisión de código. Seamos personas decentes cuando hagamos una revisión de código, seamos mejores personas.

Y también queremos tratar la revisión de código como una característica del producto, es decir, queremos analizarlas. Cuando hacemos una retrospectiva de nuestro sprint y vemos por qué una tarea tardó tanto, veamos también cuánto tiempo la revisión de código estuvo atascada en una fase de revisión. Es fácil obtener esa información de la API de GitHub y en realidad es una métrica muy importante. Si podemos ver un patrón en las revisiones de código que se atascan una y otra vez, tal vez eso signifique que no tenemos suficiente experiencia en el equipo, tal vez signifique que algunas personas deberían hacer otras tareas. Podríamos utilizar la información y las métricas que obtenemos de, digamos, las herramientas de revisión de código de GitHub y obtener un mejor producto para ellos. Y por último pero no menos importante está la gestión de prioridades. Hoy en día existen herramientas que pueden ayudarte a gestionar la prioridad de la revisión de código. Como mencioné, por ejemplo, GitStream analiza las revisiones de código en sí mismas y determina si una revisión de código es algo que realmente debería tener prioridad sobre otras tareas o si puede ir directamente a la integración y despliegue continuos y pasar a producción. A veces sí, a veces sin la intervención de los ojos humanos, los ojos humanos, como dijimos, son importantes, pero debemos usarlos sabiamente. Estoy seguro de que también tienes best practices para tus revisiones de código. Pero recordemos, estamos construyendo nuestro software. Estamos creando el nuevo proceso de revisión de código. Descubre cuál es tu proceso para la revisión de código. Construye tus best practices, crea un mejor producto y desarrolladores más felices. Muchas 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

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.