Header Ads Widget

Ticker

6/recent/ticker-posts

Mejores prácticas para una implementación de GraphQL saludable


 Hemos hablado de GraphQL en profundidad anteriormente, y aunque las discusiones sobre cómo funciona GraphQL son obviamente muy poderosas, todavía tenemos que sumergirnos en algunas de las mejores prácticas que deben adoptarse al desarrollar una API centrada en GraphQL.

Hoy vamos a hacer exactamente eso. Vamos a discutir las mejores prácticas para una implementación saludable de GraphQL y describir por qué se recomiendan estas prácticas. Al integrar correctamente estas mejores prácticas como una cuestión de rutina, su implementación impulsada por GraphQL y su estructura API asociada pueden ser más poderosas, eficientes y prácticas.

Dogma vs Prácticas

Antes de sumergirnos demasiado en esto, hay que decirlo: estas son las mejores prácticas sugeridas, no un dogma absoluto. Si bien la mayoría de las prácticas incluidas en este documento son aplicables a la mayoría de la instalación, los casos de uso y el diseño de API, existen algunas situaciones en las que el diseño o la aplicación de su API no funcionarán bien con algunos aspectos de GraphQL, mientras que requieren otros aspectos.

En tales casos, estas mejores prácticas deben considerarse una guía , no una instrucción dogmática sobre cómo se debe implementar GraphQL.

URI y rutas

Si bien GraphQL es fundamentalmente RESTful , elimina algunos elementos que se han convertido en el núcleo del diseño RESTful, como los recursos . Donde la mayoría de las API REST usan recursos como una conceptualización básica de cómo se procesan y devuelven los datos, GraphQL evita esto y, en su lugar, depende de las entidades definidas por un gráfico de entidad. Este gráfico de entidad dirige todo el tráfico a una única URL o punto final, que es la entrada frontal del sistema.

En consecuencia, los URI y las rutas deben conducir a un solo punto final; este es el caso de uso fundamental de GraphQL y es el principio de su funcionalidad.

Intercalación de puntos finales y HTTP

Por su naturaleza, GraphQL atiende solicitudes de verbos a través de un único punto final en HTTP. Este aspecto de GraphQL es fundamental para su diseño y enfoque hacia la recopilación de puntos finales; como tal, el uso de una metodología que no sea un punto final recopilado en HTTP está bloqueando muchas funciones.

En el formato REST clásico, los recursos se exponen a través de un conjunto de URL y cada URL tiene un punto final específico que está vinculado como parte de la solicitud formateada. Si bien GraphQL ciertamente puede coexistir con este tipo de configuración, tener tal colección de recursos detrás de los URI desafía el propósito de la implementación de GraphQL en primer lugar.

En consecuencia, si necesita adoptar tal práctica de enlace híbrido (también conocido como un solo punto intercalado y luego un grupo de URL que representan recursos individuales), sería recomendable analizar su diseño, esquema y formato, y abordar si en realidad, esto está previsto antes de continuar con dicho sistema en GraphQL.

Control de versiones de API

GraphQL es un esquema y, como tal, no hay nada que impida que su API realice el control de versiones como desee. Dicho esto, GraphQL ha declarado una fuerte evitación del control de versiones desde un punto de vista filosófico. El punto de vista declarado de GraphQL es el siguiente:

“¿Por qué la mayoría de las API tienen versión? Cuando existe un control limitado sobre los datos que se devuelven desde un punto final de la API, cualquier cambio puede considerarse un cambio rotundo y los cambios rotundos requieren una nueva versión. Si agregar nuevas funciones a una API requiere una nueva versión, entonces surge una compensación entre lanzar con frecuencia y tener muchas versiones incrementales versus la comprensibilidad y mantenibilidad de la API ".

En consecuencia, GraphQL considera que, dado que la solución solo devuelve datos solicitados explícitamente, no existe un "cambio radical" en las API GraphQL diseñadas correctamente. Esto es un cambio definitivo de versionado API a versionless , y es parte de la filosofía de diseño de por sí GraphQL.

