Patrones de Autorización en GraphQL

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Tal como dice la documentación de GraphQL: "Delega la lógica de autorización a la capa de lógica empresarial". ¿Es eso realmente todo lo que necesitas saber? Este consejo proviene de un buen lugar, pero depende de que sepas cómo abordar la autorización en primer lugar, ¡y este no es un problema ampliamente resuelto! Además, muchos de los enfoques utilizados en aplicaciones tradicionales no se aplican completamente. En esta charla, obtendrás un curso intensivo sobre autorización y cómo implementarla para las APIs de GraphQL."

This talk has been presented at GraphQL Galaxy 2022, check out the latest edition of this Tech Conference.

FAQ

La autorización se refiere a determinar qué acciones puede realizar un usuario conocido dentro de una aplicación, mientras que la autenticación se centra en verificar la identidad del usuario, como identificarlos a través de un nombre de usuario y contraseña.

GitHub es un ejemplo de un sistema de autorización robusto, que permite asignar roles a nivel organizacional, como propietario y miembro, y controlar acciones como la creación de repositorios. También permite roles más granulares, como otorgar diferentes niveles de acceso a los colaboradores de un repositorio.

La autorización es crucial porque sin ella, una aplicación puede enfrentarse a una anarquía operativa donde cualquiera podría realizar cualquier acción, como eliminar usuarios o datos. Una autorización adecuada asegura que los usuarios solo tengan acceso a las funciones que les están permitidas.

Delegar la autorización a la capa de lógica de negocios significa manejar las decisiones de autorización en un nivel centralizado de la aplicación, lo que ayuda a mantener la sincronización y consistencia de las políticas de autorización a través de diferentes tipos de interfaces como REST y GraphQL.

En GraphQL, la autorización puede ser manejada a nivel de resolutor, donde se implementan controles de acceso dentro de las funciones que resuelven las consultas. Esto puede incluir, por ejemplo, verificar si un usuario tiene el permiso necesario para ejecutar una mutación específica.

Implementar la autorización en la capa de GraphQL puede simplificar la gestión de permisos en aplicaciones que utilizan exclusivamente GraphQL, permitiendo una integración más limpia y directa de las políticas de autorización sin la necesidad de duplicar la lógica entre diferentes tipos de API.

Una técnica es extender los tipos de GraphQL con un campo de permisos que indique los permisos del usuario actual sobre un recurso. Esto permite que las interfaces de usuario utilicen estos datos para mostrar o ocultar elementos de la UI según los permisos del usuario, mejorando la experiencia al estar alineada con sus capacidades autorizadas.

Sam Scott
Sam Scott
20 min
08 Dec, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla presenta la teoría y la práctica de la autorización en GraphQL, resaltando la importancia de una autorización adecuada para garantizar la funcionalidad y seguridad de la aplicación. Delegar la autorización a la capa de lógica empresarial es una regla de oro en GraphQL, asegurando consistencia y evitando la duplicación de lógica. La autorización se puede realizar en la capa de resolvers, pero se recomienda combinarla con filtrado a nivel de base de datos. Abstraer la autorización detrás de una API centraliza la lógica y facilita su gestión. Las directivas personalizadas y los campos de permisos pueden reducir la tediosidad de garantizar la autorización correcta en cada resolver.
Available in English: Authorization Patterns in GraphQL

1. Introducción a la Autorización en GraphQL

Short description:

Esta charla introduce la teoría y práctica de la autorización en GraphQL. El orador proporciona definiciones de autenticación y autorización, enfatizando la importancia de la autorización de la aplicación. Se dan ejemplos de sistemas de autorización robustos en GitHub y AWS IAM, así como ejemplos menos obvios como Google Docs y Notion. La charla destaca la importancia de una autorización adecuada para garantizar la funcionalidad y seguridad de una aplicación.

Todas las buenas charlas deben comenzar con una cita, ¿verdad? Entonces, ¿sabes cómo dicen que, en teoría, no hay diferencia entre la teoría y la práctica, pero en la práctica sí la hay? Bueno, de eso trata esta charla. Voy a hablarles sobre la teoría de la autorización en GraphQL, y luego si y cómo esto se corresponde con la práctica. Así que, soy Sam, soy cofundador y CTO de Oso, y construimos autorización para desarrolladores. Y como alguien que hizo un doctorado en criptografía y gradualmente se deslizó más y más hacia el mundo práctico, estoy bastante familiarizado con la distinción entre la teoría y la práctica.

