Aws-mobile-appsync-sdk-js: Apollo-client dependency version

[miiihi]

Latest aws-appsync is using [email protected], which is more than 9 months old and has at least one serious bug (solved already, see https://github.com/apollographql/apollo-client/pull/4352).
Are there any obstacles to update to latest versions of dependant libraries? And plans about that?

Thanks, miiihi

[jimmyn]

Please upgrade apollo-client, it is very much needed for hooks support

[jimmyn]

Any updates here? this is very much needed.

[beezeebly]

Hi @jimmyn, I followed the comment here to update the Apollo Client to 2.6.3 in order to use "@apollo/react-hooks".

If you're using Yarn, force AppSync to resolve to Apollo Client 2.6.3 by adding the following to your package.json:

"resolutions": {
    "apollo-client": "2.6.3"
  }

[ryanwalters]

@apollo/react-hooks is out of beta, hopefully this gets a little more attention from the AppSync team now.

"React Apollo 3 uses hooks behind the scenes for everything, including the graphql HOC and render prop components." — Apollo Docs

[tjhowe]

@beezeebly Have you had any issues with the fixing the apollo client?

Also hopeful that the apollo client can be bumped. Mainly for a resolution to the bug @miiihi 's pointed out, but also the new @apollo/react-hooks lib.

[psiqueir]

Any news on this from the AppSync team?

[nathanbirrell]

This really needs attention.

We've addressed this by using Yarn's resolutions option in the package.json:

  "resolutions": {
    "apollo-client": "2.6.3"
  }

[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.

[pickfire]

apollo-link-http also needs to be updated, codegen depends on the newer versions.

[royalaid]

I don't want to pile on to the issue that will already be a ton of work but merely want to point out that Apollo 3.0 is coming

[BenoitDel]

Is there any roadmap for apollo-client 3.0 support ?

[ianmartorell]

I was looking to use Amplify and AppSync with @apollo/react-hooks and realized it's not working. It's been almost a year since your last comment @undefobj, are there any updates you can share? Thanks!

EDIT: I see there's more info in #448

[hutber]

Ye, it very much seems this project has been abandoned now sadly. @ianmartorell I think the only solution for us (me) to write my own client which shouldn't be too hard in theory I believe.

Still a shame though

[manueliglesias]

Hi,

If you have a need for just Apollo 3 support without offline, we just published updated versions of the links

See: https://github.com/awslabs/aws-mobile-appsync-sdk-js/pull/561#issuecomment-701696316

If you need offline support, we recommend you use Amplify DataStore

[treyspiva]

If you need offline support, we recommend you use Amplify DataStore

Does this mean you have given up implementing offline support? The DataStore is not good if you want to use a query and get relationships. You have to make multiple queries. It is more like using an ORM in your frontend code. Which defeats a big part of the benefit of using GraphQL. This is more like going back to a REST API.

To follow relationships DataStore uses the following code:

const post = await DataStore.query(Post, "123");
const comments = (await DataStore.query(Comment)).filter(c => c.postID === post.id);

This means that it first retrieves all of the comments then filters them on the client based on the post id. This is only reasonable for a small dataset. Not to mention, dynamodb has a restriction of only 1MB. So, how are you going to page all of the objects to filter out the unwanted comments? This is also not secure in a multi-tenant environment. How can this be the suggested solution except for small applications?

There is also this approach to query the data:

const posts = await DataStore.query(Post, c =>
  c.rating("gt", 4).status("eq", PostStatus.PUBLISHED)
);

This is making the UI call the database directly. No possibility to implement some real security checks. It would also open you API up to attack. . A hacker can just open up the console, and start calling your API with whatever conditions they want. So, they can start to query data for more than a single customer. If your permission model (multi-tenant) does not support being able to add trivial aws user id to the API. In the case of the multi-tenant a user can belong to more then one tenant. You have to check if the user has access to the tenant that owns the resource. Since the user can belong to more than one tenant the cognito mappings suggested do not work either. So, you have to do the work in the resolvers.