Ha habido un pedazo de salseo con el tema de GraphQL.
GraphQL, ¿os gusta? ¿No os gusta? ¿Sabéis lo que es?
Bueno, GraphQL fue muy, muy utilizado en su día y sigue vigente.
GraphQL es una tecnología de meta que ellos utilizan en producción.
Sigue habiendo conferencias, como podéis ver, GraphQL Conf en 2024, en septiembre.
Pero, no sé, estaba como en... ha caído como en desgracia.
Porque tenía muchas cosas buenas, la verdad, tenía un montón de cosas positivas a la hora de optimizar el uso del ancho de banda,
de poder traer buenos resultados, tener un solo endpoint para traerte toda la información que querías.
En fin, había un montón de cositas.
Pero, el tema es que poco a poco se vieron las costuras de GraphQL hasta que, a día de hoy, ya no parece que a la gente le guste.
No sé, a veces pasa con las tecnologías esto, que las cosas vuelven, desaparecen.
Y otra vez, mira, hay gente que no le gusta, el espíritu bueno.
Alternativas a GraphQL. Alternativas exactamente a GraphQL, no sé, pero tienes el T3 stack.
T-R-P-C, sería, T-R-P-C. Este sería, T-R-P-C.
Pero si no tienes cualquier backend for frontend.
Un backend for frontend es una alternativa a GraphQL.
E incluso un REST API no dejase también una alternativa a GraphQL.
Que no es exactamente lo mismo, porque GraphQL es un query language, es una forma de pedir los datos,
porque tú en GraphQL lo puedes utilizar por encima de un REST, por ejemplo.
Pero cualquier cosa que te permita obtener información del backend, pues ahí lo tendrías como alternativa a GraphQL.
El tema es que de pasado tantos años, fijaos, hay gente que escribe cosas como esta.
¿Por qué después de 6 años ya he superado GraphQL y por qué no lo recomendaría?
Este artículo está muy chulo, es bastante largo, tiene bastantes comentarios y os recomiendo mucho, mucho que lo leáis.
Sobre todo si utilizáis GraphQL o estáis pensando utilizarlo o dejar de utilizarlo, que también puede ser interesante.
¿Por qué? Porque explica con total exactitud las razones por las que puede ser no tan buena idea.
Que puedes estar de acuerdo o no.
Por ejemplo, yo hay cosas que al final las puedes mejorar, puedes decir, muchos de los ataques que comentan aquí de temas de seguridad,
al final las puedes parchear y problemas de seguridad puede haber en todos los patrones, arquitecturas o cualquier cosa.
Pero aún así es interesante al menos para que las conozcas, porque muchas veces a lo mejor no las conoces y se te pueden escapar.
Hay unas que son muy interesantes de cómo atacar un GraphQL.
Por ejemplo, al pedir los esquemas, puedes pedir los esquemas de GraphQL con todos los tipos de nombre posibles de la API y puedes reventar una API con una query.
Esto está bastante chulo.
Y aunque a lo mejor no la revientes con una sola query, al menos sí que puedes hacer que te devuelva megas.
Que devuelva megas y megas de JSON porque eso no está limitado.
Entonces le podéis echar un vistazo justamente para eso, para decir, ostras, voy a ver si esto pasa porque alguien podría atacar mi API de GraphQL simplemente haciendo esto.
Y es que aquí lo tenéis. Si hacéis esto, lo que podéis hacer es que haya una introspección cíclica de toda la API y esto lo que haga es generar un JSON que sea megas y megas y megas y megas.
O al revés, que puede ser que no sea de megas la respuesta, pero que tarde segundos en responder.
Y claro, algo que tarda segundos al final lo puedes utilizar para atacar para que te cueste dinero la API o un montón de cosas.
Está bastante interesante, veis, aquí también para hacer cosas cíclicas.
Y esto el problema es que a lo mejor te devuelve algo que es muy pequeño, pero que en cambio lo que está haciendo es tener un montón de ataques internos.
Aquí tenéis también cómo utilizar un rate limit en REST, que es mucho más fácil, pero que en GraphQL suele ser un poquito más complicado.
Bueno, temas de rendimiento, veis aquí tenéis el rendimiento, el problema del data fetching del N más 1.
Bueno, esto es que para hacer las queries en GraphQL es mucho más fácil, pero en cambio al hacerlo, o sea en GraphQL es mucho más difícil, pero hacerlo en REST se suele entender mucho más fácil.
O también en temas de privacidad, porque hay veces que puedes pedir datos de los que se supone que no deberías tener acceso.
Por ejemplo, este suele ser un ataque bastante típico, en el que tú, por ejemplo, al estar autentificado, se supone que puedes acceder a cierta información en Twitter.
Imagínate que esto es una query de Twitter.
Puedes tener acceso al handle, pero el email no debería ser público.
Entonces, en GraphQL hacer que por campo tengas diferentes permisos puede ser un poco complejo.
No es imposible, pero conforme los objetos van creciendo, el hacer un control granular de los campos puede ser bastante difícil.
Y hay muchas veces que muchos ataques de APIs vienen por aquí, ¿no?
En el que tú vas diciendo por aquí, vale, pues ahora que estoy autentificado y aunque yo no pueda ver que puedo recuperar el campo email, lo voy a intentar.
Y así, pues te pones a mirar un montón de campos y a veces puedes acceder a información de la que se supone que no deberías ver.
Es un artículo muy chulo que os recomiendo que os leáis, aunque sea, como os digo, a lo mejor puede ser que os venga súper bien.
No pasa nada y lo podéis utilizar, pero al menos que tengáis en cuenta los posibles ataques que hay.
Aquí habla de algunas alternativas, para que lo sepáis, ¿eh?
Porque dice, mira, definitivamente he acabado con el Hype Cycle porque el tema del Hype Cycle es que a veces hay una nueva tecnología, hay mucho hype y a tomar por saco.
Dice, quizás es mejor que utilices un JSON REST API que cumpla con OpenAPI 3.0.
Muchas veces las cosas como son, un OpenAPI, o sea, un JSON REST API, pues suele ser la más fácil en muchos términos.
Es una implementación muy sencilla, que puedes tener una especificación de OpenAPI muy buena, que está todo tipado, que además te puede ayudar a detectar recursos y tal,
y que es lo suficientemente buena como para que te dé los recursos lo suficientemente rápido y poder crear lo que necesites.
A partir de ahí, otro patrón que es muy interesante es el backend for frontend, que antes me preguntaba, ¿qué es un backend for frontend y tal?
El backend for frontend al final es un patrón, no sería una tecnología en concreto, pero es un patrón en el que al final lo que haces es crear un backend que está pensado para el frontend.
Porque hay muchos backend que están diseñados de forma neutra, como para que cualquier cliente, independientemente si es frontend, si es otro backend, una inteligencia artificial o lo que sea, lo pueda consumir.
Y un backend for frontend, la idea es poner una capa que hace que optimice los recursos.
Por ejemplo, si tú tienes una página web donde tienes que mostrar unos resultados, en lugar de hacer cuatro peticiones a una REST API,
a lo mejor lo que haces es preparar un backend for frontend muy masticadito, que sea una sola llamada y que internamente ya va a buscar esas cuatro APIs totalmente diferentes.
Y va a ser mucho más rápido, porque desde el cliente solo haces una sola query, que ya vas directo ahí y en el otro sitio, desde el backend, en el backend for frontend, ya optimizas todas las requests, están mapeando los datos y todo esto.
Eso sería un poco la idea. ¿Por qué? Porque si tú tienes que tirar del REST API y tienes que hacer la búsqueda, recuperar la información de cada cart, también del usuario, también de esto y tal, pues la optimización se va perdiendo por el camino.
Así que ahí tendrías una posible opción. Por lo general, el backend for frontend usa GraphQL. Claro, GraphQL se podría considerar en ocasiones que podrías hacer esto,
pero backend for frontend lo puedes hacer con cualquier tecnología. No se trata de que con GraphQL o sin GraphQL. No se trata de la tecnología, se trata de un patrón. Punto.
Ya está. O sea, no penséis en... Se utiliza con... Es un patrón que está pensado para optimizar el backend.
No sé si soy yo que me equivoco o me he perdido algo, pero ¿no era esta semana la review de portfolios con la chica diseñadora?
Efectivamente, te pierdes algo porque lo hemos comentado hace un momento que era el miércoles. Y de hecho, tenemos... Mira, aquí tienes. Miércoles a las 6 revisando webs y portfolios.
Es esta semana. O sea, no sé lo que te habrás perdido, pero te habrás perdido el directo. Hemos estado comentando justamente esto. O sea, que es este miércoles.
Mi Du, me gustaría que un stream nos muestres un ejemplo práctico de BFF. Muchas gracias. Saludos desde Perú.
La verdad...
Ya que sé, tienes el tiempo ajustado.
Hemos hecho un montón de backend for frontend. Un backend for frontend muy típico es el que normalmente se hace en los proyectos de NextGS.
Cuando tú estás en un proyecto de NextGS y creas un endpoint que muchas veces va a más de una base de datos, que hace más de una cosa,
al final estás optimizando ese endpoint de la API para el frontend, ¿no? O sea, es algo muy específico optimizado para utilizarlo en ese cliente en concreto.
No estás creando como una API general que cualquiera puede consumir, sino que muchas veces las APIs que estás creando están diseñadas para mejorar el rendimiento
o para que se consuman directamente desde tu aplicación de NextGS. Pero bueno, lo podemos hacer un día para que lo veamos.
Pero ya te digo yo que cuando lo veáis, lo hemos hecho tantas y tantas veces.