GraphQL necesita un revamp como Zustand le hizo a Redux.

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.

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

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.

@cresenciofl4280

23 күн бұрын

@@63ivaan El interesante? jajaja vale "Chulo"

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

@Juan-pu2rv

23 күн бұрын

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

@AndresGambaSalamanca

22 күн бұрын

@@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.

@AndresGambaSalamanca

22 күн бұрын

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.

gracias por el articulo :)

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

@czabala

18 күн бұрын

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.

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

@diegobejardelaguila8614

23 күн бұрын

que arquitectura utilizan o te estan pidiendo hacerlo desde cero?

@ianmanuelpaniagua8823

21 күн бұрын

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.

@diegobejardelaguila8614

20 күн бұрын

@@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.

@ianmanuelpaniagua8823

17 күн бұрын

@@diegobejardelaguila8614 gracias

En mi caso, me gusta usar la implementación OpenApi y un autogenador del cliente para Typescript.

BFF es el patrón Facade de toda la vida

backend for front end es lo que decimos en backend CQRS

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

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 :)

Lo mas interesante. Se podria pasar de graphQL a Eloquent de forma sencilla para que aplique las optimizaciones de query del Eloquent?

@f3rran

23 күн бұрын

Si, había una librería de Laravel que facilitaba esto bastante

@angeloliver2825

23 күн бұрын

@@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.

@f3rran

23 күн бұрын

@@angeloliver2825 bueno, no sé si con GraphQL solamente sé puede, pero con Eloquent puedes darle esa lógica en el modelo y listo

@JesusEnriqueFrancoMartinez

23 күн бұрын

@@f3rran lighthouse @angeloliver2825

Ganas de complicarla... la cosa iba tan bien con una Rest, para que liarla??

La mayoría de esos problemas se resolvieron hace mucho tiempo

Que opinas de OData?

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

Sabías que el QA en graphql no significa query language?

Hola, alguien sabe como hacer ese zoom en un area (cuadrada) especifica?

@Alexitoo_UY

23 күн бұрын

Midu tiene en su blog un apartado sobre eso, aunque creo solo funciona en MacOS

Considero que la tecnología no necesariamente se ajusta a un estándar, la mayoría preferimos estándares.

@larryrzv6173

23 күн бұрын

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.

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í.

@Juan-pu2rv

23 күн бұрын

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

Estoy a punto de comenzar a entrarme al mundo GraphQL y encuentro este video... mmm, no sé qué hacer...

En REST con Odata se puede hacer muchas cosas

@albertoarmando6711

23 күн бұрын

hacia años que no escuchaba mencion a Odata. Lo use en un sistema .net y andaba de maravilla.

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.

mi equipo y yo lo dejamos a los 6 meses.

Y que yo empeze a aprender GraphQL

grapql parece una buena idea pero una ves que aprendes bien como se hacen consultas sql genericas al final terminas prefireindolas

@Juan-pu2rv

23 күн бұрын

Se pueden hacer a través de un ORM

@sapito169

22 күн бұрын

@@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

Para eso existe Hasura para esos permisos Midu controlar todo

y tu lo dejaste por las mismas razones midu? no lo dices en el video

@midulive

21 күн бұрын

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.

Ni malo ni bueno, depende el caso de uso

aguante API Rest con notación JsonAPI y aguante Laravel!

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.

@ElSebitas

Күн бұрын

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.

@ElSebitas

Күн бұрын

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.

@tomasidalgo1285

23 сағат бұрын

@@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.

@ElSebitas

11 сағат бұрын

@@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

@luiscarlospallaresascanio2374

23 күн бұрын

Explicame, no entendí lo que dijiste, apenas estoy empezando xd

@sapito169

22 күн бұрын

​@@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

Los que usamos API REST de toda la vida: Reimos en OpenAPI 3.0

gql + apollo (cache) zarpetaaa

Si tiene 11...m de descarga semanal la librería 😂😂😂😂

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

@Juan-pu2rv

23 күн бұрын

En graphql tus comentarios en la app se convierten en documentación de los "endpoints". Mientras vas programando vas documentando

@snithfferx

20 күн бұрын

@@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

@Juan-pu2rv

20 күн бұрын

@@snithfferx cuánto tiempo les manejaste para la curva?

@snithfferx

18 күн бұрын

@@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.

La gran mayoría de cosas que salen al poco tiempo ya lo vuelven obselto, las cosas que sacan dia a dia es abrumador.

tRPC for the win.

Nunca vi la necesidad, es una capa de abstracción innecesaria. Sobre todo teniendo websockets y tal

@hck1bloodday

23 күн бұрын

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.

@Juan-pu2rv

23 күн бұрын

Para BDs relacionales existen ORM, para websockets tienes suscriptions en graphql

Y yo aprendiendo GraphQl xD

@rennypetit4891

23 күн бұрын

x2

@marcosjavier3715

23 күн бұрын

X3, seguiré aprendiendo solo por qué me gusta

CQRS

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

@Juan-pu2rv

23 күн бұрын

Según midu lo implementó META, eso está lejos de ser el 1%

@LuisM_Santana

22 күн бұрын

@@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?

@EzioEG

21 күн бұрын

@@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.

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.

@midulive

21 күн бұрын

Exactamente 👍

@Juan-pu2rv

21 күн бұрын

Qué inconsistencias puedes mencionar de ejemplo?

Mucho pesar, estaba enamorado con Graphql Y Apollo.. Me mude a Next 14 Full Stack con las server actions

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.

Yo nunca me he topado con un proyecto en la vida real que use graphql....

@cresenciofl4280

23 күн бұрын

Si hay está Facebook, Shopify, Zendesk, Space X, Tripadvisor, Jira. O te refieres a proyectos donde haz trabajado tú?

Uff o sea que el tiempo que vi tu video kzread.info/dash/bejne/g3th08Smh5DdldY.html para aprender GraphQl fue perdido???

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.

@LegionDelFutbol

23 күн бұрын

Jajaja le vas a enseñar al midu

@neociber24

23 күн бұрын

"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.

@tobiasleclercq1076

23 күн бұрын

Es una opinión subjetiva. El rendimiento de una tecnología depende de tantos factores que hace imposible evaluarla tan fácilmente

@cpaez2000

23 күн бұрын

Por los comentarios de todos ustedes me doy cuenta que nunca han hecho una api bajo este patron. En fin.

@senoremc4628

23 күн бұрын

efectivamente

Patrones > Tecnologias

midu no te enojes u_u

@midulive

21 күн бұрын

xD Pues no hagas que me enfade 🥲

6 años, no mames te tardaste.

primero