API Category - Separate protocol for Model based GraphQL about amplify-swift

[jamesonwilliams]

I have had this thought, as well.

Right now in the Android code base, we have this data modeling stuff, in the core library. Then, in API and in DataStore, we expose APIs that use it.

So right now, data modeling is a cross-cutting concern to Amplify. But, maybe it should be more tightly contained.

In practice, our data models are tightly architecturally coupled to AppSync features. So, the Data Modeling stuff is, in actuality, more like something that belongs in (a new version of) the AppSync SDK.

[lawmicha]

I have had this thought, as well.

Right now in the Android code base, we have this data modeling stuff, in the core library. Then, in API and in DataStore, we expose APIs that use it.

in iOS, i believe this is the same, AmplifyCore contains Model related classes while API and DataStore exposes ways to use it.

So right now, data modeling is a cross-cutting concern to Amplify. But, maybe it should be more tightly contained.

In practice, our data models are tightly architecturally coupled to AppSync features. So, the Data Modeling stuff is, in actuality, more like something that belongs in (a new version of) the AppSync SDK.

my current thinking is that AppSync SDK does delta sync and all of the graphQL functionalities, so AWS's implementation of API Plugin and DataStore would essentially solve the same use cases and be the replacement it for new customers.

My overall goal for API plugin, considering that it is tightly coupled to Amplify GraphQL Transform and AppSync service, is that we provide the tools necessary, decorators, Model class for deserialization, that developers can use based on their use case defined by their schema and directives that they used.

[lawmicha]

i'm running pass all of the issues i've opened and seeing what can be closed, i think this issue can be closed for the API Plugin work that is on-going in general, and dicussion can continue else where, and thanks for your input here