Así que prepárense y aprendan un poco sobre patrones en GraphQL, tanto teóricos como prácticos. Sé que hay mucha confusión sobre la diferencia entre autenticación y autorización, así que comenzaré con algunas definiciones. Autenticación se trata de la identidad, ¿sabes, quién es el usuario? Puede ser que los identifiques a través de un nombre de usuario y contraseña, puedes hacer inicio de sesión único, puedes tener autenticación de dos factores, eso es todo autenticación. La autorización es la pieza que viene después. Ahora que sabes quién es el usuario, ¿qué pueden hacer? Y voy a hablar sobre la autorización de la aplicación. Entonces, específicamente, ¿qué pueden hacer dentro de tu aplicación?

Para darte algunos ejemplos, GitHub, este es un gran ejemplo. Tiene un sistema de autorización bastante robusto. Te permite hacer roles a nivel organizacional, como propietario y miembro, y cuáles de esos pueden crear repositorios. También puedes tener roles a un nivel más granular. Puedo invitarte como colaborador a mi repositorio y darte un rol que te otorgue diferentes accesos. Ahora, me gusta mucho GitHub como ejemplo, porque también tienen una API de GraphQL, por lo que podremos ver no solo la autorización genéricamente, sino también en el contexto de GraphQL. Para un ejemplo de autorización más complejo, toma AWS IAM. Y con AWS IAM, puedes escribir tu propia lógica y políticas de autorización para determinar quién tiene permitido hacer qué dentro de esta plataforma gigantesca. Es bastante complejo. Pero hay algunas autorizaciones de aplicaciones en las que quizás no pienses tanto. Toma algo como Google Docs o Notion, donde parte del flujo de trabajo principal es invitar a personas a colaborar en documentos, o tal vez invitarlos a una carpeta completa y decir dónde pueden ver, editar o comentar esos documentos. Eso es toda autorización. GitHub, AWS, Google Docs, Notion, todos estos son ejemplos fantásticos de autorización de aplicaciones.

Antes de comenzar a entrar en los detalles técnicos, ¿por qué es este un tema importante para hablar? Bueno, en primer lugar, si no tienes autorización en una aplicación, tu producto está completamente roto. Tienes una especie de anarquía. Cualquiera puede entrar y hacer cualquier cosa. Pueden eliminar a otros usuarios, pueden eliminar los datos de otras personas, pueden hacer cualquier cosa. Pero por otro lado, si tu autorización está rota, las personas no pueden acceder a nada. Tu aplicación no funciona. Si tu autorización tiene errores, los usuarios comienzan a frustrarse. Todos hemos estado en esa situación en la que la lógica de autorización en una aplicación está tan rota y frustrante que simplemente dices, sabes qué, voy a hacer que todos sean administradores.

2. Patrones de Autorización en la Capa de Lógica de Negocios

Short description:

El primer patrón discutido es la autorización en la capa de lógica de negocios. Delegar la autorización a la capa de lógica de negocios es una regla de oro en GraphQL. La capa de lógica de negocios maneja la asignación de las solicitudes del cliente a los procesos internos de la aplicación. Recopila datos relevantes, calcula campos y realiza transformaciones. Por otro lado, la capa de persistencia se encarga de leer y escribir datos en la base de datos.

No quiero lidiar con este sistema de permisos. Por lo tanto, eso puede ser lo que implican hacer mal la autorización o incluso hacerla de manera deficiente.

