Analizar, no validar

Rate this content
Bookmark
La mayoría de las aplicaciones JavaScript utilizan JSON.parse para crear cualquier objeto primero, y luego validar y estrechar el tipo de datos al esperado. Este enfoque tiene problemas de rendimiento y seguridad, ya que incluso si los datos no son válidos, toda la cadena JSON debe ser analizada primero antes de que los datos sean validados, en lugar de fallar en la etapa de análisis JSON (por ejemplo, si se pasa un número en lugar de una cadena en alguna propiedad).

Muchos lenguajes admiten el análisis de cadenas JSON directamente en los tipos esperados, pero no es compatible de forma nativa en JavaScript o TypeScript.

En esta charla mostraremos cómo se pueden utilizar las capacidades de TypeScript combinadas con la nueva especificación JSON Type Definition (RFC 8927) y la biblioteca Ajv para analizar sus datos directamente en el tipo definido por la aplicación más rápido que JSON.parse, y también cómo serializar datos de un tipo conocido aproximadamente 10 veces más rápido que JSON.serialize.

26 min
17 Apr, 2023

Video Summary and Transcription

Hola. Hoy vamos a hablar sobre JavaScript y cómo garantizar la corrección de los datos. JSON puede ser ineficiente y tiene problemas de seguridad, pero Fastify aborda estos desafíos. JTD es mejor que JSON Schema para la mayoría de los casos de uso de API, ya que tiene una estructura más estricta y evita problemas de depuración. Jason demuestra cómo validar datos con JTD y TypeScript, garantizando la validez de los datos y mejorando el rendimiento. El enfoque de analizar JSON directamente en el tipo de aplicación y serializar un tipo específico mejora la seguridad y confiabilidad.

Available in English

1. Introducción a JavaScript y Corrección de Datos

Short description:

Hola. Hoy vamos a hablar sobre JavaScript y cómo asegurar la corrección de datos. Hemos trabajado juntos en varios proyectos, incluyendo MailOnline y Threads. Voy a pasarle la palabra a Jason para que se presente. Jason es el director de tecnología en Threads Styling y tiene una amplia experiencia en validación de datos utilizando JSON Schema. Nos hemos encontrado con problemas comunes en nuestros proyectos, como seguridad, confiabilidad y validación de datos. Discutiremos un enfoque alternativo para la validación que implica analizar y llevar la prueba de validez. JSON, aunque flexible, tiene sus desafíos y puede ser derrochador.

Hola. Soy Evgeniy y este es Jason. Hoy vamos a hablar sobre JavaScript y cómo asegurar la corrección de datos pero antes daremos una breve introducción. Así que hemos hecho muchas cosas geniales juntos. Trabajamos juntos en MailOnline, en Threads, y cuando hice la biblioteca de Java, Jason también ayudó mucho. Actualmente, fundé Simplex Chat, que es una plataforma de mensajería única en su tipo que no tiene identificadores de usuario, pero de eso no trata la charla. Así que le paso la palabra a Jason para que se presente. Gracias, Evgeniy. Obviamente, ya saben que soy Jason Green, soy el director de tecnología en Threads Styling. Threads es una empresa de moda tecnológica que lidera el mundo de las compras de lujo personalizadas a través de chat y redes sociales. También trabajé anteriormente con Evgeniy como ingeniero principal en MailOnline. He sido usuario de validación de datos con JSON Schema durante mucho tiempo y en particular utilizando AJV, que he visto crecer y madurar mucho a lo largo de los años. También soy inversor temprano en Simplex Chat. Sí, el crecimiento de AJV ha sido realmente increíble, pasó de ser prácticamente nada en 2015 cuando comenzó, y ahora tiene 350 millones de descargas cada mes, con cada aplicación de JavaScript probablemente todos lo usen. Entonces, ¿por qué queremos hablar de lo que hablamos, verdad? En todos estos proyectos que hemos hecho y hemos hecho cosas realmente geniales, ¿verdad? Hicimos un creador de contenido en MailOnline cuando ya éramos bastante maduros y, sin embargo, construimos una aplicación muy compleja en el navegador con cientos de miles de líneas de código de JavaScript que permitía la edición. Todo el sitio web de MailOnline es gestionado por eso. Y luego, cuando estaba trabajando en Threads y Jason también se unió a Threads, construimos StoryMaker. Principalmente Jason lo construyó, yo solo me deleito con la gloria. Era un sistema de gestión de contenido para Instagram, del cual definitivamente aprendimos muchas cosas del proyecto anterior. Y en todos esos proyectos que hicimos, nos encontramos inevitablemente con los mismos problemas de seguridad, confiabilidad, validación de datos, sin importar el proyecto que hagamos, los problemas son invariablemente los mismos. He trabajado mucho con Haskell, y este enfoque de parse.don't.validate.maxim pertenece a Alexis Kane, uno de los mejores y más geniales ingenieros de Haskell que existen, quien propone el enfoque de análisis como una alternativa a la validación. Así que en lugar de simplemente verificar que tus datos sean correctos, empujas la prueba y llevas la prueba de validez contigo. No solo correctos, no solo verificar que tus datos sean correctos, sino también obtener alguna prueba como si estuviera en algún tipo diferente y usarla en toda tu aplicación. Así que voy a pasarle la palabra a Jason. Y en esta clase con JavaScript, lo que aprenderemos es que realmente no deberías estar usando JSON nativo en JavaScript. Deberías estar haciendo otras cosas. Jason, te toca a ti.

