¿Por qué después de 6 años dejé GraphQL? 

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

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

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.

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

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

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

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.

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

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

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

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

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.

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.

Exactamente 👍

Qué inconsistencias puedes mencionar de ejemplo?

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.

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

x2

X3, seguiré aprendiendo solo por qué me gusta

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

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

xD Pues no hagas que me enfade 🥲