Bien, vamos a hablar de los patrones de autorización. El primer patrón del que quiero hablar es la autorización en la capa de lógica de negocios. Ahora, si eres como yo y estás abordando un nuevo tema, probablemente lo primero que hagas es buscarlo en Google. Ahora escribes 'autorización GraphQL' y el primer resultado que aparece es GraphQL.org. Tiene una hermosa descripción conceptual sobre la autorización en GraphQL. Y comienza con una especie de regla de oro que dice: delega la autorización a la capa de lógica de negocios. Ahora, hay potencialmente dos conceptos nuevos en esto que quizás no hayas pensado antes. Uno, ¿qué significa delegar la autorización? Y dos, ¿qué es esta capa de lógica de negocios? El término capa de lógica de negocios también proviene de otra página de GraphQL.org. Esta página trata sobre cómo pensar en gráficos y presenta un diagrama arquitectónico de capas que muestra cómo se integra GraphQL en tu aplicación. Tengo mi propia versión de este diagrama para poder garabatear y dibujar cosas. Y, bueno, cuando hablo de las capas de tu aplicación, me refiero a una aplicación backend, ¿verdad? Entonces, poniendo esta imagen en contexto, tal vez se vea más o menos así. En primer lugar, a la izquierda, tal vez tengas tu cliente. Esto podría ser un navegador web o una aplicación móvil. Y todas esas cosas estarán haciendo diversas solicitudes a tu backend, a tus APIs de backend. Esas solicitudes podrían ser solicitudes REST o consultas GraphQL. La capa de lógica de negocios se encarga de manejar eso, mapeando esas solicitudes a las cosas reales que ocurren dentro de tu aplicación. Por ejemplo, si quieres obtener una organización específica, la lógica de negocios se encargaría de recopilar todos los datos relevantes para devolverlos, calcular campos, realizar transformaciones, cosas así.

En la parte inferior, la capa de persistencia es la encargada de leer y escribir datos en la base de datos. Por ejemplo, volviendo a eso, si un usuario quiere revisar una organización específica, tal vez lo haga a través de una solicitud REST, y en el backend tal vez tengamos alguna lógica de aplicación que hayamos escrito para manejar eso, que busca la organización por ese ID en la base de datos. Autoriza, ¿tiene el usuario permiso para leer esa organización? Y si no, devuelve nulo. Eso podría ser nuestro punto final REST. De manera similar, en el lado de GraphQL, ahora tenemos una consulta para una organización por un ID específico. Pero nuevamente, escribimos nuestra lógica de resolución para buscar esa organización por ese ID en particular, autorizar, ¿tiene el usuario permiso para leer esa organización? y de manera similar devolver nulo. Hasta ahora, todo bien.

3. Autorización en GraphQL: Mejores Prácticas

Short description:

Tenemos nuestra API REST, nuestra API GraphQL y autorización. Duplicar la lógica de autorización en varios lugares puede llevar a inconsistencias y una mala experiencia de usuario. La solución es delegar la autorización a la capa de lógica de negocios y manejarla allí. Esto garantiza consistencia y evita duplicar la lógica. Además, al obtener múltiples organizaciones, es mejor aplicar la lógica de autorización como un filtro a nivel de consulta para evitar problemas de rendimiento y manejar el acceso no autorizado.

Tenemos nuestra API REST, tenemos nuestra API GraphQL, tenemos autorización. No parece tan malo. Volviendo a esa página original de documentación de GraphQL.org, lo que está diciendo es que el problema aquí es que has duplicado esta lógica de autorización en varios lugares. Y destacaron esto como algo malo porque, bueno, en este caso tenemos dos lecturas, dos métodos y no puedes actualizarlos demasiado mal. Pero a medida que creces, creces tus diferentes API y puntos finales, ahora necesitas mantener todas estas diferentes declaraciones de autorización sincronizadas entre estas dos API, la REST y GraphQL.

Ahora, por qué eso es problemático es si estas cosas se desincronizan, tal vez verifiques un permiso en un lugar, verifiques un permiso diferente en otro lugar, entonces tu aplicación comienza a comportarse de manera diferente según qué API esté utilizando alguien y eso puede crear una experiencia de usuario realmente pobre. Volviendo a ese diagrama, cuando esa Regla de Oro dice delegar la autorización a la capa de lógica de negocios, lo que está hablando es empujar esa autorización hacia abajo. No manejarlo en esos controladores de API, sino empujarlo hacia abajo, manejarlo dentro de la capa de lógica de negocios. Entonces, en mi ejemplo anterior, lo que eso podría significar es que en tu método para buscar la organización por ID, tal vez ahí es donde colocas esa lógica de autorización. Entonces, cuando vayas a buscar esa organización, luego verificas si el usuario puede leerla o no. Debido a que tanto la API REST como GraphQL están llamando al mismo método, tenemos una garantía de que estarán sincronizados. Bien. Ahí lo tienes. Esa es la teoría conceptual de la autorización en GraphQL. De hecho, no lo haces realmente en GraphQL. Lo empujas hacia abajo a la capa de lógica de negocios y lo manejas allí. Entonces no tienes que repetir esa lógica varias veces. En realidad, no es solo una teoría. Creo que en la práctica, este también es un consejo fantástico. Creo que para muchas personas, esta debería ser la opción predeterminada correcta, especialmente si tienes una aplicación en la que ya tienes autorización en muchos lugares. A medida que agregas esos puntos finales de GraphQL, no quieres copiar y pegar esa lógica de autorización. Es mejor que puedas tenerla definida en un solo lugar.

