Analizar, no validar

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

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.

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.

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.

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.

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.

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.

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.

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.