Apollo on Angular, almost a love story
Tags: angular, apollo, graphql, hasura
Published: 2019-12-11 13:04:45

#Apollo

[Apollo](https://www.apollographql.com/) is a (if not the) graphQL client for frontend applications.

It is available for React, Angular, Vue and many more, with great docs available in order to get started easily and understand how to use its power.

##Apollo-angular

[Apollo-angular](https://www.apollographql.com/docs/angular/) is the Angular wrapper for the apollo client. It fits particularly well with Angular because all its API was designed to use Observable and reactive paradigm. If you use Angular daily you should know how much it uses Observables and how it can be annoying when an external API doesn't. Apollo-angular will help you to develop efficiently with Apollo and Angular, by providing everything you need the way you need it.

##Getting started

When getting started on apollo-angular, you can simply follow the example shown in the [docs](https://www.apollographql.com/docs/angular/basics/setup/), which will allow you to install the library, then configure its module and finally provide a factory for Apollo.

{% gist https://gist.github.com/Supamiu/1bfdd108af16168b12494cfd6c2584f7 %}

## But then, it's done?

Even if this example is perfect in order to get you started with the library, it is far from being good for production use, because of how you have to [setup authorization header](https://www.apollographql.com/docs/react/networking/authentication/#header).

The main reason being that if your application needs to change something on the client's configuration, you won't be able to create a new Apollo instance, instead you will get an error saying `apollo has been already created`. This example is only good if your token has no expiration date, or if it's shorter than your application's life (if it's not meant to be opened for this long).

 
![But why?](https://www.reactiongifs.com/r/but-why.gif)

The reason for this is that Apollo client has to be single instance, it is made to be singleton and once you created one, especially in an Angular context, where everything is a service, it's hard to delete it.


## The solution

#### Context

In my case, I'm using [Firebase](https://firebase.google.com/) for the authentication part, in order to query my graphQL API, created using [Hasura](https://hasura.io/). To secure the application, it requires a classic JWT authentication to match a role in the IAM, unauthenticated access is forbidden, in order to avoid unwanted spam of requests from people wanting to just hammer the API.


#### The problem

When the application is running, as it's a SPA, it can live longer than the JWT, meaning that I will have to refresh it, but because of that, I would have to create a new Apollo instance using the method linked above, and we know it, it's not going to work.

#### The solution

When you think about it, graphQL requests are *just* POST requests to the graphQL endoint, which means they use the http service from Angular. And this means that we can use interceptors !

{% gist https://gist.github.com/Supamiu/354030d8fc09b93437985cdefe88d345 %}

This allows the token to be reloaded anytime, without having to worry about the Apollo instance, as it can safely be kept as a singleton, with a proper authorization header that can be reloaded !


You can now enjoy your graphQL API with the same application instance during several hours ! :tada:

If you enjoyed this article do not hesitate to share it on twitter. If you have any questions or feedback please don't hesitate to tweet me [@Supamiu_](https://twitter.com/Supamiu_)