Quiero ampliar brevemente este tema con algo más que creo que puede ser muy útil hacer. Antes, estábamos obteniendo una organización específica, pero ¿qué pasa si en su lugar estamos obteniendo múltiples organizaciones? Supongamos que queremos obtener las primeras 10 organizaciones, ¿verdad? Lo ingenuo sería obtener esas organizaciones y luego autorizar cada una una por una. El problema de eso es, uno, puede ser un poco lento hacer esa autorización repetidamente. Pero dos, si una de ellas no está permitida, ¿qué haces? ¿Solo devuelves nueve organizaciones en lugar de 10? ¿Devuelves un nulo? ¿Requieres que el usuario vuelva y obtenga más y así sucesivamente? Esto puede ser realmente complicado de hacer correctamente. Pero nuevamente, esa teoría anterior se aplica muy bien. Debes hacer esta autorización en esa capa de lógica de negocios. Pero en la práctica, cómo lo logras es aplicando tu lógica de autorización como un filtro a nivel de consulta. Entonces, tal vez lo que necesitas hacer es filtrar esas organizaciones por todas las organizaciones a las que pertenece el usuario. Quiero decir, tal vez tengamos, como una lista de organizaciones en el usuario.

4. Lógica de Autorización y Resolutores de Consultas

Short description:

Cuando se trata de resolutores de consultas, un gran patrón es realizar la autorización como parte de la obtención de datos de la base de datos. Esto se puede lograr separando la lógica de autorización detrás de una única interfaz, como OSO. La versión alternativa del diagrama podría tener la autorización antes de la capa de persistencia, todo dentro de la capa de lógica de negocios.

Ahora, a medida que esa lógica de autorización se vuelve más compleja, probablemente quieras separar esa lógica también detrás de una única interfaz. Digamos, algo que pueda listar todos los IDs de organizaciones autorizadas para ti, y luego puedes filtrar la base de datos. Ese es el tipo de cosa que realmente puedes obtener de soluciones de autorización modernas como OSO. Y por lo tanto, el patrón que quiero que entiendas aquí es que cuando estés haciendo tus resolutores de consultas, un gran patrón a seguir es realizar esa autorización como parte de, digamos, obtener los datos de la base de datos. No solo para una cosa, sino también para varias cosas. Y tal vez una versión alternativa del diagrama podría tener esa autorización antes de la capa de persistencia. No lo sé. Todo como parte de esa capa de lógica de negocios.

5. Razones para la Autorización en GraphQL

Short description:

El orador analiza las razones por las cuales algunas personas eligen colocar la lógica de autorización en la capa de resolutores en GraphQL. Mencionan que puede ser más fácil y rápido hacerlo de esta manera, especialmente para aquellos que están adoptando GraphQL y ya tienen experiencia en colocar la autorización en la lógica de manejo de rutas para puntos finales REST. Otra razón es para las empresas que están totalmente comprometidas con GraphQL, ya que brinda la oportunidad de realizar la autorización de manera limpia y aprovechar los beneficios que ofrece. Por último, se destaca la defensa en profundidad como una sólida razón para realizar la autorización en la capa de GraphQL, asegurando que la autorización se implemente correctamente en todo el backend.

