search

Laboratoria / curriculum

El bootcamp de @Laboratoria es un programa de aprendizaje inmersivo de 6 meses enfocado en los perfiles de Web Developer y UX Designer.
https://curriculum.laboratoria.la
Creative Commons Attribution Share Alike 4.0 International
491 stars 462 forks source link

GraphQL como nuevo paradigma de API centrado en relaciones #509

Closed tzkmx closed 3 years ago

tzkmx commented 6 years ago

Además de las situaciones de overfetching y underfetching típicas de REST, me parece que tanto el tipado de datos, la capacidad de introspección y la facilidad con que se accede a otras API, no solo HTTP sino de todo tipo, por ejemplo DOM, o incluso syslogs, etc. Así como la integración con frameworks de frontend.

Pero especialmente que complementa en buena medida el énfasis en lo visual, llevando a las desarrolladoras a pensar en modelos de datos y como se relacionan entre sí, también el reuso de código y donde no hace falta no reinventar la rueda cómo API de autenticación.

Por si fuera poco, no requiere forzosamente implementar un backend, y se puede experimentar desde el frontend tanto con la implementación modelo cómo la facilitada por graphql-tools de Apollo.

ivandevp commented 6 years ago

Hola @tzkmx! Gracias por tus comentarios, definitivamente GraphQL está teniendo un gran apogeo, y resuelve muchos de los problemas que tienen los RESTful APIs, por otro lado también tienen los propios, aun así, tiene un paradigma muy interesante y una comunidad muy fuerte, y también consideramos que las front-end developers lo deberían tener en cuenta.

Nosotros en el Bootcamp, hemos optado por no ponerlo como parte de nuestro curso Construye una SPA multi-usuario consumiendo data remota por el tiempo de generación de contenido y el flujo del bootcamp (explicado en #508). Sin embargo, nos gustaría agregarlo como un concepto general que ellas puedan revisar o hacer un taller al respecto. Desde tu experiencia, ¿qué cosas priorizarías que deben conocer o cómo armarías el flujo de un taller de GraphQL? ¿Lo mostrarías cuando vean React y/o algún otro framework? ¿O con VanillaJS? ¿Usarías de demo la API de Github?

tzkmx commented 6 years ago

Hola @ivandevp y gracias por tu pronta respuesta.

Efectivamente para el flujo del bootcamp y los tiempos, el curso de GraphQL ya parece algo apretado, pero con gusto trabajaré la propuesta, estaba revisando las plantillas de sus cursos y el flujo del bootcamp, para poder plantearlo de manera más estructurada.

Antes de elaborar una propuesta más amplia, quiero responder rápidamente a tus preguntas, esperando que si tienes observaciones adicionales, podamos ir clarificando aún más la exposición y ejercicios a fin de beneficiar a sus estudiantes de la mejor manera.

Prioridades:

Pain Points de APIs de terceros:

En cuanto a la integración con otros frameworks, realmente tengo experiencia principalmente con {P,}React y jQuery, he hecho algún experimento con mithril y cero con Angular, pero aún sin la magia de librerías como Urql o Relay, es posible aprovechar GraphQL incluso desde Vanilla, porque en realidad es solo una especificación de API y no necesariamente se implementa en JS, sería interesante revisar si se puede implementar un backend en Ruby como lo proponen en un curso.

De hecho por las prioridades y este aspecto, en realidad como especificación de API VS su implementación, yo veo potencial en GraphQL como un tema transversal a diversas unidades.

En cuanto a la demo de Github/v4 sin duda puede servir como modelo de mejores prácticas en la especificación de una API amplia y compleja, pero para poder apreciarla en toda su dimensión y no verla como solo una API más, sería preciso conocer antes su API REST o de Webhooks, lo que en sí implica todo un curso o unidad prerrequisito aparte, IMHO innecesario para construir el aprendizaje de GraphQL en sí.

Además, la propuesta como puedes ver, consiste no tanto en el consumo de una API, como en la construcción y razonamiento del modelo de datos que se requiere para una UI, de hecho más inspirado en como ustedes, antes de enseñarles a consumir Bootstrap, les inducen a crear su propia grid con floats y porcentajes.

Así pues, aunque casi tooodas las exposiciones de GraphQL, casi pitches para venderla, se enfocan en el problema de {over,under}fetching de REST, esa es solo una ventaja de performance que ofrece a las apps (y eso atendiendo justo a parte de los issues propios que tiene), pero ese es propiamente un problema de backend (lo sé bien con WordPress 😅 ), en realidad se podrían ofrecer por ejemplo endpoints que se limite los campos que devuelve y/o incluya data conexa.

Y por eso no, no propongo usar la API de Github, sino más bien armar el modelo de los datos que necesita una app, y enchufar la(s) API subyacente(s), devolviendo al frontend solo lo que se requiera, incluso montando en un proveedor serverless el backend proxy con el endpoint GraphQL. En este sentido yo propondría algo más basado en express que en Ruby, ya que en este no tengo experiencia.

lupomontero commented 5 years ago

Hola @tzkmx e @ivandevp, perdón que me sume a la fiesta tan tarde... :see_no_evil:

Hoy por hoy no me parecería mala idea considerar un proyecto (nuestro Bootcamp está 100% orientado a proyectos) que requiera (o sugiera) usar GraphQL... :thinking:

Creo que esto puede tener sentido en el medio/largo plazo, según vayamos proponiendo nuevos proyectos, y en particular proyectos electivos.

cc/ @merunga

tzkmx commented 4 years ago

Hola @tzkmx e @ivandevp, perdón que me sume a la fiesta tan tarde... 🙈

Asere yo vuelvo a meter la cuchara espero que ya con más sazón que aportar 😀

Hoy por hoy no me parecería mala idea considerar un proyecto (nuestro Bootcamp está 100% orientado a proyectos) que requiera (o sugiera) usar GraphQL... 🤔

De entrada se me ocurren 2 proyectos en que podría plantearse. Pokemon era perfecto usar la API GraphQL por la lata que daba la pokeapi "rest", pero como para data lover ya les facilitan los datos pierde un poco el sentido 🙃.

Recuerdo que antes hacían un proyecto tipo kanban. Ya les proponía en el #861 que le echarán un ojo a la mini API con la que consumo para presentar feeds de WordPress. Mostrar como implementar los resolvers con fetch, creo deja ver que GraphQL es asequible aún para el frontend. Agregando algo como manejar esos posts como en etapas de un proceso de redacción con las tarjetas, además introduce el manejo de datos locales con el propio caché. O algo así.

Creo que esto puede tener sentido en el medio/largo plazo, según vayamos proponiendo nuevos proyectos, y en particular proyectos electivos.

cc/ @merunga

Y por último creo que un proyecto de los juegos como battleship o el memorama en #421 el manejo de su estado también se presta para hacer el dispatch de acciones o mutaciones en la jerga de GraphQL, ni idea de porque sacaron Redux según vi por ahí en un comment. Pero creo que la idea de enviar eventos a un contexto que la vista refleja, llámese Store o Service o Model o Context, es común a los framework actuales y de hecho el concepto es muy viejo y muy útil para resolver problemas tanto en front como backend.

lupomontero commented 3 years ago

En este momento @mfdebian está justo trabajando en una propuesta de proyecto que hace uso de GraphQL. Me tomo la libertad de cerrar este issue (por antiguo), pero si quieren comentar sobre la propuesta de @mfdebian pronto tendremos un PR donde pueden opinar, y mientras tanto tenemos este issue: #1054.

Gracias por todos lo comentarios :yellow_heart: