feat(api-graphql): custom subscriptions

[iartemiev]

Draft until this is merged: aws-amplify/amplify-data#131

TODO:

• Update data-schema & data-schema-types dep versions after merging ^

Description of changes

Adds custom subscriptions support to data-client.

Given this schema

const schema = a.schema({
...,
onPostLiked: a
  .subscription()
  .for(a.ref('likePostReturnPost'))
  .returns(a.ref('Post'))
  .handler(a.handler.custom({ entry: './jsResolver_base.js' })),

onPostUpdated: a
  .subscription()
  .for(a.ref('Post').mutations(['update']))
  .arguments({ postId: a.string() })
  .returns(a.ref('Post'))
  .handler(a.handler.custom({ entry: './jsResolver_base.js' })),

}).authorization([a.allow.private()]),

data-client makes the following subscription functions available:

const sub = client.subscriptions.onPostLiked().subscribe({ next: ..., error: ... })
const sub2 = client.subscriptions.onPostUpdated({ postId: 'abc123' }).subscribe({ next: ..., error: ... })

Issue #, if available

Description of how you validated changes

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[iartemiev]

The workspace settings defined in this file override local VS Code settings, so this effectively forces everyone to use tabSize: 4. Removing it so contributors can use their tab size of choice.

[svidgen]

No blockers jumping out at me.

[svidgen]

I can't brain it right now, but it would be slick if there were a way to ingest these variations with some type guarding.

[iartemiev]

Agreed. contextSpec and options have a predictable shape, so we can guard those.

[iartemiev]

(will update shortly)

[iartemiev]

I added a type guard for contextSpec, but options and args are actually not deterministically distinguishable via type guard, because options consists of only optional params and we can't be sure that args won't contain an argument with the same name. Updated with a slight improvement, but not fully type guarded.

[svidgen]

Gotcha. Could a type guard be applied to ...args as a whole with guarding based on length and the shape of the first arg?

(Not a blocker.)

[iartemiev]

That's an interesting idea. I think it can work. Mind if I play around with that as a follow up?

[iartemiev]

Lines up the DX with aws-amplify/amplify-data#132

[iartemiev]

Migrating these to the new DX as well. We still have tests in data-schema that ensure the now-deprecated top-level .function functionality is intact.