Creando juegos multijugador con Colyseus, Node.js y TypeScript

Rate this content
Bookmark

Al interactuar con la comunidad de Colyseus en los últimos años, algunas preguntas fundamentales (no necesariamente relacionadas con el framework) parecen aparecer una y otra vez cuando los desarrolladores comienzan a construir sus propios juegos multijugador. Esta charla cubrirá algunas de estas preguntas, así como los escenarios y técnicas más comunes que puedes comenzar a usar hoy en día al construir tu propio juego multijugador.

31 min
07 Apr, 2022

Video Summary and Transcription

La charla de hoy cubre la creación de juegos multijugador con Coliseus, Node.js y Typescript. Explora el estado de la red en la web, servidores alternativos y cómo funciona Coliseus. La charla también discute la predicción del lado del cliente, compensación de retraso, limitaciones del servidor, escalabilidad y muestra juegos geniales hechos con Coliseus. Además, menciona la integración de Nakama y Unity para la predicción del lado del cliente en juegos multijugador. Coliseus está disponible en dispositivos móviles y se puede encontrar en colossus.io o en el repositorio de GitHub.

Available in English

1. Introducción a Coliseus y Networking

Short description:

Hoy hablaré sobre cómo crear juegos multijugador con Coliseus, Node.js y Typescript. Discutiremos el estado de la red en la web, servidores alternativos, cómo funciona Coliseus, técnicas del lado del cliente y juegos multijugador construidos con Coliseus. El estado de la red en la web actualmente se basa en WebSockets y WebRTC, con la posible inclusión futura de Web Transport. Aunque TCP es la única opción para juegos basados en web, generalmente se prefiere UDP. Sin embargo, muchos juegos exitosos se han creado utilizando TCP y WebSockets.

crear juegos multijugador con Coliseus, Node.js y Typescript. Estoy muy emocionado de estar aquí.

Los temas de esta charla son el estado de la red en la web, servidores alternativos, cómo funciona Coliseus y sus sistemas internos, algunas técnicas del lado del cliente que se pueden aplicar incluso fuera del ámbito de Coliseus, y algunos juegos multijugador construidos con Coliseus.

Entonces, el estado de la red en la web. En este momento, para conexiones bidireccionales, principalmente tenemos disponibles WebSockets y WebRTC. Esperamos que en el futuro se incluya Web Transport. WebSockets solo admite TCP y está disponible desde 2011. WebRTC se ha estandarizado completamente solo en el último año y es bastante complicado e involucra muchos otros protocolos, y admite conexiones confiables e no confiables. WebTransport, esperamos que reemplace a WebSocket en el futuro. Nadie sabe cuándo. Y es muy emocionante. Admite entrega confiable y no confiable y ya tiene soporte experimental en Chrome desde enero de este año. El consejo general para la red fuera de la web es que TCP no es ideal para juegos y UDP sí lo es, es difícil no estar de acuerdo con esto, pero desafortunadamente la web solo tiene TCP hasta ahora. Esperamos que Web Transport cambie eso en el futuro y muchos juegos exitosos se han creado en el pasado utilizando TCP y WebSockets es lo que tenemos y hay muchos juegos exitosos creados sobre WebSockets.

2. Servidores Alternativos y Marco de Coliseus

Short description:

En un enfoque alternativo, el servidor valida y determina el estado del juego en lugar de confiar en el cliente. Coliseus es un marco de Node.js que utiliza WebSockets para el transporte. Proporciona emparejamiento de jugadores, sincronización de salas y mensajería. Las salas en Coliseus tienen métodos de ciclo de vida y pueden crearse cuando los clientes solicitan unirse o crearlas. El flujo de emparejamiento implica una solicitud HTTP para la reserva de asientos, la consulta de salas existentes, la creación de una sala si es necesario y el establecimiento de una conexión WebSocket. Después de establecer la conexión, el cliente recibe el estado completo de la sala y puede comenzar a intercambiar mensajes.

