Casos de uso para múltiples endpoints personalizados
Se espera que GraphQL exponga un único endpoint para consultar los datos. Sin embargo, hay situaciones en las que tiene sentido exponer en su lugar múltiples endpoints personalizados, donde cada uno de estos endpoints presenta un esquema personalizado. Esto nos permite proporcionar un comportamiento distinto para diferentes usuarios o aplicaciones simplemente intercambiando el endpoint accedido.
Exponer múltiples endpoints en GraphQL no equivale a REST. Mientras que en REST cada endpoint proporciona acceso a un recurso predefinido o conjunto de recursos, cada uno de los múltiples endpoints GraphQL seguirá proporcionando acceso a todos los datos de su esquema, permitiendo obtener exactamente lo que necesitamos. Así que sigue siendo el comportamiento normal de GraphQL, con la adición de poder acceder a los datos desde diferentes esquemas.
Esta capacidad también es diferente a schema stitching o federation, que permiten incorporar varias fuentes de datos en un único grafo unificado. Con múltiples endpoints estamos tratando con múltiples esquemas. La intención es tratarlos por sí mismos, y no como parte de un esquema mayor.
Exponer diferentes esquemas puede proporcionar acceso a múltiples grafos independientes. El creador de GraphQL Lee Byron explica cuándo esto puede ser útil:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
Exploremos algunos casos de uso adicionales en los que exponer múltiples endpoints GraphQL tiene sentido.
Exponer los endpoints de administración y público por separado
Cuando estamos utilizando un único grafo para todos los datos de la empresa, podemos validar quién tiene acceso a los diferentes campos en nuestro esquema GraphQL configurando políticas de control de acceso. Por ejemplo, podemos configurar campos para que sean accesibles solo a usuarios autenticados o usuarios con un determinado rol.
Sin embargo, cuando hay campos que contienen información sensible o confidencial, de manera que bajo ninguna circunstancia deberían ser accesibles a actores no deseados, entonces preferiríamos no exponer estos campos en un esquema público en primer lugar, y solo en un esquema privado al que solo el equipo tiene acceso. Esta estrategia protegerá nuestros datos privados de problemas no intencionados, como errores de software y descuidos al configurar el esquema, e incluso reforzará la seguridad permitiendo solo a los visitantes de ciertas IPs acceder al endpoint privado.
Por lo tanto, podemos crear dos esquemas separados, los esquemas Admin y Public, y exponerlos bajo los endpoints /graphql/admin (y restringir el acceso a este a visitantes desde una determinada IP) y /graphql/public (accesible para todos) respectivamente.
Restringir el acceso a información privada de una forma más segura
Esta sección es una generalización de la anterior: no se trata solo de público frente a administración, sino de cualquier situación en la que un conjunto de usuarios no deba ciertamente poder acceder a información de otro conjunto de usuarios.
Por ejemplo, siempre que necesitemos crear esquemas personalizados para nuestros diferentes clientes, podemos exponer un endpoint personalizado para cada uno de ellos (/graphql/some-client, /graphql/another-client, etc), lo que puede ser más seguro que darles acceso al mismo esquema unificado y validarlos mediante control de acceso.
Proporcionar un comportamiento diferente a diferentes aplicaciones
Podemos otorgar un comportamiento diferente a las distintas aplicaciones que acceden a la misma fuente de datos.
Por ejemplo, Reddit produce una respuesta distinta si se accede desde un navegador de escritorio o desde un navegador móvil. Desde el navegador de escritorio, estemos o no autenticados, podemos visualizar directamente el contenido:
Sin embargo, accediendo desde el móvil, debemos estar autenticados para acceder al contenido, y se nos anima a usar la app en su lugar:
Este comportamiento diferente podría proporcionarse creando dos esquemas, los esquemas Desktop y Mobile, y exponerlos bajo /graphql/desktop y /graphql/mobile respectivamente.
Generar un sitio en diferentes idiomas
Si queremos generar el mismo sitio en diferentes idiomas, podemos hacer que el código del idioma ya forme parte de la estructura del endpoint personalizado, como /graphql/en para inglés y /graphql/fr para francés. Entonces, el servidor GraphQL puede recuperar esta información y traducir los datos al idioma deseado.
Finalmente, apuntamos a cada uno de estos endpoints en el generador de sitios estáticos para producir el sitio en uno u otro idioma:
Probar un esquema mejorado antes de publicarlo en producción
Si queremos actualizar nuestro esquema GraphQL, y tener un conjunto de usuarios que lo prueben por adelantado, podemos exponer este nuevo esquema mediante un endpoint /graphql/upcoming. Aún más, también podríamos exponer un endpoint /graphql/bleeding-edge, que sigue desplegando el esquema desde DEV.
Soportar el enfoque BfF
Backend-for-Frontends (BfF para abreviar) es un enfoque para producir diferentes APIs para diferentes clientes, haciendo que cada cliente "posea" su API, permitiéndole producir la versión más óptima en función de sus propios requisitos.
En este modelo, un BfF personalizado es el intermediario entre los servicios back-end y su cliente:
Este modelo puede satisfacerse en GraphQL haciendo que todos los BfFs se implementen en un único servidor GraphQL con múltiples endpoints, abordando cada endpoint un BfF/cliente específico (como /graphql/mobile y /graphql/web):
