Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de la supermodelo


 Quizás uno de los elementos más importantes de cualquier implementación que aproveche los datos es el modelado real de los datos en sí. Los datos solo son útiles cuando se comprenden y contextualizan, cuando en última instancia se comparten o se convierten en información. No modelar realmente estos datos de una manera comprensible es perjudicial y puede obstaculizar seriamente cualquier esfuerzo para desarrollar un producto. Además, hace que cualquier producto que se desarrolle sea más difícil de compartir e iterar, esencialmente obstaculizando el desarrollo a escala macro.

La supermodelo tiene como objetivo solucionar este problema. Hoy, vamos a echar un vistazo a Supermodelo para ver qué es y qué problema pretende resolver. Veremos algunos ejemplos de la experiencia del usuario en Supermodel y postularemos un caso de uso en el que Supermodel tendría sentido. También nos sentamos con el creador de Supermodel y ex orador de las API nórdicas,  Zdenek “Z” Nemec , ¡y compartiremos algunos de sus pensamientos!

¿Qué es la supermodelo?

Supermodel , un proyecto de Good API , es en realidad dos partes distintas que forman un todo mayor: Supermodel.io es un registro de esquemas para modelos de datos y Supermodel CLI es un diseño de herramienta de código abierto para trabajar con estos modelos de esquemas. Dicho esto, Supermodel se puede definir aproximadamente como una herramienta colaborativa para modelar datos y compartir esos datos a través de un registro confiable. Supermodel usa un esquema JSON en el formato YAML para sus definiciones de modelos de datos y define estos modelos de datos a través de un esquema de intercambio. Los modelos pueden crearse directamente en el registro de Supermodel.io o almacenarse localmente y luego enviarse al registro mediante la CLI de Supermodel.

En esencia, Supermodel se preocupa principalmente por proporcionar un método para modelar datos y luego presentar esos datos en una variedad de formatos digeribles y comúnmente compatibles. Funciona con una amplia variedad de formatos, incluidos JSON , GraphQL , JSON-LD y Open API Specification , entre otros como Kafka . Cuando se generan estos modelos, se pueden publicar en el registro y, en ese momento, los que están dentro del ecosistema Supermodel.io pueden buscarlos y reutilizarlos. La CLI de Supermodelo es distinta del registro en sí, pero es una herramienta fundamentalmente importante en ese proceso, ya que convierte desde varios formatos y permite la referencia o el consumo directo de dichos esquemas.

Quizás el mejor resumen de esta oferta se puede encontrar en el anuncio de Z, su creador:

"Los objetivos clave de Supermodel son promover el modelado de datos de hoy en día, administrar dominios complejos, mejorar la comunicación y permitir el descubrimiento y la reutilización de modelos de datos".

¿Qué problema está tratando de resolver la supermodelo?

Antes de que podamos ver en detalle lo que hace Supermodel (y cómo lo hace), primero debemos mirar el problema que está tratando de resolver. A lo largo de toda su documentación y su anuncio inicial, el principal problema que plantea Supermodel es la naturaleza de la documentación de la estructura de datos y la disponibilidad de información semántica. En esencia, el argumento que hace la supermodelo es que los modelos de datos formales son raros y, si existen, a menudo están incompletos. Es más probable que las organizaciones más pequeñas no se molesten en absoluto con las definiciones de modelos de datos formales, y con organizaciones más grandes, estos modelos a menudo se ven afectados indeleblemente por los antiguos monolitos y los “modelos de datos canónicos” que surgen del desarrollo empresarial tradicional.

"Hay cada vez más API, pero el problema en este momento son los modelos de datos en sí mismos y la comprensión de los datos en general".

En ambos casos, los modelos de datos, si están presentes, no coinciden con los modelos de datos de producción reales y dan lugar a problemas que se propagan por el camino de la implementación. Con la falta de formalización del modelo de datos, falta documentación. Con una documentación deficiente, se obtiene un conocimiento escaso en torno a los principales modelos de datos que impulsan el sistema subyacente, y con respecto a las integraciones de producción, un desarrollo de API deficiente y una comprensión deficiente. De hecho, existe el argumento de que asignar a la API la tarea de formalizar las representaciones de datos del modelo de datos subyacente en realidad expone los marcos internos y los modelos de base de datos de una manera dañina; en esencia, sin un modelo de datos formal, le está pidiendo al consumidor que hacer su propio modelo y saber lo que no puede saber. Esto tiene el efecto de encadenar el cliente API a las bibliotecas y bases de datos internas directamente,