OK. Parece que hemos cubierto todo. Como hemos hecho, devuelvan su tiempo. Pueden, ya saben, dar un paseo o algo antes de la próxima charla. No del todo. No del todo. Entonces, lo anterior, ¿verdad? Es genial en teoría y en realidad, también. Cuando comenzamos a analizar la autorización en GraphQL hace unos años, esto simplemente tenía mucho sentido para mí. Esto es genial. Resolveremos la autorización para las personas con GraphQL y no tenemos nada más que hacer. En realidad, fue mi cofundador quien me preguntó repetidamente si podríamos hacer más por la autorización en GraphQL. Cada vez que pensábamos en ello, la lógica decía que debemos hacerlo en la capa de lógica de negocios y ahí es donde encajamos de todos modos. Y sin embargo, cada vez veíamos a personas que estaban haciendo cosas personalizadas de autorización con GraphQL, nos preguntaban sobre integraciones y queríamos saber qué estaba pasando allí. ¿Por qué era esto? Y había tres razones diferentes que vimos. Así que en primer lugar, honestamente, es más fácil. En realidad, es mucho más fácil no tener esa disciplina rigurosa donde tienes perfectamente separada y desacoplada tu autorización de la lógica de manejo de resolutores y tu capa de persistencia, y una tercera. Para muchas personas, simplemente están tratando de avanzar rápido, están adoptando GraphQL y colocan su autorización en el resolutor porque es la forma más fácil de hacerlo. Y no hay ningún juicio en eso, por cierto, porque durante años, las personas han estado haciendo esto para la autorización con puntos finales REST, ¿verdad? Simplemente lo colocan en su lógica de manejo de rutas. Pueden crear middleware, hay muchas cosas diferentes que la gente hace. Y a menudo, esa puede ser la razón. La segunda que vi es tal vez un poco más fundamentada que eso, que es para las personas que adoptan GraphQL primero como empresa. Están completamente comprometidos con GraphQL, por lo que esa idea de duplicarlo entre GraphQL y REST no tiene mucho sentido para ellos porque solo están usando GraphQL de todos modos. Y eso no tiene sentido. Y veremos en un segundo por qué puede ser muy poderoso hacer la autorización en la capa de GraphQL. Creo que simplemente desde ese punto de vista, para muchas personas, lo ven como una oportunidad para hacer la autorización de manera muy limpia. Y veremos que hay algunos beneficios realmente geniales al hacer la autorización en la capa de GraphQL. Y creo que las personas están aprovechando esa oportunidad. Pienso en eso como el enfoque de GraphQL primero, donde estás diciendo que quieres hacer la autorización en GraphQL intencionalmente. Creo que, finalmente, y esta siempre es una razón fantástica en la autorización, es la defensa en profundidad. ¿Verdad? Puede ser difícil saber si has realizado la autorización correctamente en todos los lugares correctos de todo el backend, todas las diferentes rutas que necesitas manejar.

6. Autorización en la Capa de GraphQL

Short description:

Tener un único lugar para la autorización en la API REST o la API GraphQL brinda comodidad y garantiza cierto nivel de autorización. El orador analiza la realización de la autorización directamente en la capa de GraphQL, específicamente en el lado del resolutor. Se da un ejemplo de mutaciones y cómo se puede implementar la autorización en la capa de resolutores.

Y tener un único lugar para colocarlo, ya sea en la API REST, la API GraphQL, puede brindarte esa comodidad de saber que al menos se ha realizado cierta cantidad de autorización en un solo lugar. Entonces, el próximo patrón del que quiero hablar es cómo se ve realizar la autorización directamente en la capa de GraphQL. Y eso significa que hay un par de formas diferentes en las que podríamos hacer esto. Voy a hablar sobre el lado del resolutor. Supongamos que tenemos algunas mutaciones. Tal vez se haya creado un repositorio, se haya abierto un problema, y así sucesivamente. Y hemos implementado resolutores para cada una de esas mutaciones, ¿verdad? Eso mira los datos. Y por una de esas razones que mencioné antes, hemos realizado la autorización aquí en la capa de resolutores.

7. Abstracción de la Lógica de Autorización

Short description:

Es crucial abstraer la autorización detrás de una API. Esto centraliza la lógica, facilitando su gestión y depuración. La capa de integración se encarga de la autorización, eliminando la necesidad de preocuparse por ella en otros lugares.

