Enhancing Accessibility at Stack Overflow

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Slides
Rate this content

La accesibilidad es crucial para crear productos inclusivos y a menudo para cumplir con los requisitos legales también. Sin embargo, evaluar y cuantificar el progreso de una empresa en esta área puede ser un desafío. En Stack Overflow, pasamos de abordar rápidamente los problemas de accesibilidad a una estrategia proactiva que integra la accesibilidad en nuestro ciclo de desarrollo de productos.

Acompáñame mientras comparto cómo el equipo de Diseño del Sistema en Stack Overflow lideró esta transformación al definir objetivos claros, asegurar el compromiso de ingeniería y desarrollar un panel de accesibilidad que realiza un seguimiento del progreso y proporciona información accionable. Aprende cómo creamos un sistema de puntuación de accesibilidad semiautomatizado que nos ayudó a establecer objetivos de nivel de servicio de accesibilidad (SLO) para nuestros productos.

This talk has been presented at JSNation US 2024, check out the latest edition of this JavaScript Conference.

Giamir Buoncristiani
Giamir Buoncristiani
15 min
21 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hola a todos, soy Giammi. Hoy me gustaría compartir con ustedes un estudio de caso sobre cómo la cuantificación de la accesibilidad jugó un papel crucial en la mejora de la accesibilidad de nuestros productos en Stack Overflow. Comenzamos nuestro viaje estableciendo objetivos claros de accesibilidad basados en las pautas de WCAG y adoptamos el Algoritmo de Contraste Perceptual Avanzado para abordar el contraste de colores. Establecimos una forma de medir el progreso de la accesibilidad utilizando herramientas automatizadas y puntuaciones manuales. Nuestro enfoque se centró en el sistema de diseño y realizamos mejoras como una nueva paleta de colores. Algunas lecciones clave incluyen la importancia de establecer objetivos claros y medir la accesibilidad del producto para motivación y visibilidad. El trabajo de accesibilidad está en curso y debe integrarse temprano en el proceso de desarrollo. Gracias por escuchar.

1. Introducción

Short description:

Hola a todos, soy Giammi. Hoy, me gustaría compartir con ustedes un estudio de caso sobre cómo cuantificar la accesibilidad jugó un papel crucial en la mejora de la accesibilidad de nuestros productos en Stack Overflow. Trabajo como ingeniero de planta en el equipo que impulsa iniciativas relacionadas con el front-end. Nuestros equipos de producto carecen de objetivos claros de accesibilidad y a menudo solucionan problemas de manera reactiva. Nuestro liderazgo dudaba en invertir completamente en esfuerzos de accesibilidad, y nuestras comunidades y clientes luchaban por ver nuestro compromiso.

Hola a todos, soy Giammi. Hoy, me gustaría compartir con ustedes un estudio de caso sobre cómo cuantificar la accesibilidad ha jugado un papel crucial para mejorar la accesibilidad de nuestros productos en Stack Overflow.

Pero primero, un par de palabras sobre mí. Estoy bastante seguro de que la mayoría de ustedes aquí están familiarizados con Stack Overflow. Lo que quizás no sepan es que Stack Overflow tiene un sistema de diseño de código abierto que llamamos Stacks. Trabajo como ingeniero de planta en ese equipo, donde estamos impulsando muchas iniciativas relacionadas con el front-end en nuestra organización.

Pequeño descargo de responsabilidad, no me considero un experto en accesibilidad, pero tuve la oportunidad de liderar la iniciativa que estoy a punto de contarles. Lo que sigue ha funcionado bien para nuestra organización, pero como todo en el desarrollo de software, su experiencia puede variar.

Permítanme comenzar dándoles un poco de contexto sobre los desafíos de accesibilidad que enfrentamos en Stack Overflow. Nuestros equipos de producto carecen de objetivos claros de accesibilidad. A menudo solucionan problemas de manera reactiva, esperando que se informen los problemas en lugar de prevenirlos proactivamente. Nuestro liderazgo era comprensiblemente reacio a invertir completamente en esfuerzos de accesibilidad. Sin una visibilidad clara de nuestro progreso, era difícil justificar priorizarlo junto con otras iniciativas urgentes. Y finalmente, nuestras comunidades y clientes, algunos de los cuales con requisitos legales de accesibilidad hacia sus empleados, estaban luchando por ver nuestro compromiso con la accesibilidad.

