feat: Add lamda data client support

[stocaaro]

Problem

Users would like to use the Gen2 data client interface to access their APIs from application functions (lambda's).

Our docs offer instructions on this experience, which stop short of indicating how the customer should provide the model introspection schema needed to make the whole experience work.

Changes

1. Build the model introspection schema
   1. Build the Model Introspection Schema (MIS) in the data factory
   2. Construct an S3 bucket with the MIS as an object
   3. Grant get permission to the MIS to any function that is granted resource permissions to the data schema
   4. Add the bucket name and object key for the MIS to SSM (where it will be read
2. Add config function for user ease
   1. Add a configuration function we can internally import from import { getAmplifyClientsConfiguration } from "@aws-amplify/backend/function/runtime";

Example: amplify/functions/todo-count/handler.ts

import type { Handler } from "aws-lambda";
import { Amplify } from "aws-amplify";
import { generateClient } from "aws-amplify/data";
import type { Schema } from "../../data/resource";

import { getAmplifyDataClientConfig } from "@aws-amplify/backend/function/runtime";
import { env } from "$amplify/env/todo-count";

const { resourceConfig, libraryOptions } = await getAmplifyDataClientConfig(env)
Amplify.configure(resourceConfig, libraryOptions);

const client = generateClient<Schema>();

export const handler: Handler = async () => {
  const todos = (await client.models.Todo.list()).data;
  return todos.length;
};

Corresponding docs PR, if applicable:
aws-amplify/docs#8096

Validation

• Unit tests added
• Manually tested in an example application
• E2E tests added for data access and unrelated user use of S3Client

Checklist

• If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
• If this PR requires a change to the Project Architecture README, I have included that update in this PR.
• If this PR requires a docs update, I have linked to that docs PR above.
• If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

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

[changeset-bot]

🦋 Changeset detected

Latest commit: 2b7b02f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@aws-amplify/backend	Minor
@aws-amplify/backend-function	Minor
@aws-amplify/backend-data	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Amplifiyer]

The changes look good to me. The only missing part is an e2e test where we assert that lambda function can access the data client at runtime. E.g.

[sobolk]

lgtm

[sobolk]

LGTM

[sobolk]

this is not good.

[stocaaro]

You mean the commented code (removed), or is there something about the error thrown validating the api key that isn't good?

[sobolk]

You mean the commented code (removed)

Yes.

[sobolk]

I don't seem to see any code that would call the lambda.
If the feature is about lambda accessing appsync, we should be invoking lambda and asseserting that lambda intracted with appsync.

The test as is doesn't prove that lambda is working.

Some ideas how to test lambda can be found here - we assert that lambda interacts with s3 bucket there, similar strategy can be applied here for appsync.

[stocaaro]

Both of these tests call a query, which each call a lambda and the response assertions are specific to the lambda being called (todoCount and noopImport).

I considered testing the lambda's in isolation (without wiring these calls through AppSync query calls), but that use-case is a simpler subset of the use-cases covered by these tests.

Can you help me understand the coverage gap that needs to be filled?

[sobolk]

I see. There's no coverage gap then.

Can you add JSDoc comment to both private assert... methods explaining that they indeed call the lambda and how ? For the reader it's not obvious that GQL calls translate to lambda invocations here.

[stocaaro]

Understood. JSDoc added