OK, hay un par de cosas que quiero señalar sobre lo que tengo aquí. En primer lugar, creo que es absolutamente crucial que, si vas a realizar la autorización en algún lugar, la abstraigas detrás de una API como esta. Realmente no puedo recomendarlo lo suficiente. Te permite mantener toda tu lógica de autorización en un solo lugar, un lugar para realizar cambios, un lugar para debug, hacer registros, y así sucesivamente. A lo largo de esta charla, ni siquiera te mostraré ninguna lógica de autorización en sí misma. Como, ya sabes, puedes hacer esto porque tienes un rol, porque aquí en la capa de integración no necesitamos preocuparnos por eso.

8. Directivas Personalizadas y Campo de Permisos

Short description:

Incluso con una llamada autorizada limpia, puede ser tedioso asegurar la autorización correcta en cada resolutor. Un patrón para reducir esta tediosidad es utilizar una directiva personalizada para anotar las mutaciones con los permisos requeridos. La autorización a nivel de resolutor puede funcionar bien, pero debe combinarse con el filtrado en la base de datos. Otro patrón es extender los tipos de GraphQL con un campo de permisos, permitiendo que las interfaces de usuario sean conscientes de los permisos sin duplicar la lógica de autorización.

OK, entonces número dos, incluso con esa API en su lugar, incluso con esta llamada autorizada de una sola línea, todavía puede ser realmente tedioso revisar cada resolutor y asegurarse de haber realizado la autorización correctamente. Probablemente copiarás y pegarás, y es posible que termines cometiendo un error.

Y así, un patrón que he visto surgir para reducir esa tediosidad, para hacer esto un poco más fácil y repetible, es utilizar una directiva personalizada. No voy a profundizar en la definición de las directivas y cómo funcionan, pero supongamos que tenemos esta directiva de verificación personalizada, y lo que te permite hacer es anotar tus mutaciones con los permisos que debes verificar. Entonces, nuevamente, cuando creas un repositorio, debes verificar que el usuario tenga el permiso de crear repositorio en la organización.

Lo realmente bueno de este enfoque, si sigues este camino, es que tu esquema de GraphQL se convierte en un lugar declarativo único para asignar tus APIs de GraphQL a los permisos que necesitas para acceder a ellas. Y así, la conclusión es que la autorización a nivel de resolutor puede funcionar bastante bien. Sin embargo, recuerda que cuando teníamos la capa de lógica de negocios, teníamos dos patrones, uno era la autorización única, eso era como el filtrado de consultas. Nunca te librarás completamente de esa pieza de filtrado de datos. Puedes hacerlo de otras formas, pero nunca te librarás completamente de ello. Y por lo tanto, este patrón de autorización a nivel de resolutor solo debe usarse realmente en combinación con, por ejemplo, el filtrado en la base de datos. Y en particular, veo que esta autorización a nivel de resolutor es realmente excelente para las mutaciones. Porque a menudo son formas de tener una amplia gama de cosas diferentes que puedes hacer y diferentes verificaciones de permisos.

De acuerdo. Tengo un último patrón adicional que quiero compartir contigo. Y se trata de cómo puedes construir interfaces de usuario que sean conscientes de los permisos sin necesidad de duplicar toda tu lógica de autorización entre tu backend y frontend. La idea principal es que puedes extender tus tipos de GraphQL con un campo de permisos. Y ese campo de permisos contendrá todos los permisos que el usuario actual tiene en ese recurso en particular. Puedes ver un ejemplo de esto en la práctica. Por ejemplo, si miras la API de GraphQL de GitHub, al crear un repositorio, puedes solicitar los permisos del espectador. Y lo que obtendrás es una cadena que representa el nivel de permiso que tiene el usuario. Y ahora la idea general es que lo que una interfaz de usuario puede hacer es tomar esa información, una expresión condicional simple para decidir si tal vez debes desactivar un botón, ocultar una opción de configuración, ocultar una pestaña, cosas así.

