La Capa API en Disminución

Hola a todos. Mi nombre es Tejas y trabajo en slash GraphQL en dGraph Labs. Pueden encontrarme en Twitter en At T. Dinker. Hoy quiero hablar un poco sobre algo que me ha interesado durante un tiempo y le he llamado a esta charla la capa API en disminución. Sin embargo, también tenía un título alternativo para esta charla y era `allá y de vuelta otra vez`, o cómo nosotros como comunidad movemos toda esa lógica fuera de las bases de datos. Y luego un día decidimos moverla de vuelta. Así que el año 2020 ha sido un año bastante difícil para todos. Ha sido una pandemia global y las cosas han sido muy difíciles. Pero una cosa buena que me ha pasado es que mi pareja y yo acabamos de tener una niña. Y así, mientras leía El Hambriento Oruga Muy Hambrienta probablemente por 4000ª vez este año, tuve mucho tiempo libre para pensar mucho sobre preguntas filosóficas que realmente pueden no tener ninguna implicación práctica real. Y una cosa en la que he estado pensando mucho estos días es ¿qué son los datos? ¿Qué queremos decir realmente cuando hablamos de datos y cómo es diferente de la lógica o el código real? Así que he trabajado mucho en varias programaciones funcionales.

Los lenguajes de programación, especialmente Clojure. Y Clojure tiene este concepto de Homo-iconicidad, ¿verdad? Y la Homo-iconicidad es la propiedad de un lenguaje de programación de poder expresar tu código como datos, ¿verdad? Así que en Clojure, puedes escribir un macro que básicamente acepta código real y puedes procesarlo con las mismas estructuras de datos que procesarías tus datos regulares. E incluso fuera de los lenguajes de programación como Clojure, los lenguajes específicos de dominio se han vuelto muy populares en los últimos 10 o 15 años.

Y los lenguajes específicos de dominio son simplemente lenguajes diseñados específicamente donde tienes varias reglas que son código, escritas en algún formato, y luego son interpretadas por quien analiza ese lenguaje específico de dominio. Así que una vez más, vemos aquí también cómo se difumina significativamente la distinción entre datos y código. Esto me lleva a la siguiente pregunta, si el código es datos, ¿hay alguna diferencia entre los datos de tu código y los datos de tus datos? Y si no la hay, ¿debería estar tu código en tu base de datos? La primera vez que me encontré con algo así, donde se acopla estrechamente el código y los datos, fue algo en lo que trabajé al principio de mi carrera a finales de los años 2000. Y mi primera experiencia con algo así fue con Oracle Forms. Oracle Forms es un gran ejemplo de un acoplamiento muy estrecho entre datos y código. Y no es tan popular hoy en día por diversas razones. Pero en ese entonces, Oracle te daba la base de datos. Te daba el lenguaje con el que construirías estas herramientas. Tus entradas típicamente serían páginas de arrastrar y soltar que habías construido. Y luego operarías en ellas con PLSQL, y lo insertarías en tu base de datos, y finalmente lo consultarías con vistas y SQL. En esencia, tu código y tus datos eran una sola unidad que se desplegaría en varios lugares. Y no es que Oracle Forms fuera el único que hacía esto, de ninguna manera. Hay muchos otros, como por ejemplo, FoxPro, por ejemplo, viene a la mente. E incluso los sistemas que tenían una capa de código separada, a menudo dependían de características muy específicas de la base de datos, como disparadores y procedimientos almacenados. Y esto funcionaba. Tenías sistemas muy grandes construidos con estas herramientas. Y eran razonablemente fáciles de construir al principio. Pero la gente se dio cuenta rápidamente de que esto era muy difícil de probar. Era difícil de implementar, porque a menudo solo estabas reescribiendo un procedimiento almacenado en tu base de datos. Y era difícil de gestionar. Era imposible de versionar. Había tantas cosas que tenían que suceder. Y siento que este tipo de acoplamiento estrecho llevó a que todos fueran en la dirección opuesta durante mucho tiempo. Y entramos en lo que llamo la era del código repetitivo. ¿Verdad? Así que en la era del código repetitivo, tendrías un montón de API, y sin mencionar ningún lenguaje específico, tal vez eso sería como una implementación de fábrica de Data Bean factory. Y estas API estarían muy desacopladas de tu base de datos real. De hecho, llegarías tan lejos como para estar muy orgulloso del hecho de que las pruebas unitarias tendrían tu base de datos y cosas simuladas. En lugar de escribir contra una base de datos real, tu código se desarrollaría e implementaría utilizando la interfaz iRepository, que, ya sabes, esperas que