2. Establishing Accessibility Targets

Short description:

Comenzamos nuestro viaje estableciendo un resultado claro para generar confianza con nuestras comunidades y clientes. Nuestro objetivo era mejorar proactivamente la accesibilidad en todos nuestros productos y convertirla en una parte central de cómo construimos. Nuestro equipo del sistema de diseño tenía la mayor experiencia en accesibilidad y lideró la iniciativa. Establecimos objetivos claros de accesibilidad basados en las directrices de WCAG y adoptamos el Advanced Perceptual Contrast Algorithm para abordar el contraste de color. Formalizamos estos objetivos a través de un ADR para asegurar un compromiso a largo plazo.

Sabíamos que necesitábamos hacerlo mejor, tanto para cumplir con las expectativas de nuestros clientes y comunidades, como para construir productos más inclusivos en general. Así que junto con nuestro liderazgo, comenzamos nuestro viaje estableciendo un resultado claro para generar confianza con nuestras comunidades y clientes demostrando un fuerte compromiso con la accesibilidad. Queríamos ir más allá de simplemente cumplir con los requisitos legales, nuestro objetivo era mejorar proactivamente la accesibilidad en todos nuestros productos, convirtiéndola en una parte central de cómo construimos. Así es como abordamos la búsqueda de nuestra estrategia para alcanzar nuestro resultado.

Rápidamente nos dimos cuenta de que nuestro equipo del sistema de diseño, mi equipo, tenía la mayor experiencia en accesibilidad en toda la organización. Estábamos en la mejor posición para liderar esta iniciativa dado nuestro fuerte entendimiento de ambos aspectos, el diseño y los aspectos técnicos de la accesibilidad. Luego, el liderazgo nos proporcionó un resultado claro para mejorar la accesibilidad y generar confianza, pero también nos dieron la libertad de explorar soluciones. Esto nos empoderó para pensar creativamente y asumir la responsabilidad de cómo podríamos lograr este objetivo. Para organizar nuestro esfuerzo, utilizamos un árbol de soluciones de oportunidades. Esta es una herramienta de gestión de productos que nos permite hacer una lluvia de ideas y visualizar cómo cada acción que consideramos contribuirá a nuestro objetivo final. Con nuestro árbol de soluciones de oportunidades en su lugar, pudimos reducir nuestra estrategia a estos cuatro puntos principales.

Primero, necesitábamos establecer un objetivo claro de accesibilidad. Sin metas definidas, sería imposible medir el progreso o saber cuándo realmente estábamos teniendo un impacto. A continuación, decidimos medir la accesibilidad de nuestros productos de manera consistente. Queríamos datos para respaldar nuestro esfuerzo y asegurarnos de que no solo estábamos adivinando, sino realmente mejorando la accesibilidad con el tiempo. También sabíamos que teníamos que liderar con el ejemplo con nuestro sistema de diseño. Dado que nuestro equipo del sistema de diseño tenía la mayor experiencia en accesibilidad, era crucial que nuestros componentes de diseño establecieran el estándar de accesibilidad en toda la organización. Finalmente, queríamos comenzar a desplazar la accesibilidad hacia la izquierda. Esto significa incorporar la consideración de la accesibilidad más temprano en el proceso de desarrollo para que se convierta en parte de cómo hacemos las cosas, no una ocurrencia tardía. Vamos a profundizar en la primera parte de nuestra estrategia.

Lo primero que hicimos fue establecer objetivos claros y documentados de accesibilidad basados en las Web Content Accessibility Guidelines, a menudo pronunciadas WCAG. Tener estas directrices nos dio puntos de referencia concretos y reconocidos por la industria para medir nuestros productos. También creó claridad para nuestros equipos al saber exactamente qué significaba la accesibilidad en la práctica. Un desafío que enfrentamos fue el color naranja característico de Stack Overflow. Según las directrices de WCAG, no cumplía con los requisitos de contraste. La razón es que el algoritmo actual de contraste de color de WCAG es demasiado simple para tener en cuenta la complejidad de la percepción humana. Así que hicimos una excepción aquí adoptando el Advanced Perceptual Contrast Algorithm o APCA en resumen. APCA podría convertirse en parte de la próxima especificación WCAG 3 y nos permite trabajar con el naranja mientras aún tenemos un medio para verificar el contraste de color de manera automatizada. Y finalmente para asegurar un compromiso a largo plazo en toda la organización, formalizamos estos objetivos a través de un Architectural Decision Record o en resumen ADR. Este ADR hizo de la accesibilidad una parte no negociable de nuestro proceso de desarrollo, asegurando que cada equipo estuviera alineado y fuera responsable de cumplir con este objetivo.

