T3chfest

Si quieres ver las slides con el video: https://www.youtube.com/watch?v=MN-j4kDpcRI David Muñoz Díaz (Seedtag) @voiser Si eres programador, quizá hayas tenido que desarrollar una aplicación con tantas opciones y maneras diferentes de comportarse que lo más complicado era modelar la configuración. Probablemente todo acabara en una bonita colección de archivos ".cfg" con tantas opciones, flags, prefijos, secciones y casos particulares que todo acabara siendo un churro infumable que nadie sabía utilizar. Y seguro que más de la mitad del código acabó siendo una colección de estrategias, factorías y comandos tan enorme que podrían exponerse como colección permanente en un museo de patrones de diseño. Bien, si esta situación te suena, te has enfrentado al problema de definir un comportamiento de forma paramétrica. Ese enfoque no tiene una buena solución. Es una castaña. No lo hagas así. Hay otra manera de hacer las cosas, y es creando un lenguaje. Crear un lenguaje, un compilador, o una máquina virtual es una so

Si quieres ver el video con slides: https://www.youtube.com/watch?v=cUIhcgtMvGc& Jose María Rodríguez Hurtado (Genbeta Dev / Jobandtalent) Las APIs más populares que utilizamos a día de hoy son RESTful APIs o un pseudo estándar ad hoc HTTP. Pero la necesidad de avanzar rápido en productos cada vez más complejos más allá de un simple CRUD ha empujado un cambio en la forma en que interactuamos con las APIs. Aquí es dónde surge GraphQL, un fuerte candidato predestinado a sustituir a REST en muchas aplicaciones, sobre todo en el ecosistema móvil de apps. ¿Qué hay de malo en REST? Nada en su concepción inicial y en el contexto dónde surgió, pero desde que fuera definido la forma de interactuar con las APIs ha cambiado. Vamos a repasar las razones por las que deberíamos repensar las tradicionales APIs basadas en RESTful en favor de GraphQL.