De acuerdo, sin más preámbulos, hablemos de los servidores alternativos. En un enfoque alternativo, no confiaríamos en el cliente, por lo que el cliente no podría decir, por ejemplo, dónde se encuentra. El cliente nunca debería dictar información. El servidor siempre debería poder validar y decir la verdad sobre el estado del juego. Esto no es muy alternativo, podría estar bien si estás de acuerdo con esto, pero no sería factible en un juego multijugador competitivo.

Entonces, una alternativa a esto es dar más o menos información al servidor. Digamos que estoy apuntando en un cierto ángulo y moviéndome hacia adelante. El servidor tiene la posición actual y determinará cuál es la siguiente, no el cliente. Así que esta es una alternativa, las responsabilidades del servidor son mantener la lógica del juego, el estado del juego, validar las entradas del cliente e intercambiar mensajes con los clientes y también el estado. Las responsabilidades del cliente básicamente son ser una representación visual de lo que está en el servidor y enviar entradas y acciones al servidor. Lo que Coliseus aporta a la mesa es un marco de Node.js. Está construido solo con WebSockets, por lo que hasta ahora solo hay WebSocket como capa de transporte en Coliseus. Hace coincidir a los jugadores en salas y tiene una sincronización de salas y un sistema de mensajería incorporados. Y tiene los bloques de construcción y la arquitectura para que puedas escalar esto a muchos servidores y tener muchos servidores que manejen múltiples salas. Y como puedes ver, las salas son un bloque muy básico de Coliseus, y así es como se ve una definición de sala, y tiene sus métodos de ciclo de vida, como onCreate para configurar una partida, onJoin cuando algún jugador se une a la sala, onLeave para eliminar a este jugador del estado de la sala y los otros clientes pueden reaccionar a este cambio, y onDispose cuando esta sala ha sido destruida en el servidor. Si tienes un estado global compartido o algo en la base de datos, este es un buen lugar para limpiar las cosas globales que esta sala haya creado. Para que los clientes se unan a esta sala, debes exponer esto al emparejador. Verás que en este punto no se crea ninguna sala real. Las salas solo se crean cuando el cliente solicita unirse o crearlas. En este ejemplo, el cliente solicita unirse a una sala de juego y proporciona alguna información sobre sí mismo, como el nombre. Para la solicitud de emparejamiento, así es como se ve el flujo. El cliente realiza una solicitud HTTP para solicitar una reserva de asiento. El servidor va a buscar posibles salas que ya existan. Si no existe, intenta crear una y devuelve el ID de la sala y el ID de sesión, que es la reserva de sesión. Después de obtener la reserva de sesión, intenta conectarse realmente a través de WebSockets. Así es como se ve el flujo desde la perspectiva del servidor. Primero intenta validar al usuario durante el encendido. Esto es totalmente personalizado y basado en tus propios requisitos. Si eso tiene éxito, intenta llamar a onJoin. En cualquier momento, podrías lanzar un error aquí y el cliente llegaría al bloque catch. Sí, podrías lanzar un error desde el servidor y aquí llegaría al cliente. No ha ocurrido ningún error durante este proceso, se establece la conexión y después de establecer la conexión, lo primero que hace el cliente es recibir el estado completo de la sala, por lo que el cliente ya puede construir la representación visual que esa sala tiene en el servidor y comenzar a intercambiar mensajes y más parches de estado y más mensajes, y luego es un web socket regular y cosas bidireccionales.

3. Message Listening and State Mutation

Short description:

La API onMessage es bastante simple, te permite escuchar y enviar mensajes entre el cliente y el servidor. El servidor puede enviar mensajes a clientes específicos o transmitir mensajes a todos los clientes en una sala. El estado de la sala se basa en estructuras mutables, sincronizadas cada 15 milisegundos, y las mutaciones solo deben realizarse en el servidor. Las estructuras utilizadas para el estado se llaman esquemas de Coliseus, que proporcionan un tipado fuerte, serialización incremental, bajo rendimiento y una API de devolución de llamada en el lado del cliente. En este ejemplo, se utiliza un juego de mesa para ilustrar la creación de un estado y asignar jugadores en función del ID de sesión.