3. Measuring Accessibility Progress

Short description:

Establecimos objetivos de accesibilidad y creamos una señal sintética para rastrear nuestro progreso. Usamos una herramienta automatizada llamada Axecore para calcular puntuaciones de accesibilidad, complementada por puntuaciones manuales de varias fuentes. Construimos un panel de accesibilidad para hacer que los datos sean fácilmente accesibles y procesables. Los flujos de trabajo de GitHub y un tablero centralizado de accesibilidad nos ayudan a rastrear problemas y mejorar la accesibilidad en nuestros productos, con un enfoque en el sistema de diseño.

Si tienes curiosidad sobre los detalles de este objetivo y cómo están documentados, puedes escanear este código QR para profundizar en nuestra documentación del sistema de diseño sobre accesibilidad. Una vez que tuvimos nuestros objetivos de accesibilidad en su lugar, el siguiente paso crítico fue medir nuestro progreso de manera consistente y confiable. Nos propusimos crear una señal sintética para rastrear cómo estábamos avanzando en relación con nuestro objetivo de accesibilidad y darnos una indicación clara de si nos estábamos moviendo en la dirección correcta.

Para la verificación automatizada, utilizamos una herramienta llamada Axecore desarrollada por Deque. Es una herramienta poderosa utilizada por muchos productos en la industria que nos ayuda a calcular la accesibilidad de manera automatizada y calcular la puntuación de accesibilidad para nuestras páginas de productos. Sin embargo, las herramientas automatizadas como esta típicamente solo detectan alrededor del 50-57 por ciento de los problemas más débiles en promedio. Así que sabíamos que esto era solo una parte del panorama. Para llenar los vacíos, también establecimos puntuaciones manuales de varias fuentes, incluidos auditores externos, comentarios de la comunidad y problemas reportados por los clientes. Esto nos dio una visión más completa de la accesibilidad de nuestros productos cubriendo cosas que la automatización por sí sola no podía detectar.

Finalmente, para hacer que todos estos datos sean fácilmente accesibles y procesables, construimos un panel de accesibilidad. Esto se convirtió en un centro donde los equipos, nuestra comunidad e incluso los clientes podían rastrear nuestro progreso y responsabilizarnos. Ahora vamos a profundizar un poco más en cómo nuestros informes de accesibilidad, tanto automatizados como manuales, contribuyen a crear nuestras puntuaciones de accesibilidad. Para los automatizados, tenemos flujos de trabajo de GitHub que se activan diariamente y que verifican varias reglas más débiles a través de Axe Engine y Playwright. Esas reglas se ejecutan contra una selección de las páginas más importantes de nuestros diferentes productos. Los resultados del flujo de trabajo luego se transforman en métricas que subimos a nuestra plataforma de accesibilidad.

Para los problemas manuales, tenemos un tablero centralizado de accesibilidad donde cualquier persona en la organización puede registrar problemas. Los problemas son luego clasificados por un grupo de ingenieros y diseñadores expertos en accesibilidad. Llamamos a este grupo campeones de accesibilidad. Los problemas clasificados tienen un campo de severidad asociado a ellos y afectan la puntuación de accesibilidad manual. Luego tenemos un servicio de accesibilidad que es responsable de extraer datos de nuestra plataforma de observabilidad y nuestro tablero central de accesibilidad. Calcular la puntuación y luego mostrarlas en nuestro panel disponible públicamente. Y así es como se ve el panel final que todos pueden consultar en accessibility.stackoverflow.net. Todavía estamos iterando en este panel, pero incluso en su estado actual proporciona información procesable para que nuestro equipo mejore la accesibilidad en nuestros productos. Además de mostrar tendencias de puntuación, el panel resalta la puntuación de accesibilidad por página y detalla todos los problemas identificados por las ejecuciones automatizadas. Teníamos nuestros objetivos de accesibilidad en su lugar y una forma clara de rastrear el progreso a lo largo del tiempo. A continuación, era hora de arremangarnos y comenzar a rastrear algunos de los problemas de accesibilidad en nuestro producto. Sabíamos que comenzar con nuestro sistema de diseño tendría el mayor impacto ya que nuestras bibliotecas se utilizan para construir interfaces de usuario en prácticamente todos los productos. Así que el sistema de diseño es donde enfocamos nuestro esfuerzo primero. A medida que hicimos mejoras, documentamos y compartimos técnicas de WCAG con el resto de la organización de ingeniería, asegurando que las mejores prácticas fueran ampliamente adoptadas. Algunos de los problemas clave que abordamos incluyen mejorar el estilo de enfoque para asegurar indicadores visuales claros, especialmente para nuestros usuarios que solo usan el teclado, y también tuvimos el componente de enlaces de salto ligero que permite a los usuarios omitir bloques repetidos de contenido en nuestras páginas mejorando la navegación para todos.

