Amplify-cli: How does API + Datastore play on the same project?

Created on 16 Dec 2019  Â·  4Comments  Â·  Source: aws-amplify/amplify-cli

QUESTION
Which Category is your question related to?
API, Datastore.

Which Products is your question related to?
AppSync, AppSync's Conflict Detection , AppSync's Sync DynamoDB operation.

Hello,
This is an opinionated framework with 'ready to go' use cases, but I am using it because until now I could go custom as well, and I get tons of benefits from it.

I am amazed with Datastore announcement and such an early availability as it will solve plenty of developer needs when developing apps. Thank you very much!

I know it has just been released, and it is in preview, but already some doubts arise, and I couldn't find answers through the docs nor published videos. So here are my concerns:

  1. _API + Datastore on the same project_: I see them as separate tools that bring different added value –even if both are based on AppSync (GraphQL)–.
    I can easily find use cases with both tools running on the same app. After reading https://github.com/aws-amplify/amplify-ios/issues/239#issue-534310745 and https://github.com/aws-amplify/amplify-ios/pull/249#discussion_r356254432 I got concerned as it seems that you can not have a syncable datastore with a non syncable API at the same time. Will API and Datastore be able to play independent?, will them work at the same time? As far as I could test, when using both on the same project only one Appsync API is deployed to the backend. Which of the following alternatives should describe it better?:

    1. Should I consider API and Datastore two different Amplify independent categories with independent resources?: both API category and Datastore should deploy independent Appsync APIs (two schema).


    1. Should I consider API and Datastore two different Amplify categories that share same resources?: both API category and Datastore run independent (non-exclusive), but sharing the same Appsync API (one schema).

    1. Should I consider Datastore as an extension/feature for API?: so when Datastore is active, API should not be used. Then I would suggest evolving '@model' directive including options to choose on when using datastore/cloud-on-demand resources:
      ·@model-local models: current behavior achieved with datastore having "push" flag to false. This would be managed by 'Storage Engine' without 'Sync Engine'.
      ·@model-cloud models: current behavior achieved with API (without Datastore enabled). This would be managed by 'API' SDK and 'Apollo Cache'.
      ·@model-cloud-syncable models: current behavior achieved when activating Datastore. This would be managed by 'Storage Engine' + 'Sync Engine'.
  2. AppSync's Conflict Detection and AppSync's Sync DynamoDB operation are super Appsync features!🚀, but this time really opinionated 'ready to go' amplify flavored, and with a complete lack of customization😅. The Base table 'scan' part of it, plus the Delta DB indexing and queries doesn't fit my project needs 😅😅.


    1. In terms of Conflict Detection, as far as I understood it is done with the monotonic counter and the current version. Why is it needed the delta table on this?


    1. In terms of Sync operation, in order to get DeltaSync I believe I can use Datastore by overwriting Query.syncModelName.req.vtl with my own Sync resolver, using queries and my use case indexes instead of the new Sync operation. But I would love more information on how 'Sync Engine' works.

Thank you very much in advance.

DataStore question

All 4 comments

I have opened two feature request regarding datastore models: local-only https://github.com/aws-amplify/amplify-cli/issues/3023 and custom resources fed https://github.com/aws-amplify/amplify-cli/issues/3024

I have just noticed the difference between working with API and Datastore at model registration time:

  • AWSDataStorePlugin(modelRegistration: AmplifyModels())
  • AWSAPIPlugin(modelRegistration: AmplifyModels())

Does that means that I could go with:

  • AWSDataStorePlugin(modelRegistration: AmplifyDatastoreModels())
  • AWSAPIPlugin(modelRegistration: AmplifyAPIModels())

so that Storage Engine, Storage Adapter, and Sync Engine only manage Datastore plugin registered models?
in addition, in parallel, can I independently work with API plugin registered models with backend fetching 'on demand'?

  1. _API + Datastore on the same project_: I see them as separate tools that bring different added value –even if both are based on AppSync (GraphQL)–.
    I can easily find use cases with both tools running on the same app. After reading aws-amplify/amplify-ios#239 (comment) and aws-amplify/amplify-ios#249 (comment) I got concerned as it seems that you can not have a syncable datastore with a non syncable API at the same time. Will API and Datastore be able to play independent?, will them work at the same time? As far as I could test, when using both on the same project only one Appsync API is deployed to the backend. Which of the following alternatives should describe it better?:

      1. Should I consider API and Datastore two different Amplify independent categories with independent resources?: both API category and Datastore should deploy independent Appsync APIs (two schema).
      1. Should I consider API and Datastore two different Amplify categories that share same resources?: both API category and Datastore run independent (non-exclusive), but sharing the same Appsync API (one schema).
      1. Should I consider Datastore as an extension/feature for API?: so when Datastore is active, API should not be used. Then I would suggest evolving '@model' directive including options to choose on when using datastore/cloud-on-demand resources:
        ·@model-local models: current behavior achieved with datastore having "push" flag to false. This would be managed by 'Storage Engine' without 'Sync Engine'.
        ·@model-cloud models: current behavior achieved with API (without Datastore enabled). This would be managed by 'API' SDK and 'Apollo Cache'.
        ·@model-cloud-syncable models: current behavior achieved when activating Datastore. This would be managed by 'Storage Engine' + 'Sync Engine'.

DataStore is an extension to the API category and the same resource will be used. DataStore is useful when you are building an app that needs support for offline data, where as using this with API category is useful to run it in a lambda (or some place where you know you won't be offline).

  1. AppSync's Conflict Detection and AppSync's Sync DynamoDB operation are super Appsync features!🚀, but this time really opinionated 'ready to go' amplify flavored, and with a complete lack of customization😅. The Base table 'scan' part of it, plus the Delta DB indexing and queries doesn't fit my project needs 😅😅.


      1. In terms of Conflict Detection, as far as I understood it is done with the monotonic counter and the current version. Why is it needed the delta table on this?

Delta Sync table is not used for conflict detection and resolution. But conflict detection works only when Delta Sync is enabled on the API, as the service does not expose a switch to turn on conflict detection separately

hi @lazy-var so out of curiosity have you been able to successfully use both in the same project?

Was this page helpful?
0 / 5 - 0 ratings