Como todos sabemos, JSON es un formato ampliamente utilizado que generalmente se considera flexible y fácil de trabajar. Sin embargo, es importante tener en cuenta algunos de los problemas potenciales y

2. Desafíos con JSON y la importancia del rendimiento

Short description:

Pasar JSON puede ser derrochador ya que necesitas pasar todos los datos antes de verificar su validez. JSON tiene problemas de seguridad y puede agotar la pila de llamadas con estructuras profundas o ser utilizado en ataques de denegación de servicio (DDoS). El rendimiento y la confiabilidad son importantes dependiendo de la situación, especialmente cuando afecta la experiencia y satisfacción del usuario. Fastify es una biblioteca que aborda la serialización al definir entradas y salidas en JSON Schema, aumentando la velocidad y mejorando el manejo de la estructura de datos.

Los desafíos que presenta. JSON es particularmente derrochador. Ahora, no es algo que vayas a notar en tu depuración diaria cuando estás trabajando con él, pero pasar JSON puede ser un proceso muy derrochador, ya que necesitas pasar toda la pieza de data antes de poder entender o incluso comenzar a verificar si es válido o no. Debido a la naturaleza potencialmente compleja y anidada de JSON, puede ser especialmente lento validar. Muchos de nosotros que comenzamos en JavaScript hemos llegado a amar trabajar con TypeScript, pero luego lanzas un gran bloque de JSON no estructurado en la mezcla, y de repente, vuelves al punto de partida. Ninguno de tus tipos importa y todo vuelve a ser desconocido. También tiene algunos problemas de seguridad. Estos son problemas de los que en realidad no estaba muy consciente a pesar de trabajar con él durante mucho tiempo, hasta que investigué al respecto. Si tienes estructuras muy, muy profundas, pueden agotar tu pila de llamadas. Esto puede ser simplemente debido a los data en sí, o puede ser un ataque deliberado con estructuras muy profundamente anidadas enviadas a tus APIs. También puedes sufrir de grandes bloques de data enviados a tus APIs en forma de un ataque DDoS. Una vez más, antes de poder entender si es válido o no, tu API deberá pasar esos bloques, lo cual una vez más es muy derrochador. También es posible realizar ataques de contaminación de prototipos a través de JSON.