4. Improving Accessibility and Key Learnings

Short description:

Mejoramos la accesibilidad implementando una nueva paleta de colores guiada por el algoritmo APCA. También nos enfocamos en el pensamiento temprano sobre accesibilidad, estableciendo campeones, creando una lista de verificación y estableciendo objetivos de nivel de servicio. Las lecciones clave incluyen establecer objetivos claros y medir la accesibilidad del producto para motivación y visibilidad.

Probablemente la mejora de accesibilidad más impactante que hicimos fue implementar una nueva paleta de colores desarrollada en estrecha colaboración con nuestro equipo de diseño. Usamos el algoritmo de contraste perceptual accesible APCA como nuestra guía.

Como mencioné anteriormente el algoritmo actual de contraste de color de WCAG es demasiado simple para tener en cuenta la complejidad de la percepción humana. Es especialmente poco confiable al probar ciertos colores como el naranja de Stack Overflow. Aquí es también donde contribuimos de nuevo al código abierto. APCA siendo un algoritmo de vanguardia no estaba aún soportado por el motor AXE core, así que creamos una regla de cumplimiento de APCA para el motor que nos dio una forma automatizada de probar el contraste de color en nuestras páginas.

Si estás interesado en usar las reglas de APCA para verificar tus propias páginas, puedes encontrar más detalles en el repositorio de verificación de APCA siguiendo el código QR en las diapositivas. La última parte de nuestra estrategia fue lograr que nuestra organización pensara en la accesibilidad desde el principio en el proceso de desarrollo. Hicimos esto a través de algunas iniciativas clave. Primero establecimos campeones de accesibilidad dentro de cada equipo. Son responsables de difundir el conocimiento sobre accesibilidad y reunirse regularmente con otros campeones en toda la organización. También trabajamos con el liderazgo de producto y de ingeniería para asegurarnos de que los equipos tuvieran el espacio para priorizar y mejorar sus puntuaciones de accesibilidad. Creamos una lista de verificación de accesibilidad ágil que aparece automáticamente como un comentario cuando se detectan cambios en la UI en las solicitudes de extracción. Y desarrollamos un breve video de capacitación interna para ingenieros y diseñadores con consejos prácticos de accesibilidad específicos para nuestras necesidades.

Llamamos a estos bocados de accesibilidad. Quizás una de las cosas más importantes que hicimos para salvaguardar nuestros estándares de accesibilidad fue establecer objetivos de nivel de servicio de accesibilidad. Básicamente usamos la puntuación de accesibilidad automatizada como un indicador de nivel de servicio. A cada producto se le asignó un objetivo. Si hay una caída en la puntuación, se crea automáticamente un incidente de prioridad tres y se notifica al campeón de accesibilidad de guardia. A partir de ahí, hay un plazo de siete días para identificar y solucionar la causa raíz de la regresión de accesibilidad. Al cuantificar la accesibilidad, pudimos integrarla en procesos familiares para nuestros ingenieros y liderazgo. La accesibilidad ya no es un concepto vago e intangible.