La API onMessage es bastante simple, así es como escuchas y envías mensajes entre el cliente y el servidor. El servidor puede enviar un mensaje a un cliente en particular en función de la referencia del cliente, y el servidor también puede transmitir mensajes a todos los clientes dentro de esta sala, por lo que no hay una forma incorporada para que el servidor envíe la transmisión a cada cliente en cada sala. Si necesitas hacer eso, debes implementarlo tú mismo.

El estado de la sala se basa en estructuras mutables, por lo que no puedes usar ninguna estructura inmutable como lo harías en los frameworks de front-end, y las mutaciones que realizas en esas estructuras se sincronizan automáticamente cada 15 milisegundos de forma predeterminada. Y esas mutaciones son unidireccionales, por lo que solo debes mutar los datos de estado en el servidor para que se transmitan de vuelta a los clientes. Nunca debes mutar el estado en el cliente mismo.

Correcto, las estructuras que usamos para el estado se llaman esquemas de Coliseus. Son de tipado fuerte, admiten serialización incremental, tienen la menor salida que podríamos implementar y proporcionan una API de devolución de llamada en el lado del cliente. Explicaré un poco más sobre esto en un momento. Está muy inspirado en otras bibliotecas de serialización como protocol buffers, flat buffers y otras. En este ejemplo, imagina un juego de mesa. Aquí tienes un mapa de jugadores, y el jugador tiene una posición. Una posición en el mapa o en el tablero. Y en el código de la sala, inicialmente crearías un estado, estableciendo el estado durante la creación, y cada vez que un jugador se una a esta sala, asignaremos al mapa de jugadores un nuevo jugador en función del ID de sesión de ese cliente.

4. Client-side Prediction and Lag Compensation

Short description:

El ID de sesión es el identificador único para este cliente en esta sala. En el lado del cliente, cada cliente debe escuchar las adiciones y eliminaciones de esta estructura de jugadores. ¿Cuál es la diferencia entre mensajes y estado de sala? Los mensajes son efímeros, mientras que el estado es persistente. En los juegos multijugador, la latencia es inevitable y los desarrolladores deben tratar de mitigar la latencia percibida por el jugador actual. La predicción en el lado del cliente se puede utilizar para proporcionar una respuesta inmediata a las acciones del jugador. La interpolación lineal es una técnica simple que puede tener buenos resultados.

El ID de sesión es el identificador único para este cliente en esta sala. Y cada vez que el cliente envía un mensaje de movimiento, obtiene la referencia del jugador y aumenta su posición. Como puedes ver, esto no es muy alternativo. Cualquier jugador podría enviar esto en cualquier momento y aumentaría su posición. Idealmente, debe haber algún tipo de validación, como, ¿este jugador está en su turno actual? ¿Tiene algún movimiento válido pendiente? Algunas comprobaciones como estas.

Sí, en el lado del cliente, cada cliente debe escuchar las adiciones y eliminaciones de esta estructura de jugadores. Estos son los callbacks que registrarías en el cliente para preparar la representación visual. Esto está escuchando el cambio del atributo de posición. Una ventaja de usar TypeScript es que si proporcionas, esto es opcional por cierto, si proporcionas la referencia de tipo para el estado de la sala aquí, tendrás autocompletado para todas las propiedades y todo lo que está dentro del estado durante el desarrollo.