Eso no quiere decir, por supuesto, que el control de versiones deba ser una práctica de todo o nada. Es muy fácil simplemente versionar documentando los cambios y refiriéndose a la API por un número de versión establecido; sin embargo, esto es mucho más una consideración organizacional interna y, por lo tanto, queda fuera de la definición común de control de versiones verdadero. Como tal, es mejor llamar a esto un proceso de revisión en lugar de un proceso de control de versiones.

Consulte también: Más de 10 herramientas y extensiones increíbles para las API GraphQL

Nulabilidad y escritura predeterminada

Normalmente, las API manejan la nulabilidad en dos pasos: con un tipo común "nulo" y luego una versión "nulable" de ese tipo, específicamente para separar los dos tipos entre sí y permitir la anulación mediante una declaración específica de dicho tipo. Todo esto está muy bien, y de hecho es una buena práctica en sí misma, pero debido a cómo GraphQL está estructurado y definido, esto en realidad no funciona dentro del esquema.

En consecuencia, la mejor práctica para la anulación en GraphQL es recordar que este tipo nulo es, de hecho, una configuración predeterminada para cada campo. Esto se integró en GraphQL como una metodología para administrar fallas de una variedad de causas internas y externas y, como tal, funciona bien para los propósitos previstos.

Como corolario de esto, tenga en cuenta que si se requiere un valor no nulo, se puede establecer como un tipo no nulo; independientemente, es importante recordar este enfoque de nulabilidad predeterminado al abordar problemas en la etapa de retorno de la recuperación de datos .

Paginación

La paginación en GraphQL es casi enteramente competencia del desarrollador. GraphQL permite valores listados como una devolución y, a medida que esos valores listados aumentan de tamaño, la forma en que se devuelven depende de las restricciones creadas por el propio propietario de la API.

GraphQL permite un patrón conocido como " Conexiones ". Este elemento de GraphQL permite no solo descubrir información sobre elementos relacionados específicos, sino también sobre las relaciones en sí. Adoptar colecciones es una práctica recomendada, ya que se vincula con otras suites y herramientas GraphQL como Relay, que pueden admitir automáticamente la paginación del lado del cliente en ese formato común.

Dependencia de JSON y GZIP

GraphQL está diseñado para responder a solicitudes mediante JSON. A pesar de esto, no se requiere expresamente en la especificación y, de hecho, GraphQL puede funcionar con una variedad de tipos de respuesta. Dicho esto, es una buena práctica adoptar JSON debido a su organización centrada en texto, ya que GraphQL está diseñado expresamente para funcionar con compresión GZIP de alta relación.

Curiosamente, GraphQL está diseñado con la sintaxis de JSON en mente y, como tal, es una buena idea mantener esta sintaxis consistente tanto en el diseño como en la respuesta. Asimismo, GraphQL sugiere que los clientes respondan con lo siguiente adjunto en el encabezado:

Accept-Encoding: gzip

Esto permitirá una compresión aún mayor de los datos de respuesta y debería resultar en una menor sobrecarga y un mayor rendimiento de la red. No necesariamente tiene que adoptar JSON, especialmente si está adoptando GraphQL después de que su API ya haya sido diseñada y se le haya dado un formato de salida específico, pero no adoptar JSON puede resultar en una disminución de la eficiencia y confusión entre la base de usuarios al comparar la salida con el código que genera dicha salida.

Agrupar para abordar la charla

GraphQL es, por defecto, extremadamente hablador . Esto se debe simplemente a cómo se forma GraphQL, cómo se recopilan y devuelven los datos, y cómo solicita la dirección del servidor. Esta charla puede ser un obstáculo, especialmente cuando se realizan solicitudes de datos a gran escala desde una base de datos.

Bajo GraphQL, la solución es simplemente lote estas solicitudes en un período determinado de tiempo, el cotejo de ellos, y luego la presentación de las solicitudes múltiples como una única solicitud, cotejado con el sistema en cuestión.