Encuentro que este es un patrón realmente... Siento que este es un patrón muy elegante. Y en particular, es muy, muy agradable y fácil de expresar esto para GraphQL. Porque para implementar esto, todo lo que estás haciendo es tal vez extender tu resolutor con un nuevo campo de permisos. Que vas a calcular de una manera completamente diferente. Debido a que GraphQL te permite extender tus tipos con otros tipos de datos de esta manera fácilmente, puede ser muy natural simplemente inyectar este campo adicional en tus tipos. Entonces, la forma en que podrías implementar esto, nuevamente, probablemente quieras esa interfaz abstracta. Entonces, algo como acciones de lista que pueden devolver todos los permisos que el usuario tiene en un recurso en particular.

9. Patrones de Autorización y Exposición de Permisos

Short description:

Para un modelo de autorización simple, puedes verificar el rol del usuario y devolver los permisos correspondientes. A medida que la lógica de autorización se vuelve más compleja, las soluciones existentes como OSO pueden ser de gran ayuda. Exponer los permisos en el backend ayuda a construir interfaces de usuario que utilizan datos de permisos y extienden el esquema. Se discuten tres patrones: filtrado de datos para permisos de nivel de lectura, uso de directivas personalizadas para permisos de mutación y exposición de permisos en el esquema de GraphQL. Si deseas obtener más información, hay publicaciones de blog y guías técnicas disponibles, y también puedes explorar el producto Oso Cloud para una solución lista para usar.

Para tal vez un modelo de autorización simple, la forma en que podrías implementarlo es verificar qué rol tiene el usuario y luego devolver los permisos que tiene ese rol. A medida que la lógica de autorización se vuelve más compleja, esto puede volverse un poco más complicado, es donde las soluciones de autorización existentes como OSO pueden ser realmente, realmente útiles.

Entonces, lo que realmente me gustaría, me encantaría que todos adopten este patrón, porque creo que es uno increíblemente poderoso. Quieres que tu backend sea la fuente de verdad para la lógica de autorización y al exponer los permisos de esta manera, te ayuda a construir interfaces de usuario realmente, realmente geniales que utilizan esos datos de permisos y extienden ese esquema.

De acuerdo, en resumen, tres patrones. Uno, realizar un filtrado de datos para permisos de nivel de lectura en la capa de lógica de negocios es una excelente manera de centralizar esa lógica en un solo lugar. Pero cuando estás pensando en realizar muchas mutaciones y tratar de determinar qué permisos debe verificar una mutación, utilizar una directiva personalizada puede ser una forma realmente agradable de gestionar eso de manera declarativa en tu esquema de GraphQL. Y finalmente, el patrón que mencioné sobre, ya sabes, exponer los permisos como parte de tu esquema de GraphQL para que las interfaces de usuario puedan construir sobre eso, creo que puede ser realmente genial para construir aplicaciones que sean muy conscientes de la autorización.

Eso es todo de lo que quiero hablar. Gracias por escuchar. Si deseas obtener más información sobre alguno de estos temas, sabes, gran parte de este contenido se basó en una publicación de blog escrita por un colega mío, Patrick, y habla sobre estos diferentes patrones de autorización en GraphQL. Si solo estás interesado en aprender más sobre autorización, solo he tocado la superficie en diferentes tipos de autorización. También hay todo lo relacionado con cómo hacer cosas como, ya sabes, roles, relaciones, atributos en la modelización lógica, cómo estructurar esto en microservicios, cosas así. Básicamente, tomamos mucho del pensamiento que hemos hecho sobre autorización y los pusimos en este conjunto de guías técnicas independientes del proveedor sobre cómo construir autorización para tu aplicación. Y finalmente, si estás buscando una forma de que otra persona resuelva esto, ya sabes, si estás escuchando esta charla y piensas, oh, Sam, solo haz que este problema desaparezca para mí, bueno, tenemos un producto llamado Oso Cloud que te ayudará con eso. Así que muchas gracias por escuchar mi charla y estaré encantado de responder cualquier pregunta en la sesión de preguntas y respuestas.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Vue.js London Live 2021Vue.js London Live 2021
24 min
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Baterías Incluidas Reimaginadas - El Resurgimiento de GraphQL Yoga
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
Aplicaciones sólidas de React y GraphQL para personas con prisa
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Aplicaciones sólidas de React y GraphQL para personas con prisa
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.
Adoptando GraphQL en una Empresa
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
Adoptando GraphQL en una Empresa
Today's Talk is about adopting GraphQL in an enterprise. It discusses the challenges of using REST APIs and the benefits of GraphQL. The Talk explores different approaches to adopting GraphQL, including coexistence with REST APIs. It emphasizes the power of GraphQL and provides tips for successful adoption. Overall, the Talk highlights the advantages of GraphQL in terms of efficiency, collaboration, and control over APIs.