Entonces, antes de preocuparnos por el rendimiento y la confiabilidad, es importante pensar en cuándo el rendimiento y la confiabilidad son realmente importantes. Parece una afirmación obvia. Sabes, la mayoría de las personas no se molestarían en argumentar que no es importante, pero no será importante para todas las situaciones. Realmente depende de varios factores. Obviamente, una aplicación lenta es mejor que ninguna aplicación en absoluto. Entonces, si tienes una aplicación que brinda valor, es posible que tengas problemas mucho más grandes que debas enfrentar antes de preocuparte por el rendimiento y la confiabilidad. Especialmente en las etapas iniciales del desarrollo de la aplicación, estarás mucho más preocupado por el tiempo de comercialización. Si tu aplicación ni siquiera está disponible todavía, obviamente eso es un gran problema. Te preocuparás por el presupuesto, la experiencia de usuario general de tu aplicación y, por supuesto, cuáles son las necesidades de tus usuarios y qué es lo más importante para ellos. Sin embargo, será un problema cuando el rendimiento afecte la experiencia del usuario y la satisfacción. Eso puede hacer que pierdas usuarios y aquellas personas que se alejen de tu aplicación o sitio porque no se cargó lo suficientemente rápido, es posible que no vuelvan lo cual obviamente se conoce como altas tasas de rebote. Aún peor, si la confiabilidad es tu problema y tus clientes pierden su trabajo o sus data se corrompen, eso es un gran problema que, en el mejor de los casos, puede resultar en algunas disculpas. En el peor de los casos, es posible que incluso tengas que pagarlo de alguna manera a través de compensación o descuentos para mantener a las personas contentas. Entonces, en realidad hay una solución a parte de este problema, que es abordado por una biblioteca llamada Fastify, que es un reemplazo para tu enrutador Express. Aborda la parte de la serialización del problema, es decir, al definir las entradas y salidas y su estructura en JSON Schema, esta biblioteca es capaz de serializar las respuestas de manera más rápida y puede obtener un aumento considerable en la velocidad porque se enfoca en ... porque conoce la estructura de los data que se supone que debe devolver. De esta manera, puede tomar mucho de lo que normalmente serían bucles y convertirlos en acceso directo a propiedades. Entonces, si hablamos de esquemas, durante mucho tiempo JSON Schema fue la única forma de definir el formato de los data o el tipo de los data o como quieras llamarlo. Comenzó en 2009 y desde 2020 existe una especificación alternativa que se creó para abordar las deficiencias.

3. JTD vs JSON Schema: Pros, Cons, and Debugging

Short description:

JTD es mejor que JSON Schema para la mayoría de los casos de uso de API. En los casos en que JTD es peor, considera escribir código en lugar de usar un esquema. JSON Schema puede generar problemas de depuración debido a su interpretación de los esquemas, causando confusión y errores.

Puedes pasar bastante tiempo comparando los pros y los contras de dos especificaciones. Puedes verlo más tarde y hacer una pausa. Fundamentalmente, JTD se define por su simplicidad y una de las cualidades importantes es que admite uniones discriminadas. Pero al mismo tiempo tiene limitaciones en el soporte, pero está extremadamente alineado con los tipos de datos, a diferencia de JSON Schema.

JSON Schema, por otro lado, tiene una adopción extremadamente amplia en la actualidad. JTD es parte de algunas especificaciones de API, pero al mismo tiempo no admite uniones discriminadas y no define JTD. Es una comparación larga. Es un compromiso no trivial y lo uso de primera mano con la biblioteca HLB que admite ambas especificaciones. Entonces, para pasar a la recomendación que puedo dar, JTD es realmente mucho, mucho mejor para la gran mayoría de los casos de uso en una API. Entonces, si estás construyendo una API, deberías usar JTD, punto final. Y para los casos en que JTD sea realmente peor que JSON Schema, es una gran pregunta si deberías usar un esquema en absoluto. Probablemente deberías escribir código y usar un esquema.

