AWSAppSyncClient full support for local state in gql queries (Apollo 2.5)

[StefanoSGI]

Do you want to request a feature or report a bug?
Feature, please consider upgrading AWSAppSyncClient dependencies from Apollo 2.4 to Apollo 2.5

What is the current behavior?
Local state support in Apollo 2.4 requires lots of boilerplate;

//2.4
const GET_CURRENT_THEATER = gql`
	{
    	currentTheaterId @client
	}
`;
const LIST_MOVIES = gql`
    query list($theaterId: ID!) {
        listMovies(theaterId: $theaterId) {
            id,
            name
        }
    }
`;
[...]
render() {
	return <Query query={GET_CURRENT_THEATER}>{
		queryRes => {
			const currentTheaterId = queryRes.data.currentTheaterId;
			return <Query query={LIST_MOVIES} variables={{theaterId: currentTheaterId}}>
				{this.renderMovies.bind(this)}
			</Query>
		}
	}</Query>;
}

What is the expected behavior?
Apollo 2.5 brings significant improvements by supporting injection of local state directly in the query variables with the @export directive.

//2.5
const LIST_MOVIES = gql`
    query list($theaterId: ID!) {
    	currentTheaterId @client @export(as: "theaterId")
        listMovies(theaterId: $theaterId) {
            id,
            name
        }
    }
`;
[...]
render() {
	return <Query query={LIST_MOVIES}>
		{this.renderMovies.bind(this)}
	</Query>;
}

See also https://www.apollographql.com/docs/react/essentials/local-state.html#client-variables

Which versions and which environment (browser, react-native, nodejs) / OS are affected by this issue? Did this work in previous versions?
aws-appsync 1.7.2

[webberwang]

Support for 2.5 would be great, the AWSAppSync is a blocker to using 2.5 with applications

[jpaas]

Agreed. Especially since Apollo themselves have said that apollo-link-state is flawed and broken and the local state support in 2.5 core is the way forward. Right now, I am a bit stuck with no ability to use AppSync + Apollo + local state.

[manueliglesias]

Thanks for the report, this is on our backlog, we are doing some internal testing and PoC.

I can't give an ETA, but we'll keep you posted in this issue

[adav]

We're also looking to remove apollo-link-state as per the Apollo docs (and warning on their github readme) and bumped into this issue.

[ntziolis]

Is there any work we can do, this is on the very top of our blocker list to NOT adapt AWSAppSync.

@manueliglesias I understand an ETA is difficult to give but are we talking weeks or months out? If we don't get any indication we will need to choose a different platform as we are heavily relying on local resolvers.

[undefobj]

@ntziolis since the new Apollo 2.5 is building link state into its core, we're going to look to see what this entails rather than the apollo-link-state which looks to be going away as an independent package. We need to evaluate what this means as trying to manage cache updates along with exposing hooks for you to update the cache is a complex process. Additionally we'll need to see if there are any additional changes in 2.5 that might impact the AppSync client.

I wouldn't say this work is imminent based on customer demand for other feature requests. That being said if you can give us an explicit example/code sample of the use case and behavior you're looking for it will help us to scope the work.

[evelant]

As a new user evaluating appsync for my project this seems to be a pretty big blocker. Without this upgrade it sounds like we will end up writing a lot of code that will require a big refactor since upstream apollo has already said it is deprecated.

[ntziolis]

@undefobj The use case is very simple:
Have ONE way to handle ALL data in our app in a type safe manner and that is via GraphQL. This significantly reduces complexity of our toolchain, but thats just a side effect. The most profound effect is that it moves the line of what is to be considered the backend of an application. Frontend devs really don't care about managing data, they just need it. On the other hand our backend devs REALLY care about the data. Since using client side resolvers our backend devs now can and LOVE writing client side code (at least when it comes to data handling). This has increased our productivity and app quality significantly. We could have NEVER gotten our backend devs to deal with redux.

