RFC: Support Datastore for Web and Desktop

[abdallahshaban557]

We are creating this issue to get insights and feedback into our plans for supporting offline first and caching experiences with our API offerings when targeting Web and Desktop. We want to use this issue to collect feedback from you on the use cases you want to use Offline first and caching for, so that we can validate the path forward for us as we explore it further.

Please help us with providing us with the exact use cases you want to use Datastore for on Web and Desktop, and how it would benefit your users. For example:

• Cache data retrieved from API calls.
• Create a faster first-time loading experience by grabbing the latest retrieved data to users.
• Allow users to browse the app even if their network disconnects by using the latest retrieved data.
• Automatically re-connect and retrieve data updates when the internet connection is re-established.

[jamontesg]

Are you kidding, are you just going to start the project?

[abdallahshaban557]

Hi @jamontesg - We have created this feature request to make sure we capture all feedback on Datastore specifically, since our other categories have shipped for Web and Desktop support.

[dorontal]

Why we think Datastore + Web would be great for our (music collaboration) app? Here are a couple of more points to add to the bullet points at the top of this issue (which are also all benefits that we see):

1. Offline first apps are accessible by more people on earth: we want a musicians living in a remote village with no Internet to be able to walk into an Internet cafe, download some tracks, then go back to their village and record along with those tracks with no Internet, until they are ready to upload the recorded result back, say a month later when they return to the Internet cafe. Datastore can make it much easier to create an offline-first app due to its DB caching.

2. Apps running in the browser bypass the judgment / vetting of Apple or Google's app stores. When your app runs in the browser, there is less risk that one of those two companies would decline your app. There is less overhead from not having to wait for the approval process.

3. We hope Datastore will become fully optimized (e.g, DB updates that send partial data with only the fields that have changed rather than the entire model instance), saving us the time of having to do those optimizations ourselves.

4. We hope Datastore can help our client apps make fewer network requests, in general, by use of extensive caching - this will make it less costly to have any app up and running on AWS - it lowers the barrier to entry for any app publisher because it lowers the overhead costs of doing business because the app's users consume less cloud resources.

[abdallahshaban557]

Thank you @dorontal for this feedback!

[dkliss]

On device storage is important for all above use cases mentioned. In context of a cross-platform application, if all platforms cannot support a unified offline storage system it will become a challenge to remotely sync data to AWS from desktop or web devices. Offline first also ensures that in areas with limited bandwidth, data sync is scheduled at off-peak or user defined times to ensure user experience stays positive.

[loint]

@abdallahshaban557
Chat is the core feature for almost enterprise web and apps so we can have a better experiences and consistency (multi-platform app) in single implementation - our user is able to read message even their connections are interrupted.
We're waiting for this support for a long time because hard to maintain both web and app with same chat data synchronization.
Local storage is also benefit us in case we want to store all in local first and sync to server later to have a better experiences without depends direct on a real time connection.

[dgagnon]

My notes:

1. Make sure to include a fully working example of datastore + authenticator UI + cognito auth.
2. The datastore documentation needs to be explicit about which feature from appsync/graphQL are not supported, i.e. multiple owners. At the moment, the datastore doc only contains part of the information needed to manage the graphql models, so users are directly to the API(graphql) doc which very often will not work with the datastore. Alternatively, keeping the datastore to feature parity with appsync would help greatly.
3. Please make sure in include performance tests in your integration suite: above 20 models 10s of thousands of records, everything because really slow, when it even works. (think an online store with different kind of speciality products).
4. The datastore starts on configure, which creates exception when not logged in ( since you need to configure amplify to do the authentication. This creates confusions for developers. Unless a public API category is configured. datastore should not start until auth happened. Adding a flag to delay starting datastore would work as well.

As for the uses cases: it is, and always has been, offline support. This is the only reason we are using AWS. We built three version of our app so far and have had to completely removed datastore, which breaks the only advantage amplify has over the competition.

I will update my message as new ideas comes in from the team.

[jamilsaadeh97]

I think that offline first capabilities is best when it comes to querying and syncing data to the cloud. I'm using DataStore extensively and I must say, it's great but, at the same time, lacking in some areas like starting time, ability to handle a lot of models and data effectively, the differences with GraphQL API like multi owner....

My use case is a reservations application and offline first is the way to go since it offers a better user experience while everything is syncing to the cloud in the background. Sadly I can't have my app in the Web since DataStore is not implemented there.

For the past week I've been testing the possibility to migrate everything to GraphQL API and most probably I will, but I saw that DataStore makes everything easier, especially observeQuery() so that's why I like it but in my opinion it needs to be better in order to be production-ready for applications that offers services.

If the support of Web and Desktop means that DataStore will be rewritten in Dart, and, as result, will become more effective in iOS and Android, then Amplify Flutter would be the best out there.