Although the title contains GraphQL, in this short second part, GraphQL won’t be mentioned a lot. The reason behind this is that I will write about a specific “issue” and it’s solution and I realised that this way of approach is independent of the back-end technology. Honestly, this post could be a standalone read but I decided to make it part of the series since I will reuse some of the things mentioned in Part 1 (like the NetworkResult sealed class and how our Repositories work).

The “Problem”

Majority of the apps have some sort of user authentication with login/registration flows. When the user authenticates we get a token (or a session id) that we use on all of the following network calls. And that token usually has an expiration time, after which we have to refresh it. That is what this post it about. We are going to look at a way to deal with token refresh. I am not saying this is the “most efficient” way, but it sure is flexible, readable and fitting a good architecture. 

Since we don’t know at what time or at which screen the token is going to expire we have to be prepared to react on it anytime. Which means the majority of our network calls (or queries/mutation in GraphQL) have to have some logic that deals with catching expired tokens and refreshing them.

Using Kotlin Delegates

Let’s assume we already have logic (preferably in some UseCase) that refreshes our token. Also let’s assume we have logic to catch an expired token (usually 401 response from back-end). So we start with having a way to just purely refresh the token and to catch the expired Exception (returning it as NetworkResult.Error in any request)

The token refresh should not be noticeable to the user, so our goal is this: If we catch ExpiredTokenException from a network request, we refresh the token, call the same request again and return that new result to the UI. 

A good place to deal with this is in our Repository layer. And instead of having access to refresh token logic in some BaseReposity we can do better. We can use Kotlin Delegates. By that I mean, we create an independent class (TokenHandler) that contains the above logic, and some interface (ITokenHandler) that exposes a function that can execute that logic on any network request. That way any Repository can have that interface but delegate the actual implementation to this TokenHandler class. By this we chose composition instead of inheritance, allowing for a cleaner and more testable code.

  

Another neat thing is using a typealias to make the code clearer. I am using it here to represent a suspending function that returns a NetworkResult (i.e the way we make a network request).

(*I am using Kotlin in this example to inject the RefreshTokenUseCase but this is achievable with any other DI framework)

Usage in a Repository

  

Using it in a Repository is really straighforward. We just wrap the calls with our exposed safeApi function that accepts a lambda. 

Final notes

I know that refreshing token or session id is a very specific case, but I also think its very widely required. There might be more sophisticated ways of dealing with this, but I’ve found this approach very easy to implement and use. It also offers flexibility in a way that you can choose to which specific request you what this logic applied to.

I hope I’ve inspired some thinking on how to use Kotlin Delegates as well, a very powerful concept to writing clean and testable code.

Stay tuned for more!