So you see this requirement is not about a code example but about the business case. The core thing local resolvers allowed us todo is to treat anything data related as "THE" backend of our app and lets our Frontend devs focus 100% on building features vs having to deal with data related tasks.

Just to be clear, we need full support for local resolvers. I'm not sure this is 1:1 with supporting Apollos new state management.

[arantespp]

@undefobj I'm in the same situation as @ntziolis. As my team is using AWS AppSync as a backend and we opt to use aws-appsync to handle the communication with the backend which uses Apollo Client to make queries and mutation. Using the older version with apollo-link-state, we don't have to learn Redux or another management lib. "This has increased our productivity and app quality significantly" for sure, as @ntziolis said.

An example in our last app was getting user data. When a user logs in, we get his userId from authentication system and make a query to get user data like name, age... Every time in our app we want to get the same user data, we need to get userId again and make the query (with Apollo Client to use its cache). But the userId has to be called from browser storage, for instance. This way we are using two systems to handle state: Apollo cache and browser storage. If apollo-link-state was working, we simply create a mutation which would save user data without userId and we could get the user data without obtaining userId every time.

[gabmichels]

Also looking forward to the safe client disposal of ApolloClient.stop(); introduced in 2.4.12

[jpaas]

Any chance we could get an update on Apollo 2.5 support with an ETA? If its going to be a while then I'll probably migrate back to 2.4.

[ts-23]

Came up with a temporary solution by creating a new apollo client that solely handles local state. So Appsync will be the default client using the Apollo Client 2.4 with the old apollo-link-state but another apollo client will handle the local state with version 2.5.

When we query or mutate in the components or view, Vue-Apollo lets us specify the apollo client to use per component or per query basis.

Later when Appsync upgrades the package we can do some minor refactoring.

