Curious if any thought has been put into supporting a site working without an internet connection. Thinking about local caching, optimistic updates, change tracking for when a client comes back online.
There has been some scattered discussion of offline support (which touches on workers and PWA). The most thought has come from @phzbox who created this Google Doc in hopes of getting the conversation started:
The point is to offer a setup command to create a raw manifest.json and service worker file.
The proposed files enable a “shallow PWA”, with them you can straight away install an app on device and cache an offline page to display if network is missing.
That would be level 1.5, according to the document Offline & Real-time updates, just a first step to get things started.
As for the level of support we could aim at reaching for RW, I think it’s possible to get up to level 4, partly achieved, as described in the doc. The relational DB issue would be a cliff I’d not try to jump over and leave it entirely to the developer, if we can get there it would already be awesome though.
@thedavid does the core team have a referee for this feature, the community could discuss next steps with? Anyone with experience on the matter?
On my side I’d gladly finish my PR but I’d need some community/core team feedback to see what’s needed for a first step, if the setup command is good enough to build on or not.
@phzbox may I request a review/feedback for #1372 ?
I don’t speak a word of Spanish, so I had to run your message through Google Translate, and something might have been lost in the translation. Did you make that hospitalrun site? What should I look for on the site?
The point is to offer a setup command to create a raw manifest.json and service worker file.
The proposed files enable a “shallow PWA”, with them you can straight away install an app on device and cache an offline page to display if network is missing.
(Relay can actually enable it with a third party plugin called react-relay-offline that comes at an added cost of 16.4 kB, according to bundlephobia.)
But aws-amplify/datastore is a GraphQL client that does offer offline support. It is open-source, and the client-side part of it is vendor agnostic. Importantly: it doesn’t add clutter to the component hierarchy, like Apollo Client tends to do (amongst other problems, mentioned in redwoodjs issue #758). So what about that, as a full replacement of Apollo Client? A downside is that aws-amplify/datastore takes 127 kB, according to bundlephobia. When Apollo Client takes only 15.6 kB. However, the alternatives for NextJS next-offline or next-pwa take 787 kB and 916 kB each. I would guess that makes offline-support too costly to add to most NextJS apps. So, having offline-support in RedwoodJS could be a competitive advantage.
(PS: I had to remove all the extra links I added to back up my claims and for your convenience, since new forum users here are only allowed to add 2 links, unfortunately.)
With its elegantly small bundle size, I think React Query is the hottest candidate for a client side GraphQL library these days. I see they have an entire section on Optimistic UI as well: https://react-query.tanstack.com/guides/optimistic-updates
Awesome that you made the GraphQL client swappable! It increases the modularity of Redwood, and heeds the wise adage of Robert C. Martin to “Date frameworks, but not marry them.”. So it will be even more future-proof for ecosystem changes/shifts.
Datastore is something I’ve been following because I’m interested in anything Swyx finds interesting. I’d be curious how easily it can be used independently from the larger amplify-js library.
Great. Now all my posts in this thread were flagged by the community and removed. Did someone implement a very aggressive automatic removal system of posts with links?
Anyways, swyx has now been notified about reducing the bundle size of DataStore (so it can more easily be included in frameworks such as Redwood) for offline support. So I guess he’s already looking into it.