Tu código se desarrollaría e implementaría utilizando la interfaz iRepository, que, ya sabes, esperas que el repositorio esté implementado de alguna manera. Y eso ni siquiera se prueba en el caso de las pruebas unitarias. Tus APIs, al principio, serían muy independientes. Lo que significaba que cada acción individual que se pudiera realizar en el sistema tenía su propio punto final. Pero no había una convención real para determinar qué acción querías realizar y cómo se vería la API. No había forma de saber dónde estaba la API o cómo serían las entradas de la API. En ese momento, cosas como WSDL se volvieron muy populares. Pero no siempre estaban destinadas al consumo humano. Si estabas lidiando con una nueva API, tenías que sentarte y entender los detalles de cómo funcionaba tu API. Te deshiciste de muchos de esos procedimientos almacenados porque ahora se consideraba que la base de datos era un poco poco confiable y tu código de aplicación era lo que funcionaba. Pero, ya sabes, algunos de esos procedimientos almacenados realmente feos que simplemente no podías eliminar, sí, todavía estaban ahí. Y esto funcionó por un tiempo, pero creo que en algún momento se convirtió en un verdadero enredo. Tenías tantas APIs y tantas capas e indirecciones entre lo que es tu API y lo que es tu base de datos, y tenías tantos sistemas y tantas capas intermedias que las cosas comenzaron a volverse muy confusas y difíciles de gestionar cada vez que querías hacer un cambio. Y este problema