Sí, ¿cuál es la diferencia entre mensajes y estado de sala? Bueno, los mensajes son efímeros y no se almacenan en ningún lugar. Así que cuando envías un mensaje, solo los clientes conectados actualmente lo recibirán. En cambio, el estado es persistente. Si estableces algo en el estado y un nuevo cliente se une, ese nuevo cliente recibirá esos datos. Sí, en los juegos multijugador, la latencia es inevitable y como desarrolladores debemos aceptarla y tratar de mitigar la latencia percibida por el jugador actual. Sí, imagina que tienes al cliente en la posición 10-10, luego envía la acción de mover hacia adelante y el servidor aquí, recibe que está en 11-10, pero el cliente podría haberse movido inmediatamente aquí y recibirá estos datos del servidor solo un par de milisegundos después. Esto se llama tiempo de ida y vuelta, y sí, esto es la mitad de un tiempo de ida y vuelta. Y puedes usar este valor para realizar algunas técnicas en el lado del cliente, para intentar al menos darle al jugador una respuesta inmediata. Este ejemplo de Half the Opposite implementa la predicción en el lado del cliente, que básicamente procesa la entrada de los jugadores inmediatamente en el lado del cliente. Entonces, cada vez que presionas las teclas para moverte, tu jugador se mueve inmediatamente. En el servidor, encola las acciones del jugador y procesa la cola en cada tick del servidor. Sí, puedes echar un vistazo al código fuente allí. También es aplicable si quieres usar este enfoque fuera de Coliseus. Hay una presentación muy interesante de GDC que explica el juego y el netcode de Overwatch. Recomiendo encarecidamente que lo revises. Explican toda la predicción en el lado del cliente que hicieron allí. Y sí, también mencionan algunas técnicas para paquetes perdidos. Y realmente no podemos aplicar ninguna de estas técnicas en WebSockets porque no hay paquetes perdidos en una conexión confiable. Cuando los tengamos en el transporte web, podremos aplicar tales técnicas. La interpolación lineal es muy simple y puede tener buenos resultados. En Mesmora, el juego que hice, utilicé interpolación lineal en todas partes.

5. Limitaciones del servidor, escalabilidad y juegos geniales

Short description:

Observa que este es un juego basado en fichas y el jugador se mueve a través de las fichas con interpolación lineal. Tener una física determinista es importante. Las limitaciones del servidor, como ¿cuántos usuarios concurrentes puede manejar un servidor? Pude lograr eso en un servidor económico, un servidor WebSocket que ejecuta un juego de cartas-tablero que es muy lento en el ritmo de los mensajes, el servidor podría manejar 3K conexiones concurrentes. Las salas en Coliseus tienen estado y los juegos generalmente tienen estado. Hay una capa de persistencia que permite que cualquier nodo haga emparejamiento. Entonces, ¿cuántos usuarios concurrentes puede manejar Coliseus? Depende. Recomiendo evitar tener un estado de sala muy grande y optimizar los bucles de juego para utilizar la menor cantidad de ciclos de CPU posible. Algunos juegos geniales hechos con Coliseus: el juego de Tiny Dolby, el IO Shooter de código abierto, Raft Force, School Break y Kurka.io. Night's Edge de Lightfox Games.

Observa que este es un juego basado en fichas y el jugador se mueve a través de las fichas con interpolación lineal. El paso de tiempo bloqueado es muy importante para un juego basado en física. También se le llama tasa de actualización fija. Tener una física determinista es importante porque entonces podrías tener muchos clientes y el servidor, si es necesario, simulando la física con diferentes FPS y obteniendo el mismo resultado.