Otro gran problema que esto crea es la llamada "tribalización" del conocimiento. Sin documentación de datos formal, solo ciertos grupos comprenden realmente el modelo de datos en cuestión. Si bien esto lo convierte en un pequeño equipo de expertos en el mejor de los casos, casi siempre da como resultado una situación en la que el conocimiento es invisible, en el que el conocimiento se ignora en favor de esfuerzos duplicados, a menudo en detrimento del producto final.

Esto tampoco es simplemente un problema interno: cuando estos modelos se ocultan a la vista colaborativa, este problema continúa entre equipos, productos, incluso implementaciones separadas, y da como resultado un ecosistema menos saludable. No hay discusiones fuera de la tribu informada en silos y, por lo tanto, cualquier intento de utilizar los datos es complicado y requiere conjeturas o manipulación directa fuera del caso de uso establecido.

También está el problema real de probar en tal formato. Cuando las unidades de prueba no comprenden realmente los datos disponibles, probar ese modelo de datos es más complejo y al mismo tiempo más incompleto: es más difícil probar lo que sabe e imposible probar lo que no sabe. Esto tiene un efecto muy negativo en general para su modelo de datos dado y puede resultar en problemas que se propagan hacia adelante cuando deberían haberse detectado desde el principio.

Ejemplo de caso de uso: DataFeed

Veamos un posible caso de uso en el que Supermodel sería extremadamente beneficioso. Un desarrollador está intentando crear una API que utilice un esquema de conjunto de datos para proporcionar información estructurada sobre una base de datos interna. En este caso, la base de datos recopila una variedad de documentos y publicaciones, clasificándolos principalmente por el ISSN del documento asociado.

El desarrollador se sienta a codificar su API y comienza a darse cuenta de cuán intenso será el esfuerzo asociado de modelar estos datos. Si bien tienen la base de datos ya diseñada en el backend, cada elemento de la representación de los datos (el catálogo, el ISSN, el año de publicación) representa algo que tendrá que ser procesado y de alguna manera estructurado en el modelo de datos.

El desarrollador recuerda a Supermodel, sin embargo, de un taller al que asistieron. Después de una búsqueda rápida en Supermodel.io de "conjunto de datos", se encuentra un esquema titulado - curiosamente - Conjunto de datos . Este esquema es de uso público y utiliza varios modelos de datos heredados adicionales. El conjunto de datos representa todos los elementos que necesitarían para modelar sus propios datos internamente: "ISSN" para el número ISSN, "temporal" para las limitaciones de tiempo específicas para cada punto de datos, etc., y este esquema se puede utilizar para su propia implementación.

Dado que el desarrollador está utilizando este nuevo esquema, ha obtenido importantes beneficios. Primero, tienen un modelo de datos probado y utilizable sin el costo adicional incurrido en horas de desarrollo. En segundo lugar, tienen un esquema de código abierto que permite al desarrollador no solo integrarse con otros que utilizan este modelo de datos, sino también permitir la integración con su propio modelo de datos. En tercer lugar, y quizás lo más importante, el desarrollador ha implementado un esquema comprobable, evitando la llamada "reinvención de la rueda" que tan a menudo resulta en problemas novedosos y errores íntimos que se replican en todo el sistema naciente.

En unos sencillos pasos, el desarrollador ha hecho mucho más de lo que podría haber hecho por su cuenta y con mayor eficacia.

Cómo se ve la supermodelo

Ahora que entendemos el caso de uso y el valor detrás de Supermodel, veamos el esquema real que hemos discutido, " Conjunto de datos ". Una de las mejores cosas de Supermodel es que todo se basa en todo lo demás: cada modelo puede heredar de otro modelo, lo que agrega contexto y hace que el "nivel" actual sea específico para la funcionalidad dada.

En este caso, Dataset hereda varios modelos. Primero, hereda CreativeWork, que es un modelo genérico para trabajos creativos, como películas, música o libros. CreativeWork en sí también hereda un modelo conocido como Thing, que es un objeto aún más genérico, que representa literalmente cualquier “cosa”. De esta manera, mientras que Dataset técnicamente solo hereda CreativeWork, en realidad hereda dos modelos de datos separados.

