Hello! I don’t know if this is the right forum. But lets try.
My idea is to create a microservice approach with graphql and serverless framework.
I’am thinking about creating a service for every table in the dynamodb and then create a apigateway service, and in the apigateway service use graphql-tool to stitch the schemas together.
This work pretty good and I’am satisfied.
But now I want to add authorization to my graphql queries and mutations.
I have added a custom autherizer in the apigateway that resolves the JWT token from the client and sends it to the graphql context with the userId
But now I want to add authorization to my resolvers.
What is the best approach for this?
I want it to be as moduler as possible and and best (i think) is to add the authorization in the apigatway service so my other service stay clean. But I don’t know how?
If I understand you correctly then resolvers in your main GraphQL API are basically doing a fetch against the GraphQL API for each service? If the resolvers in your main GraphQL API have access to the JWT can’t they just include that in the header when performing the fetch from each service? The custom authorizer for that service can then validate the JWT again.
FWIW - I wouldn’t do it the way you’ve described. I would setup a GraphQL API as one service (probably using AppSync instead of the API Gateway). I would then make the Lambda inside the services the API to that service and have the resolver in the GraphQL API invoke them directly. This keeps the interface clean(ish) because invoking the Lambda becomes your only access to the service but it also reduces latency by removing the second API Gateway, second custom authorizer and invoking additional Lambda.
No I don’t think so. Lets try again . Every service (Table in dynamdb) have its own schema and reslovers. then in the main-api , I schema stitch the schemas and resolver from the different services and create necessary connection between the schemas, i use graphql-tool for this. (https://www.apollographql.com/docs/graphql-tools/schema-stitching.html) I don’t use remoteschemas right now, just divided the services in different folders for now.
So I think I explained wrong. The API Gateway will only have one endpoint, to my main-api.
Then the main-api stitch everything together.
The main-api will now get the user from the jwt token from the API gateway authorizer. But it is here I don’t know what to do.
I have been looking at this project https://github.com/kkemple/graphql-auth
But then I have to change in every service and put the auth where I need it. I want to keep the auth separate.
Does it make more sense? Or this is maybe a bad approach?
I can create a test project on github, if you want and have time to look at it?
I’ve always passed the user to the resolver in the context and left it up to the resolver to decide what the user has access too. Frequently this results in the user being passed into the data loader to determine record level access. It’s the only approach that allows you to control both which records and which fields the user can have access to.
. Every service (Table in dynamdb) have its own schema and reslovers. then in the main-api , I schema stitch the schemas and resolver from the different services and create necessary connection between the schemas, i use graphql-tool for this. (