CODEWITHSUNDEEP
expressgraphqlkeycloakapolloapollo-server
Quan Nguyen
Quan Nguyen

Reputation: 3

How to share and modify variables between Express and the GraphQL/Apollo server?

Background on my application

I have an Express application with the apollo-server-express package installed, which allows me to attach a GraphQL server to the running Express server.

The Express server is used for authentication/authorization (with Keycloak and Passport), and the GraphQL server serves as the API layer for querying data.

What I'd like to accomplish

Implement a way to auto logout users when they have been inactive for 10 minutes. "Inactive" is defined as users from making a query to the GraphQL server.

My current strategy

Create a global variable when initializing the Express application that tracks each logged-in user and the last time that they made a request. Example:

const userSessionTracker = {
    userId1: 300000, // a user's timer: last time they logged in/made a request (in ms)
    userId2: 5000,
    ...
}

Every time a user logs in/makes a request, the application will reset their timer back to 0. Next time they make a request, if the timer is above 10 minutes, the application will log the user out.

Problem

When the users call a GraphQL query, I'd like to check/reset their timer inside the GraphQL query resolver. How can I do so?

What I've tried

In summary, I can access the userSessionTracker variable from inside a GraphQL resolver, but I can't edit it and have the edited version be accessible from the Express application.

This seems to be by design, as the Apollo docs stated that "Resolvers should never destructively modify the contextValue argument". How can I get around this limitation?

Upvotes: 0

Views: 111

Answers (1)

Michel Floyd
Michel Floyd

Reputation: 20226

Resolvers are the wrong place to implement this logic - you need to do it all in the context function. Every GraphQL request from a user has to go through the context function first before any queries and resolvers fire so it's the central place to put authentication and timeout logic. Resolvers can only read the context, not change it.

You shouldn't even need to look at the userSessionTracker inside your resolvers, you should only need to know if there's an authenticated user behind the request.

If you use JWTs then you can simply have the JWT expire after 10 minutes but refresh it anytime a request comes in before it expires - that way every authenticated query restarts the clock.

Storing session expiry server side implies a database or shared cache where you manage expiry times if you ever want to scale to more than one server.

Upvotes: 0

Related Questions