Entonces, las limitaciones del servidor, como... odio esta pregunta, ¿cuántos usuarios concurrentes puede manejar un servidor? Quiero decir, puedes encontrar información en Internet de que las personas lograron tener 1 millón de conexiones WebSocket en un solo servidor, pero eso no es muy realista. Podrías lograrlo principalmente con conexiones inactivas, sin intercambiar mensajes, y eso no es realista en absoluto. Lo que pude lograr es que en un servidor económico, un servidor WebSocket que ejecuta un juego de cartas-tablero que es muy lento en el ritmo de los mensajes, el servidor podría manejar 3K conexiones concurrentes. Pero no recomendaría tener una sola sala con tantas conexiones. Lo ideal serían de 50 a 100, y si necesitas más conexiones que eso, puedes tener más salas en otros servidores para manejar esta carga. Entonces, sí, luego entra en juego la escalabilidad. Y la escalabilidad, las salas viven en memoria en Coliseus, por lo que las salas tienen estado y los juegos generalmente tienen estado, por lo que realmente necesitas, no puedes usar enfoques sin estado para, no entiendo cómo la gente siempre recomienda ser sin estado al escalar las cosas. Y hay una capa de persistencia que permite que cualquier nodo haga emparejamiento. Entonces, para resumir, así es como funciona la reserva de semillas en un solo servidor y cuando tienes varios servidores, la solicitud de reserva de semillas llegaría al balanceador de carga y se enviaría a cualquiera de los servidores activos. Y luego cualquiera de los servidores activos devolvería la reserva. Y luego, teniendo esta información, podemos hacer la solicitud WebSocket directamente al servidor en el que vive esa sala. Entonces, ¿cuántos usuarios concurrentes puede manejar Coliseus? Depende. Sí, no lo sé. Depende de tu juego. Tienes límites de CPU y memoria, y todos los tienen, sin importar si estás usando Coliseus o no. Para Coliseus en sí, recomendaría evitar tener un estado de sala muy grande, lo que aumentaría el rendimiento de tus salas, y optimizar los bucles de juego para utilizar la menor cantidad de ciclos de CPU posible. Sí, ya se me está acabando el tiempo aquí. La herramienta adicional que tenemos es este monitor para el desarrollo, puede ser realmente útil. Una prueba de carga para crear pequeños bots y probar hasta dónde pueden llegar tus servidores con pruebas de carga automatizadas.

Algunos juegos geniales hechos con Coliseus. Este fue el primer juego bien hecho con Coliseus por Tiny Dolby, todavía está disponible aquí, creo que se lanzó en 2015. Esto está hecho por la comunidad, se llama el IO Shooter de código abierto, se puede encontrar aquí en este enlace. Raft Force, lo hice con Tiny Dobbins con Default Engine, también es un juego web disponible aquí. School Break hecho por Tobias, también está disponible para jugar aquí. Y Kurka.io es el primer shooter en primera persona que he visto que utiliza Coliseus y es muy divertido. Y finalmente, Night's Edge de Lightfox Games.

6. Unity Game and Poll Results

Short description:

Este es un juego de Unity, también disponible para descargar. Espero que hayas aprendido algo. Echemos un vistazo a los resultados de la encuesta. WebSockets parece ser la opción principal para los juegos multijugador. Socket.io debería haber estado en la lista. Muchas personas están utilizando Coliseus. ¿Qué es Nakama?

Este es un juego de Unity, también disponible para descargar. Y eso es todo. Espero que hayas aprendido algo. Estoy aquí, esperando tus preguntas. Muchas gracias.

Entonces, primero echemos un vistazo a los resultados de la encuesta para la pregunta que hicimos al principio. ¡Oh! Ninguno de ellos. Tenemos. Realmente estaba interesado en eso. Si eso significa que las personas no han creado juegos multijugador, o si lo han hecho y simplemente no utilizaron una de estas opciones. Sí. Porque no sé qué más estarían usando. Sí. Esperaba que WebSockets fuera el líder. Lo siento, continúa. Bueno, así es como interpreto esto. Como para las personas que hicieron, creo, juegos multijugador, suena como si WebSockets fuera la opción principal. Lo cual tiene sentido porque, al menos para mí, solo he hecho cosas en Socket.io, que yo interpreto como, básicamente, solo una capa de framework alrededor de WebSockets. Sí. Oh, sí. Socket.io también debería haber estado en esta lista. Sí, probablemente. Por eso me preguntaba si no estaba. No, está bien. Y luego hay muchas personas que también están usando, lo siento, ¿puedes pronunciarlo, Kolesius? ¿Kolesius? ¿Así se pronuncia? Sí, Kolesius, sí, correcto. Kolesius, sí. Gracias. Genial. Hay muchas personas que también lo están usando.