Esto, a su vez, elimina gran parte de la charla, ya que ya no está emitiendo múltiples solicitudes empaquetadas y clasificadas a múltiples elementos de un servidor habilitado para GraphQL; en su lugar, está agrupando paquetes de solicitudes, lo que resulta en una solución GraphQL pasiva en GraphQL que crea una solución relativamente Sistema “silencioso” para la cantidad de datos que se solicitan.

Esto no tiene que estar habilitado, por supuesto, y para proyectos más pequeños, podría tener sentido no hacerlo, de modo que los problemas en la solicitud se puedan identificar y destacar. Dicho esto, cuando se maneja una cantidad sustancial de datos, la adopción de lotes es probablemente una buena idea.

GraphQL está diseñado de una manera que le permite escribir código limpio en el servidor, donde cada campo de cada tipo tiene una función enfocada de un solo propósito para resolver ese valor. Sin embargo, sin una consideración adicional, un servicio GraphQL ingenuo podría ser muy "hablador" o cargar datos repetidamente desde sus bases de datos.

Nota: GraphQL sugiere que parte de este procesamiento por lotes se puede realizar utilizando herramientas GraphQL como DataLoader . Si bien este es un método absolutamente aceptable, adoptar el procesamiento por lotes internamente como parte de su código será más poderoso que cualquier herramienta de terceros y, si es necesario, debería implementarse como parte de la arquitectura base.

Deshabilitar GraphiQL en entornos de producción

GraphiQL es un gran punto de venta para muchos usuarios de GraphQL, pero aunque es extremadamente poderoso, debería deshabilitarse en producción. Esta recomendación proviene de la documentación oficial de GraphQL . GraphiQL debe desactivarse debido a varias vulnerabilidades que podrían exponer inadvertidamente la funcionalidad de la API interna al explorar el punto final primario orientado hacia adelante. Habilitar GraphiQL esencialmente niega muchas de las razones por las que está integrando GraphQL en primer lugar.

Prácticas de autorización GraphQL

GraphQL señala específicamente en su documentación de especificaciones que toda autorización debe realizarse en la capa de lógica empresarial . Esto se especifica debido a cómo funciona GraphQL. El uso de la lógica de autorización que comprueba los elementos del proceso de validación del punto de entrada, como "tiene ID de autor" o "lleva el token correcto", significaría que, para cada punto de entrada posible, esta lógica tendría que duplicarse, lo que conduce a una implementaciones incluso para pequeñas cantidades de controles de autorización.

En consecuencia, GraphQL dicta que esto debe hacerse en la capa de lógica empresarial para que los controles de autorización solo deban especificarse una vez para la totalidad de esa clase específica. GraphQL señala que esto se considera fundamentalmente como una " única fuente de verdad para la autorización ".

Más sobre seguridad : puntos de seguridad a considerar antes de implementar GraphQL

Modelo de canalización GraphQL

Como parte de este enfoque hacia la autorización, GraphQL advierte que todo el middleware de autenticación debe venir antes que la implementación de GraphQL para evitar los mismos problemas con la autenticación . Todos los filtros, complementos, extensiones, etc. deben colocarse antes de GraphQL para permitir la sesión y la información del usuario en su forma final para un control granular y singular.

Conclusión

Como se indicó al principio de este artículo, nuestro objetivo es compartir consejos en lugar de dogmas cuando analicemos estas mejores prácticas. La mejor práctica de todas es adoptar soluciones que se adapten a su caso de uso específico . Considere estas mejores prácticas de GraphQL como pautas en lugar de reglas inamovibles, pero en su mayor parte, la adopción de estas mejores prácticas y la implementación de GraphQL como se diseñó conducirá a un sistema más potente, más ágil y más eficiente. La falta de adherencia puede resultar en que muchos de los beneficios de GraphQL desaparezcan tan rápido como su número de puntos finales.

Para conocer todas las perspectivas de las API nórdicas sobre GraphQL, asegúrese de descargar nuestro eBook GraphQL o Bust

Publicar un comentario

0 Comentarios