Se ha vuelto tan concreto como cualquier otra métrica que rastreamos. Aquí hay algunas lecciones clave de nuestro viaje que quiero dejarles. Primero, establecer objetivos claros de accesibilidad para la organización. Sin metas definidas no hay forma de medir el éxito. Igualmente importante es asegurar el compromiso organizacional con esos objetivos por parte del liderazgo y de los equipos para que la accesibilidad se convierta en una prioridad central para todos. Segundo, asegurarse de medir y rastrear la accesibilidad del producto. Cuando los equipos pueden ver un progreso real impulsa la motivación y también da visibilidad al liderazgo y al cliente.

5. Continuing Accessibility and Appreciation

Short description:

El trabajo de accesibilidad nunca termina. Desplaza la accesibilidad hacia la izquierda integrándola temprano en el proceso de desarrollo e invirtiendo en educación y salvaguardas. Sigue refinando procesos e invierte en pruebas de usuario. Gracias por escuchar.

Demuestra compromiso y ayuda a cuantificar los retornos de la inversión en accesibilidad.

Tercero, desplaza la accesibilidad hacia la izquierda. Esto significa integrar la accesibilidad temprano en tu proceso de desarrollo. Invierte en educar a los equipos y crear salvaguardas como verificaciones automatizadas o pasos impulsados por procesos para prevenir regresiones. Se trata de preparar a los ingenieros para el éxito asegurando que la accesibilidad sea parte del proceso y no una ocurrencia tardía.

Y finalmente, recuerda que el trabajo de accesibilidad nunca termina. Siempre hay más que podemos hacer. Sigue refinando procesos e invierte en pruebas de usuario para asegurar que seguimos refinando procesos e invierte en pruebas de usuario para asegurar que realmente estamos satisfaciendo las necesidades de los usuarios. La accesibilidad no es y no debería ser un proyecto de una sola vez. Es un viaje continuo de mejora.

Eso es todo lo que tengo por hoy. Espero que nuestro enfoque para mejorar la accesibilidad en Stack Overflow te haya dado algunas ideas sobre cómo priorizar la accesibilidad en tu propia empresa.

Quiero agradecer a mis compañeros de equipo Dan y Caro, al Grupo de Campeones de Accesibilidad de Stack Overflow y al Gremio de Front-end de Stack Overflow. Todos ellos juegan un papel crucial para hacer que lo que acabo de presentar sea una realidad para nuestra organización.

Si tienes preguntas, aquí puedes encontrar mi correo electrónico y mi usuario de redes sociales. Gracias por escuchar.

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

Depuración de JS
React Summit 2023React Summit 2023
24 min
Depuración de JS
Top Content
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Un Marco para Gestionar la Deuda Técnica
TechLead Conference 2023TechLead Conference 2023
35 min
Un Marco para Gestionar la Deuda Técnica
Top ContentPremium
Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.
Construyendo un Asistente AI Activado por Voz con Javascript
JSNation 2023JSNation 2023
21 min
Construyendo un Asistente AI Activado por Voz con Javascript
Top Content
This Talk discusses building a voice-activated AI assistant using web APIs and JavaScript. It covers using the Web Speech API for speech recognition and the speech synthesis API for text to speech. The speaker demonstrates how to communicate with the Open AI API and handle the response. The Talk also explores enabling speech recognition and addressing the user. The speaker concludes by mentioning the possibility of creating a product out of the project and using Tauri for native desktop-like experiences.
Una Guía Práctica para Migrar a Componentes de Servidor
React Advanced 2023React Advanced 2023
28 min
Una Guía Práctica para Migrar a Componentes de Servidor
Top Content
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
Solucionando Problemas de Rendimiento en React
React Advanced 2023React Advanced 2023
22 min
Solucionando Problemas de Rendimiento en React
Top Content
This Talk discusses various strategies to improve React performance, including lazy loading iframes, analyzing and optimizing bundles, fixing barrel exports and tree shaking, removing dead code, and caching expensive computations. The speaker shares their experience in identifying and addressing performance issues in a real-world application. They also highlight the importance of regularly auditing webpack and bundle analyzers, using tools like Knip to find unused code, and contributing improvements to open source libraries.
De Monolito a Micro-Frontends
React Advanced 2022React Advanced 2022
22 min
De Monolito a Micro-Frontends
Top Content
Microfrontends are considered as a solution to the problems of exponential growth, code duplication, and unclear ownership in older applications. Transitioning from a monolith to microfrontends involves decoupling the system and exploring options like a modular monolith. Microfrontends enable independent deployments and runtime composition, but there is a discussion about the alternative of keeping an integrated application composed at runtime. Choosing a composition model and a router are crucial decisions in the technical plan. The Strangler pattern and the reverse Strangler pattern are used to gradually replace parts of the monolith with the new application.