QnA

Nakama y Desarrollo de Juegos Web

Short description:

¿Y qué es Nakama? Ya están en Go, así que no muchas personas han oído hablar de ello. El proceso de hacer juegos de navegador HTML5 puede diferir de colocar elementos en una pantalla a través de HTML, CSS, etc. Puedes tener un juego regular sin usar Canvas, pero es más común usar Canvas2D o WebGL. Hay muchas opciones de herramientas y frameworks, incluyendo little.js, Pixie.js, Play Canvas y Babylon.

¿Y qué es Nakama? No he oído hablar de ese. ¿Cuál? ¿Perdón? Nakama. Nakama, sí, ya están en Go, así que creo que por eso no muchas personas han oído hablar de ello. Son algo similares, pero ya están en Go. Genial, bueno saberlo.

Genial, creo que ahora podemos pasar a algunas preguntas de la audiencia. Creo que la primera que tenemos es una pregunta más general sobre juegos web. La pregunta dice, ¿qué tan diferente es el proceso entre colocar elementos en una pantalla a través de HTML, CSS, etc., en comparación con hacer uno de estos juegos de navegador HTML5? Y hay una segunda parte. ¿Cómo describirías el actual ecosistema de herramientas y frameworks para construir este tipo de juegos de navegador? Especialmente aquellos juegos retro o similares a juegos. Sí, depende mucho. No estoy seguro de cómo responder a esta pregunta, pero puedes tener un juego regular sin usar Canvas en absoluto si logras hacerlo. Puede ser más complicado, pero es posible. Por lo general, usarías Canvas2D o WebGL para renderizar cosas en tiempo real. ¿Cuál es la segunda parte de la pregunta? Es solo cómo describirías las herramientas y frameworks actuales del ecosistema. Tal vez otra forma de expresarlo, ¿qué frameworks usas o recomendarías? Actualmente hay muchas opciones, de hecho. Recientemente tuvimos una charla sobre little.js. Es una herramienta que podrías usar. Creo que por lo que vi en esa charla, es principalmente para salidas muy pequeñas, así que usarías eso. Eso podría ser utilizado posiblemente para esos juegos publicitarios que ves. No estoy muy seguro. Solo estoy asumiendo que es pequeño. Pero sí, personalmente me gusta usar Pixie.js. Creo que mañana tendremos una charla sobre Play Canvas. Play Canvas también es muy bueno para 3D y tuvimos una charla sobre Babylon. Hay tantas opciones. Es difícil contar, en realidad. Sí. También apoyo a Play Canvas porque me gusta. Además, si estás acostumbrado a tener un editor y cosas donde puedes colocar cosas, creo que eso ayuda mucho.

Predicción del lado del cliente e Integración con Unity

Short description:

La predicción del lado del cliente en juegos multijugador puede ser complicada. Implica ejecutar acciones en el lado del cliente antes de recibir confirmación del servidor. Este enfoque permite una respuesta inmediata a las acciones del jugador, pero puede generar desafíos con la colisión entre jugadores. Juegos como Brawl Stars y League of Legends no tienen colisión entre jugadores debido a su complejidad. Los usuarios de Unity pueden utilizar Coliseus con un cliente dedicado y hay juegos hechos con Unity que utilizan Coliseus.

Play Canvas hace eso. Genial. Tenemos otra pregunta en general sobre la predicción del lado del cliente y cómo funciona. ¿Puedes hablar un poco sobre eso?