Así que voy a demostrarlo con algunos ejemplos de una manera divertida. Correcto. Así que titulamos esto como lógica de definición de tipo JSON frente a JSON schema qué. Entonces, si recuerdas esos memes internos, era qué. ¿Qué es eso? Así que si miras este esquema. Entonces, qué define. La mayoría de los ingenieros de software descubrirían cualquier esquema y dirían que esto es una cosa, obviamente es un objeto. ¿Qué más puede ser? Y tiene una propiedad y la propiedad obviamente debe ser una cadena. Y eso es cómo JTD trata este esquema. JSON Schema tiene una visión interesante. Si el data resulta ser un objeto y tiene esta propiedad, entonces esto debe ser una cadena y cualquier otro data será válido en JSON schema, lo que significa que cualquier número o cualquier cadena o matriz u objeto que no tenga la propiedad foo será válido. Esto ha causado millones de horas de depuración a varios ingenieros y he estado respondiendo, como en la biblioteca Azure, probablemente el 50% de las preguntas son sobre este tipo de problemas, ¿verdad? O por ejemplo, esto es un error tipográfico, ¿verdad? Claramente, aquí se ha escrito mal la palabra properties y JTD responde correctamente. Este esquema es simplemente inválido. ¿Qué más puede ser? Bueno, JSON Schema tiene una visión. JSON Schema cree que este es un esquema válido. Simplemente tiene alguna propiedad que no sabemos qué significa. Y cualquier data es válido según este esquema. Nuevamente, se han gastado millones de horas depurando errores como este en JSON schemas.

4. JTD Structure and JSON Schema Flexibility

Short description:

JTD tiene una estructura más estricta para los arrays, requiriendo objetos como elementos con propiedades específicas. Por otro lado, JSON Schema permite más flexibilidad, lo que conduce a problemas de depuración. JSON Schema es propenso a errores y a menudo requiere anotaciones adicionales o el uso de modo estricto. JTD es más simple y a menudo una mejor opción para tu código.

O por ejemplo, para los arrays, ¿verdad? Entonces, JTD tiene esta estructura de array. Entonces, estos data deben ser un array, obviamente deben tener objetos como elementos, y estos objetos deben tener la propiedad foo y esta propiedad debe ser una cadena, por lo que hay muchos requisitos estrictos en la forma del data, ¿verdad?

Entonces, si tienes un esquema similar en JSON Schema, la única diferencia es la palabra clave. Bueno, ¿qué significa realmente? Oh, bueno, uno puede suponer que el data no tiene que ser un array. Y el data no tiene que tener todos los elementos como objetos. Y si son objetos, no tienen que tener la propiedad foo, como diferentes tipos de data pueden ser válidos según este esquema, lo que nuevamente causa muchos problemas de depuración, ¿verdad? Y la conjetura es así, ¿verdad?

Entonces, ¿qué pasa si ponemos corchetes cuadrados aquí? Pensé que eso era un array. ¿Por qué no pones corchetes cuadrados? Bueno, JTD simplemente dice que es un esquema inválido. En JSON Schema, desafortunadamente, esto es válido y solo valida el primer elemento e ignora todos los demás elementos. Y es una pregunta de soporte excepcionalmente común en AGV y se gastan millones de horas depurando errores como ese. Entonces, fundamentalmente, JSON Schema es una especificación excepcionalmente propensa a errores que requiere muchas anotaciones adicionales para expresar lo que realmente quieres expresar. AGV encontró una solución que resultó ser extremadamente popular llamada modo estricto. Básicamente, haces que todos esos casos sean errores, lo cual es una extensión o desviación de la especificación de JSON Schema y la gente lo usa. Pero fundamentalmente significa que JTD es más simple y en muchos casos es mejor para tu código.

5. Validando Datos con JTD y TypeScript

Short description:

Jason te mostrará cómo hacer magia con JTZ y TypeScript para la validación y el análisis de datos. Con JTD, el proceso es más intuitivo y sencillo. Sumergámonos en un ejemplo de objeto anidado: un personaje de Mario Kart. Definiremos el esquema para los datos del personaje, incluyendo propiedades como nombre, apellido, peso, fecha de creación y un array de armas. Utilizando la utilidad JTD Schema Type, podemos asegurarnos de que el esquema creado sea válido para este tipo de datos.

Pero ahora pasemos a Jason, quien te mostrará cómo hacer magia con JTZ y TypeScript y realizar en realidad alguna validación y análisis de datos.

Muy bien. Es hora de ver algo de código. Solo un comentario sobre algunos de los puntos que mencionó Evgeny. Después de haber trabajado con muchos esquemas JSON, terminamos construyendo muchas cosas en torno a estas decisiones y lleva mucho tiempo resolver todos esos problemas. Con JTD encontré que es mucho más intuitivo, simple y directo.