Workshops on related topic

Construyendo una Aplicación de Shopify con React & Node
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Construyendo una Aplicación de Shopify con React & Node
Top Content
Workshop
Jennifer Gray
Hanna Chen
2 authors
Los comerciantes de Shopify tienen un conjunto diverso de necesidades, y los desarrolladores tienen una oportunidad única para satisfacer esas necesidades construyendo aplicaciones. Construir una aplicación puede ser un trabajo duro, pero Shopify ha creado un conjunto de herramientas y recursos para ayudarte a construir una experiencia de aplicación sin problemas lo más rápido posible. Obtén experiencia práctica construyendo una aplicación integrada de Shopify utilizando el CLI de la aplicación Shopify, Polaris y Shopify App Bridge.Te mostraremos cómo crear una aplicación que acceda a la información de una tienda de desarrollo y pueda ejecutarse en tu entorno local.
Construye una sala de chat con Appwrite y React
JSNation 2022JSNation 2022
41 min
Construye una sala de chat con Appwrite y React
Workshop
Wess Cope
Wess Cope
Las API/Backends son difíciles y necesitamos websockets. Utilizarás VS Code como tu editor, Parcel.js, Chakra-ui, React, React Icons y Appwrite. Al final de este masterclass, tendrás los conocimientos para construir una aplicación en tiempo real utilizando Appwrite y sin necesidad de desarrollar una API. ¡Sigue los pasos y tendrás una increíble aplicación de chat para presumir!
Problemas difíciles de GraphQL en Shopify
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Problemas difíciles de GraphQL en Shopify
Workshop
Rebecca Friedman
Jonathan Baker
Alex Ackerman
Théo Ben Hassen
 Greg MacWilliam
5 authors
En Shopify a gran escala, resolvemos algunos problemas bastante difíciles. En este masterclass, cinco oradores diferentes describirán algunos de los desafíos que hemos enfrentado y cómo los hemos superado.

Tabla de contenidos:
1 - El infame problema "N+1": Jonathan Baker - Vamos a hablar sobre qué es, por qué es un problema y cómo Shopify lo maneja a gran escala en varios APIs de GraphQL.
2 - Contextualizando APIs de GraphQL: Alex Ackerman - Cómo y por qué decidimos usar directivas. Compartiré qué son las directivas, qué directivas están disponibles de forma predeterminada y cómo crear directivas personalizadas.
3 - Consultas de GraphQL más rápidas para clientes móviles: Theo Ben Hassen - A medida que tu aplicación móvil crece, también lo harán tus consultas de GraphQL. En esta charla, repasaré diversas estrategias para hacer que tus consultas sean más rápidas y efectivas.
4 - Construyendo el producto del futuro hoy: Greg MacWilliam - Cómo Shopify adopta las características futuras en el código actual.
5 - Gestión efectiva de APIs grandes: Rebecca Friedman - Tenemos miles de desarrolladores en Shopify. Veamos cómo estamos asegurando la calidad y consistencia de nuestras APIs de GraphQL con tantos colaboradores.
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Node Congress 2024Node Congress 2024
152 min
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Workshop
Emanuel Scirlet
Miguel Henriques
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
De 0 a Autenticación en una Hora para tu Aplicación JavaScript
JSNation 2023JSNation 2023
57 min
De 0 a Autenticación en una Hora para tu Aplicación JavaScript
WorkshopFree
Asaf Shen
Asaf Shen
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada.
Mejoraremos una aplicación JS de pila completa (backend Node.js + frontend Vanilla JS) para autenticar usuarios con contraseñas de un solo uso (correo electrónico) y OAuth, incluyendo:
- Autenticación de usuario: Gestión de interacciones de usuario, devolución de JWT de sesión / actualización- Gestión y validación de sesiones: Almacenamiento seguro de la sesión para solicitudes posteriores del cliente, validación / actualización de sesiones
Al final del masterclass, también abordaremos otro enfoque para la autenticación de código utilizando Flujos de Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña.