The decoupling from apollo client specifically isn't covered in this ticket as it has already been mentioned in the related future work.

In general, after looking at upstream packages which provide similar functionality - the prevailing mechanism is to decouple as much as possible from the persistence layer. If we can provide a pluggable mechanism by which we can allow developers define their own cache layer and persist it however they wish then we will have a much stronger solution. This also naturally opens the door to a client which is decoupled from Apollo.

For example, if we can provide an extendable storage layer then we can provide additional methods to extend this storage and make it more useful. An example of this is wora, which extends apollo cache to provide a `hydrated()` method to be used on application restart. While this is good, it could be taken further to completely decouple from apollo cache - or to suit apollo cache to our needs. This would need to be spiked and fleshed out further.

One complication of this is optimistic responses. Its not yet clear of the best path for handling optimistic responses. On the one hand - a simplified cache and persistence layer would mean not worrying about optimistic responses and delegating this task to the developer. On the other, handling optimistic responses as part of the client introduces power and reduces the overhead on the developer. However this has the drawback of being tied to a cache layer and therefore potentially a client.

In general, the offline flow (and specifically the queue) we currently have is powerful and performs well. An improvement could be when/if we decouple from Apollo we will see performance improvements from not requiring a large set of links on the client to alter the state of the mutations. Instead this could be handled via promises manually and built in to our client.