El resultado final de este modelo es que Dataset, que es un conjunto muy complejo de posibles propiedades, en realidad está formado por varios conjuntos más pequeños, lo que permite una comprensión y un conocimiento más modular sobre cada propiedad y sus componentes probados.

Curiosamente, la representación del esquema y la representación del gráfico pintan historias separadas, aunque ambas completas, sobre la implementación real que estamos viendo. Si miramos la representación del esquema, vemos específicamente qué propiedades se importan y dónde existen esos esquemas.

Este esquema es corto porque no está destinado a ser representativo de todo lo que se está importando; en cambio, está destinado a brindar una descripción general de las propiedades específicas que están delineadas, ya que estas son propiedades de los esquemas indicados, mientras que indica una importación completa de CreativeWork . Sin embargo, si echamos un vistazo a la representación del gráfico, vemos muchos más detalles.

En la representación del gráfico, lo que estamos viendo es un gráfico de referencias salientes. Supermodel define las referencias salientes como referencias del modelo actual a un esquema externo. Si bien muestra propiedades internas, este gráfico está mucho más relacionado con los elementos referenciados externamente. Aquí, podemos ver la verdadera complejidad detrás de la implementación.

Desde una vista lejana, podemos ver cuánto está involucrado en este esquema particular. En el lado izquierdo de esta imagen, el cuadro verde representa el conjunto de datos en sí y, a la izquierda, sus propiedades declaradas. Sin embargo, a la derecha está el esquema de CreativeWorks al que se hace referencia, que demuestra una gran cantidad de propiedades de esquema adicionales que se incluyen en esta implementación en particular. Podemos ver esto con mayor detalle con una mirada más cercana a la parte CreativeWorks de este gráfico.

Con esta vista más cercana, podemos ver el detalle real dentro del propio esquema. Si bien esto elimina una gran cantidad de contenido (y de hecho, casi no hay forma de que uno pueda ver el esquema completo mientras proporciona una cantidad legible de información) que se llama como una propiedad, demuestra uno de los valores más importantes de la Sistema de supermodelo: visualización del modelo de datos. Al visualizar los datos en este formato, especialmente en términos de conocimiento y luego probarlos, se logra una mayor comprensión del modelo y sus esquemas secundarios subyacentes. El valor de eso no puede ser exagerado, y esto es claramente algo perdido entre simples declaraciones de importación y referencias a esquemas.

Conclusión

Si bien es técnicamente cierto que un desarrollador puede salirse con la suya sin proporcionar un modelo de datos, eso es tan cierto como decir que un mecánico puede arreglárselas sin una llave inglesa; sí, es cierto, pero la realidad es que la vida sería difícil y cualquier trabajo sería monumentalmente más difícil de lo que debería ser. En consecuencia, proporcionar modelos de datos adecuados y contextualizar los datos en información es sumamente valioso.

La supermodelo ofrece esto con creces. Hay algunas advertencias, por supuesto, como las hay con todo. La oferta de la supermodelo de un esquema colaborativo que se puede compartir funciona para muchas aplicaciones, pero hay algunos espacios en la industria de las API en los que compartir dichos modelos de datos podría considerarse compartir propiedad intelectual o secretos comerciales patentados. Incluso hay algunos casos en los que las API gubernamentales pueden querer no proporcionar estos esquemas de seguridad a través de la ofuscación, ya sea que sea efectivo o no.

También existe el hecho muy real de que, para muchos microservicios, los modelos de datos pueden ser tan simples que un modelo de datos podría ser tan simple como un gráfico indicado en la documentación. En estos casos, Supermodel puede ser útil, pero puede que no sea un requisito absoluto. Esto también se aplica a las API de "servicio único", en las que el modelo de datos no es importante, ya que la API está destinada a cumplir un único propósito y no a iterar o integrar.

Dicho todo esto, Supermodel sigue siendo una solución altamente efectiva para el problema indicado, y lo hace con una GUI muy hermosa y un sistema de representación gráfica altamente eficiente.

¿Qué piensas? ¿Es Supermodel la mejor herramienta en esta categoría? ¿Tiene alguna otra herramienta que le gustaría compartir con la comunidad? ¡Háganos saber a continuación!

Publicar un comentario

0 Comentarios