Así que echemos un vistazo. Obviamente, hay muchos tipos diferentes de datos que se pueden validar. Voy a ir directamente a un objeto anidado con la suficiente complejidad como para ser un buen ejemplo para ver cómo construimos un esquema para él. Últimamente he estado jugando mucho a Mario Kart con mi familia. Sorprendentemente, mi esposa también es bastante buena en eso y ambos estamos jugando mucho a Mario Kart. Así que no se me ocurrió otro ejemplo que un personaje de Mario Kart.

Entonces, si tenemos nuestro personaje, estos son nuestros datos. Dije, bueno, este es nuestro tipo, nuestra interfaz. Tiene un nombre, un apellido opcional. Todos conocemos los personajes de Mario Kart. Tienen un peso. Los más pesados son los mejores, obviamente. Tenemos createdAtDate, solo para darnos un ejemplo aquí. Y obviamente tenemos un array de armas. Cada arma tiene un ID, un nombre de arma, que es un enum, y un contador de daño que indica cuánto daño causará esta arma. Voy a borrar todo esto, porque quiero mostrar el proceso de escribir el esquema más que cualquier otra cosa. Porque tenemos este tipo de utilidad muy interesante que viene con AGV, se llama JTD Schema Type. Y cuando usamos este tipo, pasando nuestro personaje de Mario Kart, solo nos permitirá crear un esquema que sea válido para este tipo de datos en particular. Así que realmente no tengo que, quiero decir, puedo empezar escribiendo, escribiendo. No, en realidad, no sé. Bueno, en realidad no sé cómo escribir un esquema todavía. Así que puedo ir directamente a mi, ya sabes, autocompletar y activar, ¿cómo se llama?, olvidé el nombre, pero activar las propiedades posibles que puedo tener aquí. Y tenemos un valor de propiedades. Así que vamos a necesitar eso para empezar.

6. Definiendo Propiedades de Objetos y Arrays

Short description:

Al definir un objeto, especificas las propiedades que debe tener. Comienza por definir el tipo, como string o date. Se admiten propiedades opcionales y también puedes definir números con diferentes tipos. El esquema garantiza la validez de los datos, permitiendo valores nulos. Los arrays se pueden definir especificando los elementos y propiedades anidadas.

Eso se debe a que al definir un objeto, así es como se hace con las propiedades, propiedad. Suena terrible, pero entiendes la idea. Si vuelvo a activar, ahora podemos empezar a poner las propiedades reales que nuestro personaje de Mario Kart necesita tener definidas.

Te darás cuenta de que falta el apellido aquí, pero llegaremos a eso en un segundo. Vamos a empezar poniendo un par de estas definiciones. Necesitamos un tipo obviamente, y el tipo de este es, bueno, en realidad puede ser una de dos cosas, pero en nuestro caso es string. En este caso, verás que cuando intento poner el tipo createdAt, solo me da la opción de date. Esta vez ya no me permite poner un string, y eso es porque sabe que en este tipo de personaje de Mario Kart, createdAt es una fecha. Por último, tenemos las armas.

Voy a definir eso en un segundo, porque primero quiero saltar a cómo definimos el apellido. El apellido es una propiedad opcional. Y si vuelvo a ver mis predicciones, tenemos propiedades opcionales. Y aquí, tan pronto como empiezo a escribir S, también aparece apellido. Así que todo es muy intuitivo. Y a partir de este punto, es exactamente igual que cualquier otra propiedad que estés definiendo. También olvidé que también tenemos el peso del personaje y este es un número. Y como puedes ver, hay una gran variedad de tipos de números que podemos admitir en JDT, JTD. Voy a ir con, dado que es peso, creo que U int ocho tendría sentido. Solo un entero positivo. ¿Lo tengo correcto? Oh sí. Esta es la mejor parte de esto. No es válido. No es correcto. Este peso no cumple con los requisitos de este tipo en el esquema. Y eso es porque he hecho que el peso pueda ser un valor nulo también. Así que aquí tenemos que pasar nullable true. Y entonces también será válido.