Sí, eso puede ser complicado. Muy recientemente, escribí un lado del cliente solo para movimientos simples. Por ejemplo, también depende de cómo sea tu entrada. Por ejemplo, si estuvieras usando tu teclado como entrada, generalmente enviarías un mensaje en cada cuadro, lo cual puede sonar un poco ridículo, pero así es como funciona. Quiero decir, ¿cuál es un enfoque para esto? Y luego, no puedo explicarlo correctamente, me faltan las palabras, pero básicamente estás tratando de ejecutar en el lado del cliente antes de que el servidor realmente envíe el mensaje donde el objeto se encuentra en el servidor. Entonces, tal vez una forma de pensarlo, porque creo que mencionaste esto un poco en tu charla, donde tienes un jugador y el ángulo del jugador y el jugador quiere moverse hacia adelante. Y en lugar de esperar a que el servidor diga que estarás en esta posición, puedes asumir que te moverás hacia adelante. Y luego, cuando lo recibas de vuelta, puedes decir eso. Sí. Tiene sentido. Y lo que puede ser un poco complicado de esto es que, digamos que mueves tu cliente hacia adelante, pero tienes otro... Es por eso que es realmente complicado tener colisión entre jugadores en juegos multijugador. Por ejemplo, ves tantos juegos multijugador que no tienen colisión entre jugadores porque es complicado. Es complicado. Como Brawl Stars, como la mayoría de los juegos de apuntar y hacer clic como Dota. Creo que League of Legends tampoco lo tiene, no estoy seguro. Pero tienes tu simulación local y, como, ¿en qué cliente debería confiar este servidor? Es fácil desalinearse. Sí. Genial. No, tiene sentido. Eso suena mucho más complicado. Obviamente, eso conlleva un compromiso de que se verá mejor si puedes lograr eso, porque entonces parecerá que hay menos retraso.

Creo que tenemos una pregunta más. Alguien está preguntando sobre Unity. Si están usando Unity, ¿es posible usar Coliseus? ¿Hay un complemento o una forma de usarlo con soporte para Unity WebGL?

Sí, es posible. Hay un cliente disponible para Unity. Y sí, hay un juego que se hizo con Unity.

Disponibilidad de Coliseus y Conclusión

Short description:

Coliseus está disponible en dispositivos móviles y se puede encontrar en colossus.io o en el repositorio de GitHub, que proporciona todos los enlaces e información necesarios.

Está disponible en dispositivos móviles. Es realmente genial. Increíble. Y si quisieran encontrarlo, ¿estarían en GitHub o en la página web, la Unity? Sí, está en colossus.io. Y desde el repositorio de GitHub, puedes encontrar prácticamente todos los enlaces, toda la información.

Increíble. Bueno, creo que es todas las preguntas que tenemos. Muchas gracias, Endo. Fue genial tenerte aquí. Genial. Muchas gracias por recibirme.

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.
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Building Fun Experiments with WebXR & Babylon.js
Top Content
During this session, we’ll see a couple of demos of what you can do using WebXR, with Babylon.js. From VR audio experiments, to casual gaming in VR on an arcade machine up to more serious usage to create new ways of collaboration using either AR or VR, you should have a pretty good understanding of what you can do today.
Check the article as well to see the full content including code samples: article. 
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! ⚡️

Workshops on related topic

JSNation 2023JSNation 2023
116 min
Make a Game With PlayCanvas in 2 Hours
Featured WorkshopFree
In this workshop, we’ll build a game using the PlayCanvas WebGL engine from start to finish. From development to publishing, we’ll cover the most crucial features such as scripting, UI creation and much more.
Table of the content:- Introduction- Intro to PlayCanvas- What we will be building- Adding a character model and animation- Making the character move with scripts- 'Fake' running- Adding obstacles- Detecting collisions- Adding a score counter- Game over and restarting- Wrap up!- Questions
Workshop levelFamiliarity with game engines and game development aspects is recommended, but not required.
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.
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas End-to-End : the quick version
Top Content
WorkshopFree
In this workshop, we’ll build a complete game using the PlayCanvas engine while learning the best practices for project management. From development to publishing, we’ll cover the most crucial features such as asset management, scripting, audio, debugging, and much more.
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.