¿Por qué después de 6 años dejé GraphQL?
Vložit
- čas přidán 4. 06. 2024
- En este video, hablaremos sobre un artículo "Por qué, después de 6 años, he superado GraphQL". Analizaremos las limitaciones y problemas de seguridad, rendimiento y complejidad de gestión de permisos que han llevado a muchos desarrolladores a abandonar GraphQL, pero también sus ventajas
Artículo analizado: bessey.dev/blog/2024/05/24/wh...
▶ No te pierdas más directos en: / midudev - Věda a technologie
GraphQL nos ayudó mucho en nuestra API en nuestro caso en elixir y absinthe nos facilita resolver esos problemitas.
Aunque claramente GraphQL es preferible usarlo internamente (Backend -> FrontEnd) y no para APIs publicas, porque es muy propenso a ataques por la cantidad de posibilidades y cosas que te permite hacer.
GraphQL necesita un revamp como Zustand le hizo a Redux.
En el trabajo tuvimos estos detalles y Query complexity and depth ayuda con el tema de la seguridad, para el N+1 existen los Dataloaders. Lo que sigue sin tener una forma sencilla de hacerse es prevenir Query Batching Attacks.
@@63ivaan El interesante? jajaja vale "Chulo"
Justo cómo comentan, usamos graphql para uso interno, para evitar tener que crear 50 endpoints, ya que muchas veces quieres obtener una lista de algo sencillo, para mi si la petición tiene lógica o cálculos ahi si qué metería un endpoint, vamos un uso híbrido según que se requiere
Ya estamos bajando el uso de GraphQL en nuestro aplicativo, básicamente es mucho mas trabajo asegurarlo por todo lado adicional a optimizar las queries que construye el Graph que simplemente hacer endpoints y hacer nuestras queries mucho mas optimizadas, resultado: se aumentó la velocidad x3 en el performance del aplicativo
Dudo que halla sido por usar endpoint en lugar de queries de graphql ya que la idea central de graphql es en una sola query traer información de varios endpoints a la vez
@@Juan-pu2rv Total esa es la idea de GraphQL y por eso decidimos usarlo, pero en esta etapa de nuestro producto tenemos casos donde la misma query en Graph crea una consulta muy mal optimizada aparte de otras que simplemente no se pueden hacer por cierta logica que necesitamos, si bien se puede corregir haciendo muuuchas adaptaciones a nuestro caso de uso no valela pena cuando tenemos procedimiento almacenados que responden mucho mas rapido, para nosotros es primordial el UX antes que nuestro DX, por mas que nos haya gustado Graph, hay que ser practicos, repito, en nuestro caso.
Básicamente hemos vivido en carne propia lo que dice ese articulo
comentario con respecto a la proteccion de un campo eso no es problema ya que la capa de servicio puede omitir y regresar null las propiedades que el usuario no tenga acceso a un que el client lo vea u observe vera null y listo
En mi caso demasiada parafernalia para llamar integrar algunos datos, por eso deje de usarlo.
BFF es el patrón Facade de toda la vida
gracias por el articulo :)
En mi caso, me gusta usar la implementación OpenApi y un autogenador del cliente para Typescript.
Acudo a un consejo de arquitectura, Cual es la mejor opción y por qué? Poner el bff delante o detrás del api gateway
Desde mi punto de vista, la mejor opción es poner el BFF detrás del API Gateway, especialmente si el API Gateway está diseñado para manejar exclusivamente solicitudes desde el internet. Esto ofrece seguridad unificada, gestion del trafico, etc.
A mi me gustaba mucho, yo creia que seria lo estandar con el tiempo. Pero bueno, al menos ahora uso trpc para el trabajo que es super parecido :)
Ash Framework con graphql es de las cosas mas hermosas que hay, además que hay solución para todo lo que se escribió en el artículo
backend for front end es lo que decimos en backend CQRS
Hola Minudev, aprendo mucho de ti. Estoy haciendo un FP de informática en Alemania. En mis prácticas me han pedido reemplazar las request Graphql del Frontend al Backend por REST APIs. Y configurar en el backend lo necesario(rutas, controladores…) Puedes recomendarme alguno de tus vídeos para aprender hacer esto correctamente? Utilizamos React, JS, Nodejs, axio… O quizás tienes pensado hacer un vídeo de transición de Grapqhl a Rest ? Gracias Máquina ! Saludos
que arquitectura utilizan o te estan pidiendo hacerlo desde cero?
Buena pregunta, no se como responderte a eso. No es desde cero. El proyecto ya funciona. Solo que quieren dejar de usar graphql para usar REST. Tenemos un front end y und backend que se conecta con la Base de datos. La verdad de arquitecturas aún no se nada.
@@ianmanuelpaniagua8823 oh entiendo, guiate de como esta la estructura, seria bueno preguntarles cual es su arquitectura, para que puedas buscar y saber masomenos como esta estructurado y te sea mucho mas facil agregar o cambiar cosas. Me paso lo mismo en mi empresa, pero ahi me guiaron en las partes, y tenia codigo de donde sacar, casos de usos, controlares, inyeccion de dependencias, etc. Hace un año casi empece como dev trainee tambien.
@@diegobejardelaguila8614 gracias
En alguna Startup donde estuve, utilizaban GraphQL y fue un total caos, tanto que corrieron muchos devs (incluido yo, como front) y en meses la startup de destruyó.
G
Que opinas de OData?
Sabías que el QA en graphql no significa query language?
Lo mas interesante.
Se podria pasar de graphQL a Eloquent de forma sencilla para que aplique las optimizaciones de query del Eloquent?
Si, había una librería de Laravel que facilitaba esto bastante
@@f3rran lo más simpático es que todos estos problemas son super frecuentes en cualquier implementaciones, y creo que deberian ser en su mayoría restricciones a nivel de base de datos.
Y no estoy hablando de que se use un usuario de db por cada usuario.
Pero si que se restrinja el acceso según una condición de pertenece el dato a esta persona.
@@angeloliver2825 bueno, no sé si con GraphQL solamente sé puede, pero con Eloquent puedes darle esa lógica en el modelo y listo
@@f3rran lighthouse @angeloliver2825
La mayoría de esos problemas se resolvieron hace mucho tiempo
Ganas de complicarla... la cosa iba tan bien con una Rest, para que liarla??
Hola, alguien sabe como hacer ese zoom en un area (cuadrada) especifica?
Midu tiene en su blog un apartado sobre eso, aunque creo solo funciona en MacOS
A mi me encanta Graphql ❤️
Es que el GraphQL no es para todos lo proyectos, y en mi caso lo querían poner en todo, les comenté que aumentaba el tiempo de desarrollo para ciertos proyectos que con un api rest json funcionaba igual pero al final los gerentes lo querían así.
No sé trata solo de tiempos de desarrollo, con un apollo router que es un graphql Gateway puedes coordinar equipos remotos de backend más eficientemente
Considero que la tecnología no necesariamente se ajusta a un estándar, la mayoría preferimos estándares.
Si lo hace, por ejemplo no vas y nadie te alentara a usar una arquitectura antigua y abandonada con Miles de agujeros, fallas y compleja como pocas. Cuando tienes a disposición una mejor adaptada, fácil de entender, rápida y segura.
Hay estándares claros entre lo que debes usar si quieres ser competente o sufrir.
Estoy a punto de comenzar a entrarme al mundo GraphQL y encuentro este video... mmm, no sé qué hacer...
Yo jamás lo implementé seriamente en un proyecto por eso mismo, aunque nest lo hace más fácil es más tedioso manejar los permisos por campos.
Prefiero rest sobre cualquier otra tecnología. 🫤 Decimos en México que más vale malo por conocido que bueno por conocer.
En REST con Odata se puede hacer muchas cosas
hacia años que no escuchaba mencion a Odata. Lo use en un sistema .net y andaba de maravilla.
mi equipo y yo lo dejamos a los 6 meses.
Para eso existe Hasura para esos permisos Midu controlar todo
grapql parece una buena idea
pero una ves que aprendes bien como se hacen consultas sql genericas
al final terminas prefireindolas
Se pueden hacer a través de un ORM
@@Juan-pu2rv orm es para noobs y no chads como yo
las orm generan sql de muy mala calidad
y si piensas que relamente entiendes una orm signigica que no la entiendes
lee a este causita vladmihalcea cuando entiendas lo que dice te enteraras que hay pocos devs que puedan usar bien un orm
y tu lo dejaste por las mismas razones midu? no lo dices en el video
Yo he usado en proyectos grandes 2 veces GraphQL.
La primera vez nos funcionó perfecto. Teníamos que unificar la API para dar servicio a muchos dispositivos diferentes (móvil, web, televisión, APIs de terceros). La verdad, en ese momento no tuve nada negativo y algunos de los problemas que comenta en el artículo los pudimos solucionar con código. Aunque teníamos cientos de miles de usuarios, era bastante "plano" la forma de resolver la información.
La segunda vez fue un fail. Una empresa con múltiples productos, con información de usuarios a muchos niveles (favoritos, dentro de favoritos, la info de cada cosa...). Podías sacar la info fácil pero el rendimiento era horrible. No es culpa de GraphQL pero usar GraphQL escondía demasiado fácil el problema. Cuando trabajas en organizaciones grandes, no es tan fácil como decir "ah pero es culpa tuya". Tienes que convencer a mucha gente a muchos niveles para que los cambios pasen y hacer mucha pedagogía. Digamos que es algo MUY potente que se te puede desbocar fácilmente. Tampoco nos ayudó mucho el tema de versionado, que en su momento era demasiado confuso.
Ahora... Creo que vaya bien o mal, no creo que sea un problema específico de GraphQL. Muchas cosas del artículo se pueden solucionar. Simplemente hay que tenerlas en cuenta y eso sí es importante. Todo tiene sus ventajas y desventajas.
GraphQL personalmente me encanta y muchos de los problemas que se comentan (También los ataques) se puede llegar a solucionar sin mucho problema, pero es verdad que no recomendaría usarlo en todos los proyectos. En mi caso, solamente lo uso en mi empresa y para proyectos con sistemas distribuidos.
Hola, podrías explicarme por favor, ¿cómo puedo identificar cuando es conveniente usarlo o no? Soy Junior, pero ya llevo estudiándolo y usando funcionalidades de state management 6 meses en un proyecto dónde básicamente, he estado solo, además de que en mi empresa nunca usaron estas funcionalidades que me parece mucho peor por el llamado excesivo de consultas. Puedo decir que me ha gustado por las ventajas del caching y manejo de estado, pero es verdad que he sufrido algunas veces por las inconsistencias entre los datos locales y remotos.
Resaltó que soy frontend, sin embargo, me entusiasmo lo suficiente para empezar hace poco a aprender algunas cosas de backend con Graphql para tratar de aportar en el buen uso de esta tecnología en la empresa, pero con tantas opiniones negativas me asusta dar tanta iniciativa para algo que pueda ser un error. 😢
Quizás hasta lo mejor para ellos es no usar Graphql.
@@ElSebitas En general deberías utilizarlo en proyectos medianos/grandes, debido a lo tedioso que puede llegar a ser implementarlo, tanto en el back como en el front, pero si se implementa correctamente es un lujo y un disfrute utilizarlo. Definitivamente debe haber una buena comunicación del equipo del back y del front. GraphQL es maravilloso (Más si lo usas con apollo o similares), el problema radica en que ya no hay tanto entusiasmo por el, pero sigue siendo un opción formidable y nunca viene mal aprender algo nuevo.
@@tomasidalgo1285 Muchas gracias!
y yo todo chad estoy feliz de saber que mi query no expone nada inseguro y esta correctamente capado
haciendo varios querys con 15 filtros para todos los casos XD
los querys apuntan a sql nativo XD
sql nativo es lo mejor de lo mejor nada de todas esas aberraciones que al final todos usan mal y tienes que ser un genio para imaginarse que sql genera
Explicame, no entendí lo que dijiste, apenas estoy empezando xd
@@luiscarlospallaresascanio2374
hay un lenguaje para comunicarse con la base de datos llamado sql
un ejemplo de los problemas que sql resuelve muy bien son del estilo
"dame el precio de venta y costo de todos los productos categorisados por almacen y luego categoria"
los que son noobs usan otros lenguajes luego otra erramiento lo traduce a sql lo cual hace muy dificil adivinar que sql realmente se ejecuto y es muy dificil que la herramienta genere exactamente el sql que cumple los requerimientos de seguridad y rendimiento
Ni malo ni bueno, depende el caso de uso
aguante API Rest con notación JsonAPI y aguante Laravel!
Y que yo empeze a aprender GraphQL
Mucho pesar, estaba enamorado con Graphql Y Apollo.. Me mude a Next 14 Full Stack con las server actions
Para el que no entienda, GraphQL es una moda más que no resuelve ninguna necesidad masiva y que solo sirve para el 1% de casos. Lo cual es la razon por la que muchas tecnologias que en algún momento se ven que las comentan por todos lados, desaparecen de un día a otro. Porque la realidad de los negocios se imponen y ya
Según midu lo implementó META, eso está lejos de ser el 1%
@@Juan-pu2rv cuantas empresas tienen el tamaño y/o necesidades de Meta/Facebook? A eso me refiero con 1%, cuantos trabajos hay donde te encuentres con una verdadera necesidad de esto?
@@Juan-pu2rv si fue asi, meta lo invento para resolver un problema de ellos mismos, donde el REST clasico no les resolvia un caso en particular que les estaba dando mucho problemas, alli inventaron GraphQL. Luego lo pusieron al publico.
La gran mayoría de cosas que salen al poco tiempo ya lo vuelven obselto, las cosas que sacan dia a dia es abrumador.
Los que usamos API REST de toda la vida:
Reimos en OpenAPI 3.0
Yo no he leido mucho de graf, me da flojera. pero lo que le conocí y por el trabajo debo usar,, me parece interesante, pero siempre se pareció en cierta forma lo que yo llamo API, porque veo que no es el mismo concepto.
Para mi, tener una lista de endpoints es un dolor de cabeza, prefiero la url especifica de la "api" y conocer los recursos, dichos recursos están siendo atendidos por los controllers y si algo no existe o no tiene la forma correcta, error. algo pesado pero, hasta cierto punto más ligero de entender, pero creo que es porque nunca he usado un gramework para hacer mis "aplicaciones" jejejeje
En graphql tus comentarios en la app se convierten en documentación de los "endpoints". Mientras vas programando vas documentando
@@Juan-pu2rv que genial, no haces una documentación por a parte. yo solo lo toqué para probarlo, pero la curva era demasiado amplia y no les gustó en el trabajo el tiempo que tardaría en aprender. jejejeje
@@snithfferx cuánto tiempo les manejaste para la curva?
@@Juan-pu2rv Pues, con mi poco conocimiento en javascript calculé un mes para aprender a usarlo junto con prisma.
En el futuro espero aprenderlo, a pesar que ya le hallan dado de baja.
GraphQL raramente presenta errores porque es un lenguaje de consulta que se basa en un conjunto de reglas y estructuras bien definidas. Sin embargo, es importante tener en cuenta que las implementaciones en JavaScript pueden diferir técnicamente de las de Python o Rust en su funcionamiento. Por lo tanto, aunque GraphQL en sí mismo es robusto, es posible que surjan inconsistencias dependiendo de la plataforma o lenguaje de programación utilizado para su implementación.
Exactamente 👍
Qué inconsistencias puedes mencionar de ejemplo?
Nunca vi la necesidad, es una capa de abstracción innecesaria.
Sobre todo teniendo websockets y tal
totalmente de acuerdo, desde que salio yo lo dije, estamos poniendo un serividor mas en frente de la base de datos, que necesita mas configuracion, mas proteccion, mas optimizacion, cuando podrias hacer las peticiones que necesitas directamente a la base de datos y responder en un api rest.
y GraphQL funciona relativamente facil con mongodb, pero pobre de ti si lo quieres usar con una base de datos relacional. la configuracion que hay que hacer , el rendimiento que se pierde hace que sea mucho peor tenerlo que no tenerlo.
Para BDs relacionales existen ORM, para websockets tienes suscriptions en graphql
Parra empezar GraphQL es un lenguaje de consultas basado en un patrón de diseño no es una tecnología, como patrón de diseño tu lo puedes adaptar achicandolo o acortandolo sin necesidad de que este abierto para N mil consultas por lo tanto cualquier patron de diseño mal implementado tendrás los problemas de seguridad que comenta el articulo. Es decir no puedes echarle la culpa a algo porque simplemente lo implementaste mal.
Jajaja le vas a enseñar al midu
"No lo sabes usar" no es el mejor argumento acá, me parece que se refiere a que tan fácil es cometer esos errores.
Hay ciertas tecnologías o patrones que hacen más fácil cometer esos errores que otras.
Es una opinión subjetiva. El rendimiento de una tecnología depende de tantos factores que hace imposible evaluarla tan fácilmente
Por los comentarios de todos ustedes me doy cuenta que nunca han hecho una api bajo este patron. En fin.
efectivamente
gql + apollo (cache) zarpetaaa
Si tiene 11...m de descarga semanal la librería 😂😂😂😂
Nunca me gustó GraphQL y afortunadamente cuando doy las razones de no usarlo en un proyecto me apoyan y no lo usamos. No sé para mí con un API REST BFF es suficiente.
tRPC for the win.
Uff o sea que el tiempo que vi tu video czcams.com/video/QG-qbmW-wes/video.html para aprender GraphQl fue perdido???
Y yo aprendiendo GraphQl xD
x2
X3, seguiré aprendiendo solo por qué me gusta
Yo nunca me he topado con un proyecto en la vida real que use graphql....
Si hay está Facebook, Shopify, Zendesk, Space X, Tripadvisor, Jira. O te refieres a proyectos donde haz trabajado tú?
CQRS
6 años, no mames te tardaste.
Patrones > Tecnologias
midu no te enojes u_u
xD Pues no hagas que me enfade 🥲
primero