Armas. Así que cuando queremos definir un array, creo que recordarás del ejemplo que mostró Evgeniy antes, es elements, y a partir de ese punto, una vez más, solo estás definiendo, es más del mismo esquema. Es una especie de valor anidado ahora, por lo que también en este caso, queremos propiedades porque este es un array de objetos para definir un objeto en JTD, propiedades únicas y una vez más podemos seguir poniendo los demás valores tipo que es número ID.

7. Tipo Enum para Nombre

Short description:

En este caso, tenemos un nuevo tipo llamado nombre, que es un enum ad hoc. Pasamos todos los posibles valores como un array, y la predicción del tipo se basa en el tipo definido.

Voy a ir incluso 32 y nombre. Entonces, el nombre en este caso, este es otro nuevo tipo con el que nos hemos encontrado. Hemos hecho esto un enum. Um, esto es en realidad más un enum ad hoc en lugar de usar la palabra clave enum en TypeScript. Y así, en este caso, solo necesitamos pasar todos los posibles valores para este enum. Y eso está en forma de un array. Como puedes ver, comienza a predecir cuáles son los posibles valores. Lo sabe a partir del tipo que hemos definido, lo cual es realmente útil. Y caparazón rojo.

8. Serialización y Análisis con el Esquema de MarioKart

Short description:

Finalmente, tenemos daño, que es otro número. Podemos serializar datos utilizando un serializador alineado con el tipo para el esquema de MarioKart, que es 10 veces más rápido que usar un serializador regular. También podemos analizar datos utilizando un analizador generado a partir del esquema, que devuelve el tipo esperado o undefined si los datos no son válidos. Este enfoque de analizar JSON directamente al tipo de aplicación y serializar un tipo específico mejora el rendimiento y la confiabilidad.

Finalmente, tenemos daño, que es otro número. Uh, vamos a hacer esto un float 32. Así que también podemos tener puntos decimales. Y ese es el esquema completo ahora definido.

Entonces, ¿qué podemos hacer sin el esquema de MarioKart? Um, podemos serializar data. Así que si tomo, uh, si, si tengo algún, ya sabes, objeto JavaScript definido, uh, que cumple con este data, bueno, que cumple con este tipo, puedo crear un serializador a partir de mi esquema de MarioKart. Um, disculpas. Esto es de un ejemplo anterior. Oh, Dios mío. Aquí está nuestro serializador de MarioKart, ahora podemos pasar tanto data como queramos, y se serializará 10 veces más rápido que, uh, usando este serializador alineado con el tipo que hemos creado. También podemos, por supuesto, analizar, disculpen, aquí hay una cadena con un string JSON de datos de personaje de MarioKart. También podemos compilar un analizador utilizando nuestro esquema. Y la mejor parte de esto es que sabe el tipo que esperamos de esto. Uh, cuando usamos este analizador para analizar realmente esta cadena, el tipo resultante va a ser o bien personaje de MarioKart o undefined. Undefined si está, uh, básicamente va a ser el caso si los data están de alguna manera inválidos. Y así, si los data no son inválidos y tenemos un resultado, entonces sabemos que estos son datos de Mario Kart. Tenemos todos nuestros typings configurados. Podemos comenzar, obtenemos nuestra ayuda de tipo. Um, podemos estar seguros de los data que se han definido aquí y simplemente hace que todo nuestro código a partir de ese punto sea mucho más fácil. Y por supuesto, si es undefined, entonces podemos consultar el mensaje de error a través de la propiedad en la función de paso.

