¿Cuándo se recomienda usar GraphQL para una aplicación Ruby on Rails con React?

Antes de sumergirnos en la pregunta en cuestión, tengo que sacar algo de mi pecho. No te dejes seducir por la tecnología. No adopte una nueva herramienta porque es tendencia. GitHub y Facebook dejaron REST atrás para GraphQL. No asuma que si funcionó para ellos, funcionará para usted. Aquí, no ha tenido en cuenta su contexto. En palabras más simples, ¿qué quieres que GraphQL haga por ti? Esto puede parecer un punto obvio, pero antes de adoptar nuevas herramientas, debe educarse sobre sus ventajas y desventajas.

¿Qué es GraphQL?

• Cómo agregar un ícono con contenido en WordPress
• ¿Cuáles son algunas de las ventajas o desventajas de usar Google Firebase?
• ¿Qué plataforma es mejor para el desarrollo web?
• ¿Por qué la página web de la herramienta de validación del W3C no puede ser validada perfectamente por su validador?
• ¿Puedo usar Cloudflare para mi sitio web de red social?

GraphQL es un lenguaje utilizado para definir cómo dos aplicaciones se comunican entre sí. Usted define los tipos de datos, luego las acciones a realizar en esos tipos de datos. Si desea una definición más elegante, GraphQL es un lenguaje para manipular y consultar datos. Vea, en GraphQL, el formato de respuesta se describe en la consulta y lo define el cliente en lugar del servidor. Por eso se llaman consultas especificadas por el cliente. En otras palabras, si su aplicación necesita datos y JSON es la respuesta, GraphQL es la pregunta.

GraphQL es una excelente manera de hacer la pregunta porque alinea la forma en que obtiene datos con la forma en que los desarrolladores y diseñadores de productos piensan sobre el consumo de datos. Recuerde GraphQL es una especificación entre el cliente y el servidor. No es específico de ningún lenguaje de programación. Cualquier cliente debería poder comunicarse con cualquier servidor si habla GraphQL.

La historia de Facebook

GraphQL fue creado por Facebook para resolver algunos de los desafíos que enfrentaron al escalar la red social más grande del mundo. Por lo tanto, ningún artículo sobre GraphQL está completo sin la historia de Facebook. Hasta alrededor de 2007, Facebook era una empresa centrada en la web. Esto fue antes de que los teléfonos móviles tomaran el mundo por sorpresa y las compañías se dieron cuenta de que estos teléfonos inteligentes no eran solo una nueva moda, sino algo para quedarse. De aquí en adelante, Facebook y muchas otras compañías tuvieron que cambiar su estrategia y reorganizar todo, desde la tecnología que practicaron hasta el enfoque que utilizaron para el desarrollo móvil.

Facebook comenzó creando aplicaciones móviles HTML5 en una vista nativa para adaptar su contenido web a los teléfonos inteligentes. La experiencia para las personas que usaban las aplicaciones móviles de Facebook en este momento era previsiblemente terrible. Los navegadores web en teléfonos inteligentes simplemente no podían mantenerse al día con la complejidad de la aplicación de Facebook. Verá, todavía practicaron una idea de último momento móvil y no una estrategia móvil primero. En 2012, Facebook comenzó a construir aplicaciones móviles nativas . No solo reescribieron sus aplicaciones móviles desde cero. Repensaron toda la pila de tecnología.

Con estos cambios en la pila, el centro de gravedad se desplazó al dispositivo del usuario, que en la mayoría de los casos era un teléfono inteligente. El nivel web se convirtió más como un servidor de aplicaciones. Facebook eliminó las API de Restful con una gran cantidad de puntos finales y mega puntos finales, ya que con el tiempo se volvió inmanejable. Se dieron cuenta de que la API de Rest no era el camino a seguir porque la mayoría de los desarrolladores móviles piensan en el diseño de la interfaz de usuario y no en términos de URL de recursos. Verás, cuando piensas en buscar datos, estás pensando en datos gráficos. Esta fue la realización de Facebook, por lo que desarrollaron GraphQL, un lenguaje de consulta para, bueno, gráficos de datos.

Los principios centrales

GraphQL en su núcleo es como un sistema de tipos. El servidor posee un sistema de tipos, y el sistema de tipos expresa todas las capacidades del servidor. Cuando el cliente tiene requisitos, el servidor transmite las capacidades. El cliente pide cosas durante el tiempo de ejecución, y el servidor sabe lo que es posible, y el cliente sabe lo que necesita. Este enfoque permite a los clientes y servidores evolucionar y escalar independientemente uno del otro.

