Datastore syncExpressions in a one to many relationship?

Which Category is your question related to? Datastore

What AWS Services are you utilizing? Appsync Datastore

Provide additional details e.g. code snippets Is it possible with Datastore syncExpressions in a one to many relationship if we sync the top model does the related items get synced too and nothing else?

Say for example

type Post @model {
  id: ID!
  comments: [Comment] @connection(keyName: "byPost", fields: ["id"])
}

type Comment @model
  @key(name: "byPost", fields: ["postID", "content"]) {
  id: ID!
  postID: ID!
  content: String!
}

Is it posible if we sync just Post model with Id then all it’s related comments are synced and not all comments.

DataStore.configure({
  syncExpressions: [
    syncExpression(Post, () => {
      return (c) => c.id('eq', '123')
    }),
  ],
})

[iyz91]

@renebrandel @undefobj Just providing an update. I evaluated the AppSync SDK route, primarily revolving around the old Apollo client it relies on and outstanding issues that seem to highlight the library has been abandoned, which would be risky for production even if the outstanding issues wouldn’t affect me. This is unfortunate as for many users a write-through cache setup is sufficient for optimistic response and general offline use.

With DataStore not currently ready for multi-tenancy, model relationships (such as the one detailed in this issue) and subscription/sync issues, among others, and the AppSync SDK generally abandoned, customers are left with no pre-built, production ready offline capability when using AppSync for these types of apps. I could, of course, develop/adapt my own solution but part of the reason why I chose this framework was because of what was presented in the docs and blog posts for AppSync/Amplify/DataStore for offline capabilities. From what I can tell, trying to implement Apollo Client for its in memory cache with AppSync would probably be more trouble than it’s worth considering the AppSync specific implementation differences and time limitations.

So I myself have opted to forgo offline use for now while using the Amplify API library for the sake of time and existing investment into the framework. The majority of my real-world uses cases will have sufficient internet access so it’s an acceptable tradeoff for now. The GQL transformers and the other categories in general still work well and save me significant time. This is with the hope that, with the highest priority of the Amplify team, DataStore will be partly redesigned to generally accommodate multi-tenancy and will be a relatively easy drop-in replacement in the future for those already using the Amplify API library. Ideally, like the framework itself, “escape hatches” can be provided with write-through capability for non-trivial store/sync scenarios. If this is prioritized, and if it is successful for use cases such as a WhatsApp clone, I wouldn’t be surprised if Amplify, AppSync and related services see a big jump in adoption (not that AWS is hurting of course). For now, I would strongly urge you to make the limitations clear in your documentation, especially the DataStore sections.

I know this work and DataStore in particular is terribly complex and the Amplify team is undoubtedly putting in incredible work. I’m just providing my 2 cents from the customer point of view. If anything I stated is inaccurate or you are aware of alternative solutions, I would appreciate any clarification and direction.

[iyz91]

@iartemiev @renebrandel Out of curiosity at this point, what would the solution to the above be, if there is? Telling your sync engine to stop and start for many predicates is pretty odd.

If there’s no current solution, it seems DataStore was not designed from the outset for many common application design patterns. Seems to be more useful for small-medium internal organization apps and demos, but not much else in the real world, which would generally be fine if the docs and AWS blog posts made that clear (which they don’t). Please correct me if I’m wrong.