search

aerogear / offix

GraphQL Offline Client and Server
https://offix.dev
Apache License 2.0
760 stars 45 forks source link

Can I put `offix` into a Service Worker? #161

Closed loganpowell closed 5 years ago

loganpowell commented 5 years ago

Feature Request

Is your feature request related to a problem? Please describe. Would like to use offix as the single source of truth for my app online and off

Describe the solution you'd like I'd also like to leverage some of the other features of Service Workers (push notifications, keep scripts - e.g., offix persisted across sessions - also uses IndexedDB like idb-localstorage)

Describe alternatives you've considered Seems like a match made in heaven. I couldn't find any such references in the docs/issues/code... just curious if plans are brewing...

StephenCoady commented 5 years ago

Hi @loganpowell, thanks for reaching out. Would you mind elaborating a little bit with the use cases you envisage? I am trying to discern what advantages it will provide. My experience with service workers is limited but from what I can see (some) of the benefits they provide are automatically handled in offix such as network management, background sync'ing etc.

Any information you can provide would be helpful!

loganpowell commented 5 years ago

I was thinking that - since offix handles so much of the state managment and offline capabilities, it seemed a natural fit within a service worker as the proxy between the client and server. Some examples of potential I see:

Currently there are not "ready to wear" GraphQL service worker implementations. The only thing I found that seems even compatible is micro-graphql-react which is tailored to react and is only a way to use GET instead of POST to make it fit nicely with the fetch API of service workers' caching strategy.

wtrocki commented 5 years ago

@loganpowell There should be no problem of using offix in service worker as both IndexedDB and offline state are provided. Api for both can be different so we will need to provide wrappers.

The problem of offix being in service worker is the problem of using offix client inside the application to make requests. We are doing now some serious refactor that will simplify many use cases - including service workers. Can you provide more information how would you see client talking with service workers?

I think workbox is completely different piece of the puzzle. Workbox will be wrapping some complex api for static resource caching. Offix is GraphQL specific cache layer.

They can exist on both lavels. Workbox will cache js code that will also contain offix initializer. Bringing offix instance to service worker makes less sense due to the cost of using it as client in the app - data serialization is needed. I would really like to know your use case and see how we can help here.

if offix lives in the service worker, it is always on and doesn't have to be reinstantiated

Service workers getting some short timeframe (depending on operating system) and it will mean that client will need to be reinstantiated.

loganpowell commented 5 years ago

Hi @wtrocki thank you for following up on this. Since our last exchange, I have had more time to work with service worker and figure out ways to cache graphql requests. I believe the work you've done for conflict reconciliation (not just caching), as well as acting as a graphql client felt to me like you could kill a lot of birds with this, but I definitely don't want to try to fit a "square peg in a round hole" if you don't see the fit :)

wtrocki commented 5 years ago

Thank you so much. No worries. I think we might explore service workers for more comprehensive use cases. For example we can have fully offline website with service worker and offix together.