GraphQL habilita un nuevo contrato entre el servidor y el cliente. Con GraphQL ahora, debe admitir varios tipos de contenido (XML, JSON, etc.). Mientras que REST le proporciona una interfaz uniforme entre el cliente y el servidor, lo que significa que hablan en el mismo formato.

La composición es otro principio importante. GraphQL puede ubicar y construir una mega consulta que es una consulta única atendida por backends más distintos o solicitudes internas. Aquí, con GraphQL tendrá que considerar un caso en el que uno de ellos puede fallar, pero hay una solución simple. Dividir las consultas.

¿Dónde es útil GraphQL?

1. La combinación de datos de múltiples puntos es una gran ventaja de GraphQL y también lo es la flexibilidad que le brinda en su modelo de datos.
2. En las API de Rest tiene que versionar su API para evolucionar, mientras que GraphQL le permite evolucionar sin versionar. Esto significa que su API se vuelve menos hambrienta de recursos y más limpia.
3. GraphQL tiene un formato de respuesta flexible. Esto ayuda cuando su cliente móvil o web necesita evitar más consultas y una transformación masiva de datos.
4. Use un servidor GraphQL para facilitar que el desarrollador de su cliente móvil cambie el formato de respuesta sin necesidad de solicitar cambios en el back-end.
5. Con GraphQL, puede describir los datos requeridos de una manera más natural, por eso GraphQL es conocido por acelerar el desarrollo de aplicaciones.

Los puntos de dolor

1. La falta de casos de uso documentados claros tiende a ser un problema. Recuerde que la documentación de la API es más que la descripción de su contrato de interfaz junto con un inventario de consultas y objetos. La API y su documentación juntas son la clave para una buena experiencia de desarrollador.
2. Con las API de REST, puede confiar en el sistema de almacenamiento en caché de HTTP, pero cuando se trata de GraphQL, esta opción ya no está allí. Debe depender del Cliente para manejar el caché. Esto podría no ser un problema en el futuro a medida que GraphQL evoluciona.
3. GraphQL requiere un cargador de datos para ser eficiente. Con GraphQL, debe indicar lo que desea explícitamente. Esto significa que en cada solicitud los consumidores tienen que enviar una consulta completa. Las solicitudes complejas y masivas podrían afectar su infraestructura si tiene un desarrollador perezoso.
4. Es difícil encontrar y mantener buenas convenciones de nombres para consultas, mutaciones y argumentos para todas ellas. La buena noticia es que hay suficientes artículos sobre buenas prácticas de nombres para ayudarlo a superar este problema
5. Algunos usuarios de GraphQL enfrentan un problema con la complejidad que Relay agrega a su modelo de datos.

¿Se recomienda usar Rails, React y GraphQL juntos como una pila tecnológica?

Es difícil darle una respuesta afirmativa o negativa sin comprender el problema que está tratando de resolver. Si React proporciona una ventaja tecnológica para un proyecto en particular que merece su uso, entonces vale la pena garantizar el éxito de esa implementación, aunque es dudoso si React solo proporcionará la infraestructura técnica necesaria. Mira, React es increíble para construir aplicaciones front-end.

Ahora Rails es perfecto para el backend. No hace nada “innovador” en el front-end. Para un proyecto que requiere un backend que cuenta con una base de datos confiable y bien documentada junto con un historial de estabilidad y crecimiento constante, Rails es el camino a seguir. Rails y React ambos funcionan muy bien juntos.

Ahora GraphQL es una gran opción para elegir cuando tienes un front-end dinámico. Desacopla a sus desarrolladores de front-end de sus ingenieros de back-end, permitiendo que ambos hagan sus consultas para obtener los datos que necesitan sin depender el uno del otro. Tomemos el caso de Facebook, prototipan mucho, por lo que esto les ahorra tiempo al eliminar algunas de las comunicaciones de ida y vuelta entre sus desarrolladores de back-end y front-end.

Esto debería ayudarlo a tomar una decisión más informada sobre cuándo usar GraphQL en su próximo proyecto. [1]

Notas al pie

[1] ¿Cuándo se recomienda usar GraphQL para una aplicación Ruby on Rails con React?