La cosa se puso mucho peor una vez que empecé a mirar cosas como microservicios. Sí, así que cada API tendría su propio formato, y, ya sabes, a medida que agregabas más APIs, se volvía cada vez más difícil depurar lo que realmente estaba sucediendo. Lo siguiente que vi y que realmente me impresionó fue cuando me encontré por primera vez con Ruby on Rails y REST, creo que fue alrededor de 2012. Fue realmente impresionante, porque por primera vez pude ver cómo Rails generaba tu base de datos y luego tu base de datos generaba tu código y tu API. Entonces, lo que quiero decir con eso, con Rails lo que harías es comenzar definiendo una migración, y dirías, ya sabes, estoy creando esta tabla y estos son los campos que tiene. Y en base a eso, tu base de datos estaría completamente actualizada, e incluso verificaría y diría, okay, este campo faltaba desde la última vez que se ejecutó esta migración, creará, ya sabes, columnas y cosas así. Pero luego, y aquí es donde la magia de Rails realmente entraba en juego, cuando tu servidor de Rails realmente comenzaba, leería de vuelta desde tu base de datos y generaría todos los campos, todos los métodos para obtener esos campos, todos tus setters y getters, basados en los campos reales de tu base de datos. Y tu API también respondería en función de esos campos. Y creo que por primera vez, una vez más, Rails te hacía creer que tu código y tu base de datos son una unidad única, ¿verdad? Se esperaba que tus pruebas cubrieran la base de datos, famosamente Rails, ya sabes, en las pruebas unitarias, realmente carga datos de la base de datos y haces afirmaciones contra eso, en lugar de todo este simulacro y cosas así. La sabiduría convencional allí es que, ya sabes, quieres simular cosas que están fuera de tu servicio, pero tu base de datos es parte de tu servicio. Y creo que este acoplamiento estrecho fue realmente fantástico. Y para alguien nuevo, Rails era mágico. Y creo que Rails es mágico. Y creo que eso es lo mejor y lo peor de ello. Con un simple andamiaje, obtienes una API funcional, obtienes un servidor funcional y obtienes una base de datos funcional. Y esto se basa en mucha magia de metaprogramación de Ruby. Pregunta a cualquier programador de Ruby y te dirá que Rails es fantástico cuando las cosas funcionan. No hay forma más rápida de hacer cualquier cosa. Pero cuando las cosas no funcionan, tienes que pasar por tantas capas de magia para depurar lo que realmente está sucediendo. Y depurar Rails tiende a ser un poco difícil. Hay tantas de estas capas mágicas que Rails agrega. Pero con cada capa que agregas, solo estás agregando mucha más complejidad entre tu API y tu base de datos. Pero al menos una cosa que Rails hizo muy, muy popular fue REST, y hizo que estas APIs fueran al menos muy fáciles de razonar.`

ser. Y de hecho, desde ese recurso incluso te enlazaría a otros recursos que están conectados, pero no necesariamente sabrías qué campos esperar, o no podrías controlar qué data quieres obtener o qué entidades anidadas de eso quieres obtener o pasar límites de una manera sencilla. Y como resultado, incluso con toda esta especie de magia que tienes de Rails, diría que aproximadamente el 70% de todo tu código termina siendo boilerplate solo para unir todo esto. Y, solo para decir que sabes, como tienes situaciones muy típicas, como tener que escribir este registro y querer escribir tres subregistros debajo de eso. Y no es algo muy complejo. No es, ya sabes, el tipo de código que todos quieren pasar el día escribiendo. Pero, ya sabes, una buena parte de tu código sería manejar este tipo de escenarios donde es como, okay, escribe esto y todas las entidades anidadas o, ya sabes, elimina estas seis entidades y reemplázalas con estas tres entidades y cosas así que idealmente deberían ser automatizadas para ti. No hay razón para que estas cosas deban ser

Las cosas que estás escribiendo en código real. Y como todos sabemos, los programadores realmente odian el boilerplate. Y creo que esto llevó de manera muy significativa al surgimiento de lo que ahora se llama el backend. Entonces, ¿qué es un backend? Creo que cuando miras un backend, un backend es básicamente un sistema único que contiene tanto tus datos como tu lógica o código, como quieras llamarlo, que generalmente se implementa en la nube y se encarga de la escalabilidad, el mantenimiento y las operaciones. Básicamente, te proporciona una experiencia sin código o con poco código como desarrollador. Creo que Firebase, Hasura y Slashgraph QL, este último en el que trabajo, definitivamente entran en esta categoría. Estamos tratando de hacer que sea muy fácil para las personas construir código. El primer paso de esto es ¿cómo podemos generar tu código boilerplate automáticamente? Eso es el 70% de tu código. ¿Cómo generas eso automáticamente y no dejas que los desarrolladores se preocupen por eso? Y ¿cómo puedes permitir que los desarrolladores se centren en lo que quieren hacer, que es construir su aplicación súper rica, y permitirte iterar rápidamente en eso? Agregar nuevos tipos o conceptos a tu backend no debería ser algo que lleve horas y requiera tiempo de inactividad. Debería implementarse en cuestión de segundos. Quieres estar en una posición en la que un pequeño cambio puedas iterar muy rápidamente y ofrecer tus funciones a tus usuarios. Y creemos que un buen backend realmente hará todas estas cosas por ti. Estarán muy integrados entre tu código y tu almacén de datos, y creemos que esto resulta en un código mucho más elegante. Entonces, creo que como resultado, GraphQL encaja muy bien aquí. GraphQL fue desarrollado tradicionalmente como un lenguaje de API de alto nivel. Se usaba principalmente para que los navegadores obtuvieran datos de tu backend, pero creo que rápidamente se está volviendo más y más popular entre la multitud de bases de datos como el pegamento que se encuentra entre tus datos y tu API. Creo que de muchas maneras, Fauna DB, Hasura, Slash GraphQL, todos estamos tratando de responder una pregunta muy, muy similar, que es... Y eso es, ¿cuál es lo mínimo que realmente necesitarías para generar una API completamente funcional para los usuarios? Y creo que por qué GraphQL encaja tan bien aquí es el hecho de que GraphQL está altamente acoplado con el esquema, que agrega tipos. Y, por supuesto, estos tipos no son solo tipos simples, en los que dices, ok, tengo estas entradas y cada una de ellas tiene estos campos debajo, sino que también te permite expresar de manera hermosa la relación entre estos tipos. Permíteme tomar un ejemplo de dónde generamos varias operaciones CRUD para ti a partir de tus tipos. Este ejemplo proviene de Dgraph o Slash GraphQL, simplemente porque es con el que estoy más familiarizado. Aquí tengo tres tipos simples, productos, clientes y reseñas. Y cada uno de estos productos tiene algunos campos simples. Por ejemplo, la reseña tiene calificaciones que son números y comentarios que son cadenas, pero también tienen relaciones entre sí. Un producto tiene muchas reseñas y un cliente ha realizado muchas reseñas. Y si ingresas esto en Slash GraphQL, obtendrás al menos las siguientes consultas. En realidad, había demasiadas, así que ni siquiera pude enumerarlas todas en una página. Veamos solo los productos entonces. Tienes dos consultas, una para consultar un producto y otra para obtener un producto por ID. Y también tienes todas tus operaciones de actualización, agregado y eliminación en el producto.

Y un buen sistema no solo hará que estas sean solo elementos de nivel superior. Podrías crear un producto y crear las reseñas bajo ese producto en una sola consulta a través de una actualización anidada. Y creo que la mayoría de los buenos sistemas de backend como servicio realmente te proporcionarán esto. Y creo que esto realmente cubre ese 70% superior del código en el que gastarías escribiendo boilerplate. Pero esto plantea la pregunta de cuál es ese último 30% restante, ¿verdad? ¿Proporciona GraphQL algo para esto, verdad? ¿Y algo en lo que los backends puedan aprovechar?

Entonces, para mí, la respuesta es en realidad, sí. Y no sé si esta fue la intención original cuando se introdujo en GraphQL, pero creo que las directivas se han convertido muy rápidamente en una de las herramientas más poderosas de GraphQL. Las directivas, para aquellos que no lo saben, son anotaciones que se pueden colocar en varios lugares en GraphQL. Hay directivas que se pueden colocar en tu esquema. Hay directivas que se pueden colocar en las consultas. Y a un nivel muy alto, cómo funcionan estas directivas es que son una especie de patrón de decorador alrededor de la operación real que ocurre en GraphQL. Entonces, ¿qué es un patrón de decorador? Básicamente, lo que hacen es que la directiva intercepta la solicitud antes de que se procese. Y puede hacer algún preprocesamiento, y puede interceptar la respuesta en el camino de regreso y hacer algún postprocesamiento de la respuesta. De hecho, si la directiva así lo considera, ni siquiera necesitas hacer el procesamiento real. Incluso puedes interrumpir directamente en la directiva. Así que aquí, tal vez quiera revisar dos o tres usos innovadores de las directivas que encontré en la práctica. Y sí, tal vez echemos un vistazo y veamos cómo se usan y para qué se pueden extender. El primero proviene de D-graph y slash-graph-ql. Es una directiva llamada auth, ¿verdad? Entonces, la directiva auth aquí es en realidad una forma de proporcionar autorización en tus registros. Entonces, en este ejemplo, tengo una tarea por hacer. Y esta tarea por hacer dice que si estás tratando de consultar la lista de tareas por hacer que está en la línea cuatro, entonces el usuario que está tratando de consultarla debe coincidir con el propietario de la tarea por hacer. Entonces, esta regla simple se aplica como un filtro antes de que se realicen cualquier consulta para obtener las tareas por hacer. Y como resultado, los usuarios solo pueden consultar los elementos de la lista de tareas por hacer de los que son propietarios. En este ejemplo en particular, o en D-graph, esto se implementa como un prefiltro. En cierto sentido, si simplemente no tienes acceso, la tarea por hacer se filtra incluso antes de que se pueda leer. Veamos otro ejemplo, este de Apollo, la directiva at-length. Entonces, aquí tengo algo muy simple por hacer, solo tiene un ID y un título, pero el título está marcado diciendo que la longitud de este título debe tener un máximo de 42, presumiblemente caracteres en este caso. Puedes ver cómo funcionaría, y lo que harías es que potencialmente podrías tener múltiples campos diferentes y diferentes tipos de validación en ellos, como tal vez la longitud de algo, y algo más debería ser un correo electrónico, y tal vez tu contraseña y la confirmación de la contraseña deben coincidir y ser los mismos bytes exactos. Y podrías escribir fácilmente un validador que recorra todas estas reglas de validación, y sea capaz de asegurarse de que todas estas validaciones se cumplan antes de que se ingrese cualquier dato en tu almacén de datos. Y el último ejemplo que quería mostrar es de Dgraph y slash GraphQL nuevamente. Lo que encontramos es que algunos códigos son tan complejos que es difícil expresarlos puramente en términos de GraphQL, por lo que hemos agregado

en la directiva at lambda. Entonces, lo que puedes hacer con la directiva at lambda es decir que, sabes, algunos de estos campos en este esquema de JavaScript están implementados en JavaScript. En mi ejemplo, tengo un usuario que tiene un nombre y un apellido, y el nombre completo está marcado como una directiva at lambda, y decimos que ese campo se completa uniendo el nombre y el apellido con una barra diagonal. Un ejemplo un poco más complicado en la parte inferior, no entraré en detalles, pero básicamente lo que estás haciendo es enviar una consulta GraphQL para completar, ya sabes, escribir un resolvedor personalizado. En este caso, para obtener los títulos de todas las tareas pendientes. Sí. Y en conclusión, siento que de muchas formas hemos vuelto al punto de partida. Mientras que al principio teníamos tu base de datos y tu código muy acoplados, pasamos por una era en la que decíamos, no, separémoslo tanto como podamos. Y una vez más, comenzamos a ver nuestros datos como una única unidad tanto de tu almacenamiento de datos como de tu lógica. En muchos casos, de hecho, incluso hablamos de estas grandes combinaciones, como Firebase y funciones en la nube, AWS Lambda y DynamoDB, o slash GraphQL y d-graph lambdas. Continuamente tenemos estas combinaciones donde empezamos a pensar en nuestros datos y nuestra lógica como una única unidad. Y creo que las bases de datos y los adaptadores de bases de datos, realmente los backends, están empezando a adoptar esto. Y nos estamos alejando o bueno, muchas personas se están alejando del código sin servidor, donde el código sin servidor era simplemente eso, hey, escribiste una función y no te preocupes por el servidor. Nosotros nos encargamos de escalarlo. Hacia una experiencia verdaderamente sin código o con un código mínimo con un backend como servicio. Y muchas de estas cosas que hemos discutido aquí, muchas de estas tendencias, son algunas de las razones por las que hemos creado slash GraphQL en Dgraph, solo como una nota al margen. Y al menos creo que GraphQL es realmente perfecto para esto. Aunque comenzó como un lenguaje de API, rápidamente nos estamos dando cuenta de que se puede adaptar a más casos de uso. Su sistema de tipos te permite expresar fácilmente cómo se ve tu almacenamiento de datos, y puedes generar fácilmente APIs basadas en eso según el esquema. Y para eso, se convierte en una gran opción para al menos llegar al 80 o 90% del camino. Y con eso, me gustaría terminar mi charla. Gracias a todos por asistir. Estoy feliz de responder cualquier pregunta. Hola, qué bueno verte. Hola, gracias, hombre. Nos dieron un comentario de que escucharon ronquidos. ¿Puedes decirnos de qué se trataba eso? Sí, lo siento mucho, mi hija estaba durmiendo cerca y no me di cuenta de que se escuchaba. Ahora está un poco más tranquila. Bueno, bien, bien. Bueno, si un bebé está dormido, está bien para nosotros, ¿verdad? Esa es la realidad de trabajar desde casa. De hecho, sí, estaba diciendo en Discord, espero que eso no sea realmente representativo

de la calidad de mi charla. No, no, no. Si eso es lo que molesta a la gente, entonces el contacto es bueno, ¿verdad? Como dije, es la realidad de trabajar desde casa. Estaba mirando mi agenda cuando tuve esta conversación contigo y tenía un horario para que me entregaran los comestibles. Así que, afortunadamente, ya están aquí, pero podría haber tenido que salir a buscar mis comestibles, excepto que los comestibles están en la puerta de entrada. Esa es la realidad de trabajar desde casa. También, la gloriosa vida de un maestro de ceremonias y orador de conferencias. Hay disturbios. Pero ahora me gustaría pasar a las preguntas. Y tengo una pregunta. ¿Dónde puedo poner mis directivas? Genial. Esa es realmente una gran pregunta. Déjame pensar en ello. Según la especificación de GraphQL, realmente puedes poner directivas casi en cualquier lugar, para ser honesto. Entonces, en realidad puedes ponerlas en tipos, campos, fragmentos, operaciones. Actualmente también hay una especificación que incluso permite agregar directivas a nivel de esquema. Creo que esto aún no ha sido aprobado. Todavía está en el grupo de trabajo. Entonces, incluso a un nivel alto en el esquema, podrías poner directivas. De hecho, algo bastante interesante aquí es que mientras estaba escribiendo el discurso, no tuve la oportunidad de agregar una diapositiva para esto, pero en realidad descubrimos una vulnerabilidad de seguridad en nuestra propia aplicación simplemente inspeccionando el esquema y viendo qué directivas están presentes. Entonces, en nuestra API de GraphQL, cada punto final que requiere inicio de sesión o ciertos permisos, tenemos una directiva, que no cubrí en esta charla, pero tenemos una directiva llamada at needs login. Y simplemente especificamos at needs login, needs permission, XYZ o cualquier otro rol que necesites. Y en realidad, estábamos leyendo el esquema un día y solo estábamos viendo este needs login, ese needs login. Oye, ¿no necesita este API lógicamente o no necesita esta operación como una mutación, ¿así que no necesita un inicio de sesión y no necesita un rol específico para hacer eso? Y así, simplemente inspeccionando el esquema, pudimos encontrar una vulnerabilidad antes de que fuera explotada. De hecho, es una de las razones por las que me encantan tanto las directivas porque son tan cortas y son muy precisas en tu esquema.

De acuerdo. Gracias. Tenemos otra gran pregunta del público de Juan Segebre. ¿Puedes poner directivas en una mutación para parámetros, por ejemplo, la directiva skip? No sé si se pueden poner directivas en un parámetro. No creo que esté permitido hacerlo en el parámetro. Sin embargo, en la propia mutación, en la operación, puedes poner

operación, puedes poner la directiva allí. Creo que específicamente esta pregunta se refiere a la directiva skip. Skip es, creo, una de las tres directivas estándar. Creo que esto incluye skip y deprecate. En realidad, no estoy seguro si puedes... Creo que no está permitido en un parámetro. Solo se permite en la mutación misma. De acuerdo. Espero que Kwan esté satisfecho con esa respuesta. Disculpen, tengo que toser. Voy a silenciar el micrófono.

Quería decir que fue agradable tener este recuerdo del pasado y mirar hacia atrás en cómo solíamos hacer las cosas. Y sentí que tenía 14 años otra vez en la escuela en mis primeros días como programador cuando estaba comenzando, tal vez con SQL, la primera vez que estaba trabajando con bases de datos. Así que realmente quiero agradecerles por hacerme sentir joven de nuevo. Es muy amable. No sé si debería sentirme viejo, pero gracias. Fue encantador tener la oportunidad. Sí, ha sido genial estar aquí.

Muy bien, genial. Ahora vas a ir a tu sala de conferencias en Spatial Chat si las personas quieren discutir esto más a fondo contigo. Así que muchas gracias por venir y luego las personas pueden hablar contigo en Spatial Chat o tal vez puedes promocionar tus redes sociales. Claro, estoy disponible en Twitter en tdinkr y también, si aún no lo han hecho, por favor, visiten slashGraphQL. En mi opinión, es la forma más rápida de tener un punto de GraphQL en funcionamiento y pueden visitarlo en dgraph.io. Genial. Bueno, lo escucharon aquí primero, amigos. Vamos allá y gracias. Adiós.