Implement Standalone Offline Client

[smkhalsa]

@akinsho Per my comment, I've created a new package for a standalone offline client. Please add your fixes / improvements to this PR.

• [x] create seperate ferry_offline_client package
• [x] move OfflineMutationTypedLink from ferry package (and remove ferry dependency on hive)
• [ ] implement sequential ordering
• [ ] ensure mutations always get executed when coming back online (even if there aren't any listeners)
• [ ] add tests
• [ ] add example

I've created an OfflineConfig class to which we can add configurations for sequential ordering and retry.

Let me know if you have any thoughts or questions.

[akinsho]

@smkhalsa thanks for getting this started I'll add what I've got to this PR and iterate on it 👍🏿 .

[smkhalsa]

@akinsho any progress on this?

[akinsho]

Sorry @smkhalsa been quite busy the last week with some work deadlines, so haven't had a chance to do this yet. I'll at least move my work into this branch so it's visible and take it from there, hopefully things will start to quieten down on my end

[akinsho]

~Actually @smkhalsa I don't have permission to push to this branch actually, but I've pushed some of my changes to my fork of the project. I can open another PR based off of this? or is there some way to give me permission to push to this branch?~

EDIT: sorry forgot I could just PR into this branch, PR #147

[dopecoder]

Hi @smkhalsa, Any updates on this?

[smkhalsa]

@akinsho was working on this in PR #147, so I'll let him respond.

[akinsho]

I haven't really had a look at this in a while. I've been using the logic in #147 for our production app for a few months now without issue so I think it's solid. I just got blocked on testing some of the logic though and an outstanding example. There's a todo list on that PR you can track @dopecoder but I maintain and collaborate on a few things in my free time so will only be when I can.

@smkhalsa there is one implementation question I tagged you in that I need some advice as to how to tackle. The way it is now is how I use it in my project but I'm not sure it is a good general solution: https://github.com/gql-dart/ferry/pull/147#discussion_r571159311

[HosseinYousefi]

@smkhalsa @akinsho Hey guys, we have decided to use ferry in production and the next step is to create an offline first experience which requires offline mutations. Is the checklist here updated? How can we start contributing?

At first we wanted to create a offline-client ourselves but since you guys are also working on it, let's join forces.

Cheers!

[akinsho]

@HosseinYousefi that sounds great 👍🏾 the check list isn't really up to date since I'm making a separate PR into this one that ticks a lot of those boxes already. The main thing outstanding with that PR is in the description but it's boils down to

1. Finish tests - been blocked/lazy/busy on finishing this for a while
2. Add Example - should be straightforward
3. Need to iron out some details about how LinkExceptionHandler works in the offline client

There's also potentially some changed need @smkhalsa mentioned about moving the backoff mechanism into a separate link, although I'd like to put that off for the time being and focus on just getting the things above completed.

The PR I'm referring to is #147 by the way

[smkhalsa]

@HosseinYousefi

I'm not actively working on this, but I'd be glad to provide my thoughts/guidance if you'd like to contribute.

In case you haven't seen it already, there's an OfflineMutationTypedLink in the published ferry package which should work for basic use cases and can be used as a reference to implement a custom TypedLink. (it's really just a proof of concept and isn't well tested).

As @akinsho mentioned, I'd prefer to keep retry logic decoupled from the offline link. Retry logic probably can be implemented in a normal gql_link rather than a ferry TypedLink.

The intention for this PR was to implement a standalone offline client that bundles together the necessary offline bits (i.e. HiveStore and OfflineMutationTypedLink) with sensible defaults in a single import / class.

[akinsho]

@smkhalsa if the retry logic was split out how could it be setup in such a way that a user could specify which requests were to be retried and which not to retry. Would it require a user annotating a request, would it have to be global (which would be bad/unwanted for things like a failed login with wrong info etc). Maybe a list of request ids passed to the link on instantiation?

[smkhalsa]

I'd probably follow the precedent set by Apollo's RetryLink and just have a retryIf callback to determine whether or not to retry the request.

[akinsho]

Ahh that's a nice implementation to follow thanks for the link. I'll see if I can split it out in my PR using that format. I might need some help regarding how links are created if there are any bits I can't grok from the other links in the repo (I'll let you know if I get stuck)

[HosseinYousefi]

@smkhalsa That's great!

@akinsho Alright then, I'll wait for your PR to get merged and then we can decide on what should be done next to improve the experience.

[akinsho]

Given the conversation here re. splitting out the retry logic I'm going to tidy up what I have in the other PR which is a few bug fixes for things like ensuring sequential execution and ensuring that mutations are always executed etc. tidied up with an example and then hopefully we can merge that in after review and myself or anyone else can look into creating a retry link based on apollo's

[HosseinYousefi]

Hi, guys! Any updates on this?

[akinsho]

@HosseinYousefi you can direct comments to #147 since that is what is blocking this PR. I haven't really had much time to work on it. If you are willing to contribute the main outstanding thing is actually just an example showing how the client can be used.

It might actually be useful for you to dig in since it will give you a sense of how it works and might raise questions about how it can be improved.

Otherise I'm hoping to create the example and finish it before too long (end of the month) I'd ideally like to close this off sooner rather than later so other people can pick up and carry on the work since I don't really have a bunch of time for it atm.

[appinteractive]

Hey @HosseinYousefi & @smkhalsa any progress on that issue and in general for the future of that project?