I am new to the graphql world. If anyone thinks this is a terrible please let me know. It would be much appreciated :)

  const provider = new VueApollo({
    defaultClient: appsyncClient,
    clients: { [APOLLO_CLIENT.LOCAL_CLIENT]: apolloClientLocal },

[idanlo]

Anything new with this?

[danrivett]

Hating to have to create a "me too" comment, but this ticket has been open 5 months I would appreciate a further update on how likely we are to see this supported any time soon @undefobj ?

Our use case is simple - try and consolidate our local state management to avoid using Redux for local state management and persistence with Apollo/AppSync for remote state/data.

We'd also like to use the new React Hooks functionality that later versions of Apollo Client supports to simplify the boilerplate, but that's off topic for this issue.

[danrivett]

This started off as an annoyance, but unfortunately has quickly become a serious impediment to us. We're attempting to do a POC using AppSync and without any clear understanding on how to manage local state we're in danger of failing the POC.

Because of that, I'm reflagging this to attempt to get some direction and update from the AWS team. @undefobj mentioned higher up about posting updates to this ticket as appropriate, but there's not been any update since the beginning of April, so I would greatly appreciate an update if at all possible.

Has anyone been successful in using Apollo Client v2.4 to decorate server query results with additional fields stored as client local state? If so, I'd appreciate some direction.

I did see this comment, but it's almost 18 months old and so not sure if it's still valid. That's my next avenue I'm attempting but not sure how it applies to decorating server query results with additional client fields.

Alternatively I have seen some reports of manually upgrading apollo-client to 2.5+ but also seen issues with hydration and mutations which has put me off exploring further, but if anyone has successfully managed this, I'd be very interested to hear more.

[danrivett]

😞 Just seen this comment from earlier this year not recommending using Apollo Link State with AppSync, so I guess that supercedes the comment I linked to above.

It's more than a little frustrating to find such an exciting and promising technology such as AppSync showing such promise to simplify full-stack development and then take it all away with common use-cases being neglected such as local client data. I'm not meaning to rant, I'm just trying to provide some transparency to help convey the pain being felt.

[adav]

@danrivett I was in a similar spot. Gave up waiting on AppSync updates and moved my Proof of Concept onto a Postgres+Hasura stack. Very quick to recreate, feels more solid an implementation and more GraphQL-beginner friendly than AppSync anyway.
Edit: Forgot to mention that you can then use the latest Apollo local state stuff because there isn’t a dependency on the AWS client.

[idanlo]

@adav I also gave up on this library. I had workarounds for using local state with it using apollo link (which is deprecated) but hooks still didn't work because it only got support on apollo 2.5.
Also I figured that if they can't respond and post updates on a 6 months old issue I better off getting a better library that is maintained

[SebSchwartz]

As mentioned in #448 :
Can AWS tell us what is the plan for supporting Apollo 3.0? Is it in the roadmap? Is there an ETA?
@elorzafe @manueliglesias @dabit3

[ilya-bmi]

We are moving to another stack because of this issue. It looks like Amazon no longer maintain this project. Which is very sad.

[andymrussell]

Yeh, similar for myself also..
After no further forward on these issues (client state, and hooks), I also have also aborted AppSync.

[austinamorusocfc]

@jordanranz Is there any headway on getting local state supported via client 2.5

[austinamorusocfc]

Our team would benefit heavily from this being updated.

[DanLombardy]

Is there any updates on this issue? The lack of this feature is really slowing our team down

[undefobj]

Hello everyone - I want to reply and assure you that we have not abandoned support of this project. Per my earlier comment, this is a complex process and to be completely transparent there are things in the Apollo library that are out of our control and there have also been breaking changes in Apollo versions which we're trying to account for, which is also why we pinned the version. We've been spending many hours trying to account for this but it's not simple to solve. After putting more thought into this we've got some initial solutions that I hope will unblock many of you. What we've done is packaged two of the "Links" which are part of the SDK - the Auth and Subscription Links - and published them to NPM. This will allow you to include them in the newer Apollo versions if you wish to use the newer features. This does not include the "Offline Link" for offline support which is more complex to solve and we're looking into for the future.

Installation of the links:

npm install aws-appsync-auth-link aws-appsync-subscription-link

Usage:
https://github.com/awslabs/aws-mobile-appsync-sdk-js#using-authorization-and-subscription-links-with-apollo-client-no-offline-support

With is I would then give the following recommendations for choosing your client strategy:

1. If you do not have offline use cases, you can either use the Auth & Subscription Links above with the latest Apollo client or alternatively use the Amplify GraphQL client instead of Apollo:https://aws-amplify.github.io/docs/js/api#amplify-graphql-client
2. If you do have offline use cases please use the current version as-is with the older Apollo version. We're still working on a future strategy for the Offline Link.

Please let us know if you have any trouble using these links or if there is a scenario which we haven't accounted for here.

[jonixj]

It has been > 3 months since last update regarding this issue. What is happening?

[SebSchwartz]

@undefobj Any news? Should we switch to Amplify Datastore (as it is low low low priority in the backlog) or it's still going to be resolved?

[undefobj]

@SebSchwartz @jonixj At this time I do not have an update on the ability for offline with the newer versions of Apollo. We are still researching this but there is still too much variability in the data model and controls of link state based on the controls available. At this time I would recommend that you leverage DataStore for offline use cases or if you would like to use the latest Apollo version leverage the Auth and Subscription links as outlined above.

[devyardstick]

Is there going to be support for Apollo >2.5 with local state? I'm just getting back into using amplify and there seems to be no support for local (@client) data with aws appsync graphql server.

[d2kx]

You can use new Apollo versions with the aws-appsync-auth-link and aws-appsync-subscription-link packages. I don't think they will put much effort into the Apollo client anymore, as they shifted focus on Amplify DataStore.

[AlexThomas90210]

@undefobj Is there a way to use complexObjectsCredentials with your recommendation to use aws-appsync-auth-link? I am having issues with it, or is it that if you need complex object upload to S3 you must stay with < Apollo 2.5?