principio de integridad
Asegúrese de que el gráfico esté bien definido, estable y consistente
1. Gráfico único
你的公司应当只有一个统一的图，而不是多个团队分别创建的多个图。
Con solo un gráfico, puede maximizar el valor de GraphQL:
se puede acceder a más datos y servicios con una sola consulta.
El código, las consultas, las habilidades y la experiencia son transferibles entre equipos.
Todos los usuarios del gráfico pueden ver un catálogo central de todos los datos disponibles.
Costos de implementación Minimizados, porque no hay necesidad de duplicar el trabajo de implementación de gráficos La
administración central de gráficos, por ejemplo, políticas de control de acceso unificadas, se vuelve posible
Cuando diferentes equipos crean gráficos separados por separado sin esfuerzos coordinados, las brechas en los gráficos son casi inevitables, por lo que los mismos datos solo se pueden agregar al gráfico de formas incompatibles. En el mejor de los casos, puede ser costoso volver a trabajar; en el peor, puede ser confuso. Este principio debe seguirse lo antes posible en el uso de gráficos de datos por parte de una empresa.
2. Realización conjunta
虽然只有一个图，但该图应该由多个团队联合实现。
Las arquitecturas monolíticas son difíciles de escalar sin una infraestructura altamente especializada y los gráficos de datos no son una excepción. En lugar de implementar toda la capa de gráficos de datos de una organización en una sola base de código, la responsabilidad de definir e implementar el gráfico debe dividirse entre varios equipos. Cada equipo debe ser responsable de mantener la parte del esquema que expone sus datos y servicios, al mismo tiempo que tiene la flexibilidad para desarrollarse de forma independiente y ejecutarse en sus propios ciclos de lanzamiento.
Esto preserva el valor del gráfico como una sola vista unificada mientras desvincula los esfuerzos de desarrollo en toda la empresa.
3. Seguimiento del esquema en el registro
注册和追踪图时应当有一个单一的事实来源。
Al igual que rastrear el código fuente en un sistema de control de versiones, es importante rastrear la definición de un gráfico en un registro de esquema. Su empresa debe tener un registro de esquema único que actúe como la definición autorizada del gráfico, en lugar de confiar en cualquier proceso que se esté ejecutando actualmente o en el código registrado en la computadora portátil de un desarrollador. Al igual que un sistema de control de código fuente, un registro de esquema debe almacenar un historial de cambios y quién los creó, y debe comprender el concepto de múltiples versiones de un gráfico (como etapas, producción o diferentes ramas de desarrollo), hasta cierto punto similar al proceso de desarrollo de software.
El registro de esquema debe ser el eje central del sistema, potenciando las herramientas de desarrollo, los flujos de trabajo o cualquier proceso comercial que se beneficie del gráfico de datos y cualquier cambio real o propuesto en él.
4. Esquema abstracto orientado a requisitos
Schema 应当作为抽象层以隐藏服务实现细节并为消费者提供灵活性。
Uno de los grandes valores de GraphQL es que proporciona una capa de abstracción entre los servicios y los consumidores, por lo que los esquemas no deben estar fuertemente acoplados a implementaciones de servicios específicos o consumidores existentes específicos. Al separar los detalles de implementación del esquema, es posible refactorizar servicios que implementan relaciones gráficas, por ejemplo, cambiar de una arquitectura monolítica a una arquitectura de microservicios, o cambiar el idioma de implementación de un servicio, sin afectar las aplicaciones existentes. Del mismo modo, los esquemas no deben asociarse a la forma en que una aplicación en particular recupera datos. Si la nueva aplicación es muy similar a la anterior, solo se requerirán modificaciones menores en las relaciones de gráficos.
Para lograr este objetivo, utilizamos un esquema orientado a los requisitos: centrándonos en proporcionar una buena experiencia de desarrollo, facilitando a los desarrolladores el uso de las relaciones de gráficos existentes para desarrollar nuevas funciones. Apuntar a este estándar evita que la relación gráfica se acople a una implementación de servicio que cambiará y aumenta el valor de reutilización de cada campo agregado a la relación gráfica.
5. Desarrollo de esquemas utilizando métodos ágiles
Schema 应当根据实际需求增量构建，并随着时间的推移平滑演进。
Es muy tentador definir de antemano el "esquema perfecto" para todos sus datos. Sin embargo, lo que realmente hace que un esquema sea valioso es satisfacer las necesidades de los usuarios, pero las necesidades nunca se conocen por completo y siempre cambiarán. El verdadero camino hacia un "esquema perfecto" es construir una relación gráfica que sea fácil de evolucionar con los cambios en los requisitos reales.
Los campos no deben agregarse sobre la base de suposiciones. Idealmente, cada campo tiene requisitos adicionales para un consumidor específico y debe diseñarse de manera que pueda ser reutilizado por requisitos similares de otros consumidores.
La actualización de las relaciones de grafos debe ser un proceso continuo. En lugar de lanzar nuevas "versiones" de relaciones gráficas periódicamente (por ejemplo, cada 6 o 12 meses), es mejor poder revisarlas varias veces al día si es necesario. Se pueden agregar nuevos campos en cualquier momento. Para eliminar un campo, primero debe marcarlo como obsoleto y luego esperar hasta que ningún consumidor lo esté usando antes de eliminarlo. El registro de esquemas permite la evolución ágil de las relaciones de gráficos y, a través de procesos y herramientas relacionados, todos pueden estar al tanto de los cambios de campo que los afectan. Esto garantiza que solo los cambios completamente examinados entren en producción.
6. Mejorar iterativamente el rendimiento
性能管理应当是一个连续的、数据驱动的过程，可以平滑地适应不断变化的查询负载和服务实现。
La capa de relación del gráfico de datos es un excelente lugar para mantener conversaciones sobre el rendimiento y la capacidad entre los equipos de servicio y los desarrolladores de aplicaciones que consumen sus servicios. Esta sesión es un proceso continuo que permite a los desarrolladores de servicios comprender de manera continua y proactiva cómo los consumidores usan los servicios.
En lugar de optimizar todos los usos posibles de las relaciones gráficas, se recomienda centrarse en proporcionar situaciones de consulta que realmente se necesitan en el entorno de producción. Las herramientas relevantes deben extraer los escenarios de consulta propuestos recientemente y presentar sus requisitos de latencia y los volúmenes de consulta estimados a todos los equipos de servicio afectados antes de entrar en producción. Una vez que la consulta está en producción, su desempeño se monitorea continuamente. Cuando se implementa este principio, los problemas se pueden atribuir a los servicios que no se comportan como se esperaba.
7. Uso de metadatos de gráficos para ayudar a los desarrolladores
开发人员应当在整个开发过程中对图充分了解。
Uno de los principales valores de GraphQL son las enormes ganancias de productividad que brinda a los desarrolladores. Para maximizar esta mejora, las herramientas de desarrollo deben proporcionar a los desarrolladores una comprensión más general del gráfico de datos, y los desarrolladores deben usar estas herramientas durante todo el ciclo de desarrollo.
Siempre que los desarrolladores trabajen en la gestión de datos o la conectividad de servicios, sus herramientas deben poner al alcance de la mano información en tiempo real sobre las relaciones de gráficos. Esta información debe estar siempre actualizada, y las herramientas deben ser muy inteligentes, capaces de aplicar la percepción de las relaciones gráficas al trabajo en cuestión de una manera poderosa y eficiente. Cuando se termina el trabajo, no solo se mejora la productividad y la felicidad de los desarrolladores, GraphQL también conecta los equipos front-end y back-end, lo que permite conversaciones fluidas entre los equipos a lo largo del ciclo de desarrollo.
Aquí hay algunos casos de uso del mundo real para herramientas de reconocimiento de gráficos de datos:
Tan pronto como el desarrollador escribe esta consulta, la documentación en tiempo real de los datos gráficos y los servicios utilizados se proporciona en su editor, siempre actualizado.
La información sobre los campos en desuso se puede transmitir a los editores de los desarrolladores que usan esos campos, junto con los campos alternativos sugeridos.
Las estimaciones de costos (latencia o recursos del servidor) para una consulta se pueden proporcionar después de que el desarrollador haya escrito la consulta, en función de los datos de producción en tiempo real.
El equipo de operación y mantenimiento puede rastrear la carga del servicio de back-end hasta la aplicación, versión, función e incluso la línea de código específicos, para que puedan comprender completamente cómo los desarrolladores usan sus servicios.
Cuando un desarrollador de servicios cambia el esquema, el impacto del cambio se puede determinar automáticamente como parte de la integración continua. Si un cambio rompe los clientes existentes (determinado al reproducir el uso de producción reciente), los desarrolladores de servicios pueden determinar qué clientes, versiones y desarrolladores específicos se verán afectados.
A medida que los desarrolladores de aplicaciones crean funciones, se pueden extraer del código nuevas consultas para respaldar esas funciones y compartirlas con el equipo de operaciones. Armado con este entendimiento, si no se puede aprobar el tamaño de consulta esperado, el equipo de operaciones puede intervenir temprano en el proceso de desarrollo y proporcionar de manera proactiva la capacidad para respaldar la escala requerida.
Cuando una aplicación se desarrolla utilizando un lenguaje de tipos como TypeScript, Java o Swift, la información de tipo se puede propagar desde la declaración de tipo del servicio a cada línea de código de la aplicación, lo que garantiza la corrección de tipo de pila completa y la retroalimentación instantánea de errores. mensajes
8. Control de Acceso y Demanda
基于每个客户端授予对图的访问权限，并管理客户端可以访问的内容和方式。
La autorización en un gráfico de datos tiene dos aspectos igualmente importantes: el control de acceso, que dicta a qué objetos y campos puede acceder un usuario, y el control de requisitos, que dicta cómo (y cuánto) un usuario puede acceder a esos recursos. Si bien a menudo se lo denomina control de acceso, también se debe prestar atención al control de requisitos, ya que es fundamental en cualquier implementación de producción de GraphQL. Es un error permitir que los usuarios ejecuten cualquier consulta posible sin importar el costo, lo que imposibilita administrar su impacto en los sistemas de producción. Ya sea que se realice control de acceso o demanda, debe realizarse con pleno conocimiento de la semántica y el rendimiento del gráfico de datos. Sin analizar las consultas realmente enviadas, no se debe limitar el número de consultas por minuto para un usuario, ya que las consultas pueden acceder a una gama bastante amplia de servicios y el costo de las consultas puede variar en órdenes de magnitud.
La autenticación en el gráfico de datos también tiene dos aspectos: la aplicación que solicita la operación y el usuario que usa la aplicación. Si bien el control de acceso puede estar centrado en el usuario, el control de requisitos al menos garantiza el mismo control a nivel de aplicación y control a nivel de usuario, ya que las situaciones de consulta específicas son responsabilidad del desarrollador de la aplicación, no del usuario de la aplicación.
Las mejores prácticas para el control de la demanda incluyen:
Cuando los usuarios no autenticados acceden al sistema de producción, solo deberían poder enviar consultas en la aplicación que fueron registradas previamente por el desarrollador autenticado, en lugar de permitirles enviar consultas arbitrarias utilizando las credenciales de la aplicación. Sin embargo, esta restricción se puede relajar para las aplicaciones internas distribuidas solo a usuarios de confianza.
Para las aplicaciones que se espera que envíen un gran volumen de consultas, los equipos deben diseñar un flujo de trabajo de aprobación de consultas que se alinee con el ciclo de desarrollo de software más amplio para revisar las consultas antes de que entren en producción. Esto garantiza que no obtengan datos innecesarios y que la capacidad del servidor correspondiente esté preparada de antemano para admitirlos.
Como segunda línea de defensa, estimar el costo de las consultas antes de ejecutarlas y establecer presupuestos de costos de consultas a nivel de usuario y de aplicación puede evitar el uso excesivo de operaciones registradas previamente o escenarios donde las operaciones registradas previamente no se pueden usar.
Los desarrolladores deberían poder deshabilitar aplicaciones específicas para que no envíen consultas específicas en producción, por ejemplo, como una red de seguridad en caso de emergencias o cuando se descubre que aplicaciones de terceros usan gráficos de datos de manera inaceptable.
9. Registros estructurados
捕获所有图操作的结构化日志，并以之为主要工具了解图的使用情况。
Se puede capturar una gran cantidad de información sobre cada operación (lectura o escritura) realizada en una relación gráfica: qué usuario y qué aplicación realizó la operación, a qué campos se accedió, cómo se realizó realmente la operación, el efecto de la ejecución, etc. . Esta información es extremadamente valiosa y debe capturarse sistemáticamente para su uso posterior. En lugar de un registro de texto, debe capturarse en un formato estructurado y legible por máquina para aprovecharlo al máximo.
Un registro de operaciones relacionales gráficas se llama traza. El seguimiento debe reunir toda la información relevante sobre una acción en un solo lugar, incluida la información comercial (quién realizó la acción, a qué se accedió o cambió, qué desarrollador creó qué función de la aplicación, si tuvo éxito, qué tan bien funcionó) y pura Información técnica (a qué servicio de back-end se llama, cómo cada servicio genera latencia, si se utiliza el almacenamiento en caché).
Debido a que los trazos capturan cómo se usan las relaciones gráficas, se pueden usar para una amplia variedad de propósitos:
Saber si un campo en desuso se puede eliminar y, en caso contrario, encontrar aquellos clientes que acceden a él, analizar la importancia de esos clientes y
predecir el tiempo de ejecución de una consulta en tiempo real: cuando un desarrollador escribe una consulta en el IDE, ese Se puede derivar en tiempo real en función de los datos de producción.
Detecta automáticamente problemas en la producción (como un aumento de la latencia o las tasas de error) y diagnostica su causa raíz
.
¿más a menudo?)
Genere facturas para los socios en función del uso de la API, así como modelos de costos detallados que se pueden generar en función de los campos específicos a los que se accede o de los recursos
consumidos Hay un flujo de seguimiento autorizado. Este flujo luego se puede canalizar a otros sistemas de observación (lo que posiblemente requiera una transformación simple para los sistemas existentes que no son compatibles con GraphQL), o se puede almacenar en uno o más almacenes de datos para su uso posterior (muestreo, resumen y luego transformación en presupuestos, caso de uso y tamaño de los requisitos).
10. Separe la capa GraphQL de la capa de servicio
采用分层架构将数据图功能分解为单独的层，而不是融入到每个服务中。
En la mayoría de las tecnologías API, excepto durante el desarrollo, el cliente no se comunica directamente con el servidor. En su lugar, se adopta un enfoque en capas, con problemas como el equilibrio de carga, el almacenamiento en caché, la ubicación del servicio o la gestión de claves API que se superponen por separado. Luego, estas capas se pueden diseñar, operar y escalar por separado de los servicios de back-end.
Lo mismo se aplica a GraphQL. En lugar de consolidar toda la funcionalidad necesaria para un sistema completo de gráficos de datos en cada servicio, la mayor parte de la funcionalidad del gráfico de datos debe extraerse en una capa separada que se encuentra entre el cliente y el servicio, lo que permite que cada servicio se centre en manejar las solicitudes específicas de los clientes. Esta capa puede constar de múltiples procesos, como realizar funciones como control de acceso y control de demanda, federación, recopilación de seguimiento y almacenamiento en caché. Algunas partes de esta capa son específicas de GraphQL y requieren un conocimiento profundo del gráfico de datos, mientras que otras funciones, como el balanceo de carga y la autenticación de clientes, pueden usar sistemas existentes.
Incluso en escenarios simples con solo una aplicación y un servicio, esta capa única puede ser valiosa; de lo contrario, la funcionalidad que debería pertenecer a la capa intermedia debe implementarse en el servidor. En una aplicación compleja, esta capa podría parecer un sistema geodistribuido: las consultas entrantes se reciben a través de múltiples puntos de entrada, las cachés perimetrales se aprovechan para procesar consultas de la red perimetral, los subcomponentes de las consultas se enrutan a múltiples centros de datos en el público cloud , una nube privada o una nube operada por un socio y, finalmente, ensamblar estos componentes en los resultados de la consulta mientras se registra un seguimiento que abarca toda la operación.
En algunos casos, esta capa de datos se comunicará con los servicios de back-end mediante GraphQL. Sin embargo, lo más común es que los servicios de back-end sigan siendo los mismos y se siga accediendo a través de las API existentes, como REST, SOAP, gRPC, Thrift o incluso SQL, que luego el servidor de la capa de datos asigna a la capa de datos.