Workshops on related topic

Domina los Patrones de JavaScript
JSNation 2024JSNation 2024
145 min
Domina los Patrones de JavaScript
Top Content
Featured Workshop
Adrian Hajdin
Adrian Hajdin
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo.
Puntos Cubiertos:
1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso
Cómo Ayudará a los Desarrolladores:
- Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
React Patterns Made Simple
React Day Berlin 2024React Day Berlin 2024
62 min
React Patterns Made Simple
Top Content
Featured Workshop
Adrian Hajdin
Adrian Hajdin
Aprende patrones de React ampliamente utilizados, incluyendo HOCs, Compound Components, Provider Patterns, Functions as Child, y Portals, para escribir código más limpio y eficiente y crear aplicaciones escalables y mantenibles.Visión general En esta masterclass, los espectadores aprenderán sobre patrones clave de React que pueden hacer su código más eficiente, legible y mantenible. Presentaremos cada patrón, explicaremos cómo funciona y demostraremos ejemplos prácticos. Al final de la sesión, los participantes tendrán una comprensión sólida de cómo usar estos patrones en sus proyectos.Objetivos de aprendizajeHOCs Compound Components Provider Patterns Functions as Child Portals Modularidad Mantenibilidad Aplicación en el mundo real.
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
React Summit 2022React Summit 2022
173 min
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
En esta masterclass, aprenderás cómo construir una aplicación Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas usando el IDE GraphiQL, cómo colocar fragmentos GraphQL con tus componentes, y más.
Construir con SvelteKit y GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Construir con SvelteKit y GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
¿Alguna vez has pensado en construir algo que no requiera mucho código de plantilla con un tamaño de paquete pequeño? En esta masterclass, Scott Spence irá desde el hola mundo hasta cubrir el enrutamiento y el uso de endpoints en SvelteKit. Configurarás una API de GraphQL en el backend y luego usarás consultas de GraphQL con SvelteKit para mostrar los datos de la API de GraphQL. Construirás un proyecto rápido y seguro que utiliza las características de SvelteKit, y luego lo desplegarás como un sitio completamente estático. Este curso es para los curiosos de Svelte que no han tenido una experiencia extensa con SvelteKit y quieren una comprensión más profunda de cómo usarlo en aplicaciones prácticas.

Tabla de contenidos:
- Inicio e introducción a Svelte
- Inicializar el proyecto frontend
- Recorrido por el proyecto esqueleto de SvelteKit
- Configurar el proyecto backend
- Consultar datos con GraphQL
- Recuperación de datos en el frontend con GraphQL
- Estilización
- Directivas de Svelte
- Enrutamiento en SvelteKit
- Endpoints en SvelteKit
- Despliegue en Netlify
- Navegación
- Mutaciones en GraphCMS
- Envío de mutaciones GraphQL a través de SvelteKit
- Preguntas y respuestas
Modelado de Bases de Datos Relacionales para GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Modelado de Bases de Datos Relacionales para GraphQL
Top Content
Workshop
Adron Hall
Adron Hall
En esta masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se mapean a GraphQL. Una vez que se haya establecido esa base, el enfoque se desplazará a tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en varios escenarios.
Índice de contenidosParte 1 - Hora 1      a. Modelado de Datos de Bases de Datos Relacionales      b. Comparando Bases de Datos Relacionales y NoSQL      c. GraphQL con la Base de Datos en menteParte 2 - Hora 2      a. Diseño de Modelos de Datos Relacionales      b. Relación, Construcción de Tablas Multijoin      c. Complejidades de Consulta de Modelado de Datos Relacionales y GraphQL
Prerrequisitos      a. Herramienta de modelado de datos. El formador utilizará dbdiagram      b. Postgres, aunque no es necesario instalar esto localmente, ya que estaré utilizando una imagen de Dicker de Postgres, de Docker Hub para todos los ejemplos      c. Hasura
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.