Entonces, uh, sí, creo que eso es todo para el ejemplo de código. Esto es realmente genial y emocionante. Así que en realidad no creé, creé una utilidad de tipo similar para el esquema de Jason y, uh, una utilidad de tipo equivalente que Jason acaba de presentar fue creada por algún ingeniero de JavaScript excepcionalmente brillante. Él contribuye a la charla por su cuenta. Pero eso te da un gran poder en TypeScript porque este enfoque de analizar Jason directamente al tipo de aplicación en lugar de en alguna estructura genérica de data es, o, y al contrario, serializar un tipo específico en lugar de serializar una estructura genérica de data, uh, se utiliza en todos los lenguajes, casi todos los lenguajes, ¿verdad? Haskell, Go, Rust, como una estructura genérica de datos de Jason se utiliza generalmente en lenguajes de script, como JavaScript y Python, pero socava fundamentalmente el rendimiento y la confiabilidad y el uso de analizadores que están alineados con el tipo, uh, que son, uh, resulta en alta seguridad y alto rendimiento al mismo tiempo. Entonces, como dijo Jason, compilar serializar. Así que el serializador compilado genera en realidad códigos JavaScript bajo el capó. Entonces, si se usa repetidamente, te brinda un impulso de rendimiento de 10 veces en comparación con la serialización y el análisis de Jason. Uh, si los data son válidos, entonces se analizará en prácticamente el mismo tiempo que el análisis de Jason, pero lo validará a medida que avanza. Pero por ejemplo, si alguien envía un arreglo en lugar de un objeto, fallará en el primer carácter.

9. Mejora de la Seguridad y Alineación de Tipos

Short description:

El analizador falla en el primer carácter no válido en la cadena JSON, mejorando la seguridad y el rendimiento. Se ha utilizado en aplicaciones a gran escala, incluyendo Wastestream. Para el proyecto Storymaker, se generaron esquemas JSON a partir de tipos para la alineación de tipos. JTD y AJA facilitan tu trabajo, aseguran tu API y te ahorran tiempo en comparación con las alternativas.

Si alguien envía una propiedad que no está permitida o de un tipo incorrecto, data el analizador no analizará toda la estructura de datos que puede ser enorme. Simplemente fallará en el primer carácter no válido en la cadena JSON, lo cual te brinda una mejor defensa contra cualquier tipo de ataque y nunca terminarás con propiedades que no esperas en tus data que pueden resultar en contaminación del prototipo o en cualquier otro sentido.

Entonces esto realmente ha mejorado mucho la seguridad y el rendimiento. Y hasta ahora sé que se ha utilizado en aplicaciones a gran escala, incluso Wastestream, donde actualmente se utiliza en sus oficinas para devolver los resultados. Fue en mi empresa anterior cuando lideraba el equipo de ingeniería. Fueron amables al permitirnos hacerlo. También utilizan este enfoque, así que lo hicimos cuando estaba aquí.

Entonces, sabes, una nota más que tenía era que para el proyecto Storymaker, construimos todo el estado de las historias individuales que creas, todo se gestiona en el servidor. Y hay mucho intercambio de ida y vuelta de grandes piezas de JSON. Y construimos, hicimos toda la validación con esquemas JSON. Sin embargo, porque queríamos que estuviera alineado con los tipos, lo que terminamos haciendo fue algo similar de manera indirecta, en el sentido de que generamos esquemas JSON a partir de nuestros tipos. Y no teníamos ningún esquema JSON que hiciera algo que no se pudiera hacer en el tipo de TypeScript de todos modos. Porque no queríamos eso. No queríamos tener que dudar de las cosas y tener una inconsistencia allí. Entonces, sí, creo que es la forma correcta de hacerlo y puede parecer más restrictivo en lo que puedes hacer con ello, pero estoy de acuerdo. Estoy de acuerdo con tu afirmación anterior. Esas cosas probablemente no deberías hacerlas en un esquema de todos modos. Así que sí, JTD es divertido. AJA lo hace excepcionalmente poderoso. Así que úsalos a ambos. Eso facilitará tu trabajo y tu API será más segura y te ahorrarás muchas horas perdidas en depuración en comparación con las alternativas. Esa es nuestra recomendación de esta charla. Gracias. 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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
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 Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
We don't think of React as shipping its own types. But React's types are a core part of the framework - overseen by the React team, and co-ordinated with React's major releases.In this live coding talk, we'll look at all the types you've been missing out on. How do you get the props type from a component? How do you know what ref a component takes? Should you use React.FC? And what's the deal with JSX.Element?You'll walk away with a bunch of exciting ideas to take to your React applications, and hopefully a new appreciation for the wonders of React and TypeScript working together.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Workshop
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
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 + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session 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.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher