Las APIs más populares que utilizamos a día de hoy son RESTful APIs o un pseudo estándar ad hoc HTTP inventado bajo demanda en ciertos proyectos. La necesidad de avanzar más rápido en productos cada vez más complejos, más allá de un simple CRUD, ha empujado un cambio en la forma en que interactuamos con las APIs. Aquí es dónde surge GraphQL, un fuerte candidato a sustituir a REST, sobre todo en el ecosistema de APIs para apps en mobile.
#1 Dentro de veinte minutos veremos en la cola de pendientes "¿Por qué deberíamos abandonar GraphQL y empezar a usar QueryMiau en nuestras APIs?
Aún así, GraphQL parece interesante, sobre todo porque ataca a la raíz, romper el encorsetado CRUD de casi todos los frameworks y API's del momento.
Cada vez se añaden más y más dependencias y capas que al final no simplifican ni facilitan, sino que añaden un quebradero de cabeza adicional y una nueva cosa a dominar para una parte demasiado pequeña de un proyecto. Cuando algo falla (que fallará), tienes que pelearte con el framework/librería en cuestión hasta dar con la chorrada idiosincrática de turno (resulta que faltaba un espacio en blanco en nosédonde y tal parámetro sólo funciona los viernes), perdiendo tiempo que un enfoque más simple (como REST/json) habría resuelto mucho antes.
Un colega que trabaja en investigación informática en una empresa de las grandes grandes una vez me comentó que tras días y días depurando entre cuatro ingenieros una librería Java con capas y capas y más capas para generar un envelope SOAP y que nadie sabía por qué nunca funcionaba con el sevidor a pesar de que todo estaba aparentemente correcto, acabaron mandando la librería a la mierda, comentaron las llamadas y acabaron copiando y pegando el envelope, metiendo el mensaje dentro a huevo con concatenación de strings. Funcionó a la primera, y así sigue.
Quizá en proyectos con una alta complejidad esto pueda ayudar, pero para la mayoría de cosas, que suelen ser sencillas y con casos de uso muy específicos, mejor no complicarlo innecesariamente. En general siempre que tengo que usar un componente o librería nueva me lo pienso muy detenidamente, ya que en la práctica el ahorro de tiempo luego te puede joder por otro lado, normalmente cuando más lo necesitas. La sobreingeniería es muy mala y es fácil caer en ella.
#8 Estoy de acuerdo. Hasta la polla de aprender mierdas para hacer proyectos que de otra manera serían sencillos. Todo esto para sobrecompensar el complejo de inferioridad del programador..
#8 Decenas de frameworks de mierda montados sobre javascript, porque el propio javascript es una mierda pinchada en un palo incapaz de satisfacer las necesidades más básicas de una aplicación normalita. Frameworks que pasan de moda en un par de años, o que sacan una nueva versión incompatible con la que has estado desarrollando.
Comentarios
¿Ya se ha pasado de moda REST? Pero si yo aún estoy aprendiendo SOAP
#1
Dentro de veinte minutos veremos en la cola de pendientes "¿Por qué deberíamos abandonar GraphQL y empezar a usar QueryMiau en nuestras APIs?
Aún así, GraphQL parece interesante, sobre todo porque ataca a la raíz, romper el encorsetado CRUD de casi todos los frameworks y API's del momento.
#2 Porque QueryMiau es el futuro, se lo oí decir a Kofi Annan en una conferencia de desarrolladores
#1
Yo voy por RMI
#1 madre mía, el sistema de mi empresa solo admite SOAP, no sabe ni lo que es JSON... y ya Deberíamos usar otro standard?
Si funciona, no se toca.
Cada vez se añaden más y más dependencias y capas que al final no simplifican ni facilitan, sino que añaden un quebradero de cabeza adicional y una nueva cosa a dominar para una parte demasiado pequeña de un proyecto. Cuando algo falla (que fallará), tienes que pelearte con el framework/librería en cuestión hasta dar con la chorrada idiosincrática de turno (resulta que faltaba un espacio en blanco en nosédonde y tal parámetro sólo funciona los viernes), perdiendo tiempo que un enfoque más simple (como REST/json) habría resuelto mucho antes.
Un colega que trabaja en investigación informática en una empresa de las grandes grandes una vez me comentó que tras días y días depurando entre cuatro ingenieros una librería Java con capas y capas y más capas para generar un envelope SOAP y que nadie sabía por qué nunca funcionaba con el sevidor a pesar de que todo estaba aparentemente correcto, acabaron mandando la librería a la mierda, comentaron las llamadas y acabaron copiando y pegando el envelope, metiendo el mensaje dentro a huevo con concatenación de strings. Funcionó a la primera, y así sigue.
Quizá en proyectos con una alta complejidad esto pueda ayudar, pero para la mayoría de cosas, que suelen ser sencillas y con casos de uso muy específicos, mejor no complicarlo innecesariamente. En general siempre que tengo que usar un componente o librería nueva me lo pienso muy detenidamente, ya que en la práctica el ahorro de tiempo luego te puede joder por otro lado, normalmente cuando más lo necesitas. La sobreingeniería es muy mala y es fácil caer en ella.
Keep It Simple, Stupid.
#8 Estoy de acuerdo. Hasta la polla de aprender mierdas para hacer proyectos que de otra manera serían sencillos. Todo esto para sobrecompensar el complejo de inferioridad del programador..
#8 Decenas de frameworks de mierda montados sobre javascript, porque el propio javascript es una mierda pinchada en un palo incapaz de satisfacer las necesidades más básicas de una aplicación normalita. Frameworks que pasan de moda en un par de años, o que sacan una nueva versión incompatible con la que has estado desarrollando.
#10 Por ejemplo que no tenga un triste sleep o un semáforo.
Vamos camino de volver a tirar querys a la base de datos....
java, javascript, html, css, frameworks, etc ... un lío.