해석기

이전 섹션에서 스키마와 데이터 원본의 구성 요소에 대해 알아보았습니다. 이제 스키마와 데이터 원본이 상호 작용하는 방식을 알아보겠습니다. 모든 작업은 해석기에서 시작됩니다.

해석기는 서비스에 요청이 들어왔을 때 해당 필드의 데이터가 해석되는 방식을 처리하는 코드 단위입니다. 해석기는 스키마의 유형 내 특정 필드에 연결됩니다. 쿼리, 변형 및 구독 필드 작업의 상태 변경 작업을 구현하는 데 가장 일반적으로 사용됩니다. 해석기는 클라이언트의 요청을 처리한 다음 결과를 반환하며, 결과는 객체 또는 스칼라와 같은 출력 유형 그룹일 수 있습니다.

해석기 런타임

AWS AppSync에서는 먼저 리졸버의 런타임을 지정해야 합니다. 해석기 런타임은 해석기가 실행되는 환경을 나타냅니다. 또한 리졸버를 작성할 때 사용할 언어도 지정됩니다. AWS AppSync 현재 APPSYNC _JS for JavaScript 및 Velocity 템플릿 언어 () 를 지원합니다. VTL 리졸버의 JavaScript 런타임 기능 및 함수 JavaScript 또는 Resolver 매핑 템플릿 유틸리티 참조를 참조하십시오. VTL

해석기 구조

코드와 관련해서는 해석기를 몇 가지 방식으로 구성할 수 있습니다. 단위 해석기와 파이프라인 해석기가 있습니다.

단위 해석기

단위 해석기는 데이터 원본에 대해 실행되는 단일 요청 및 응답 핸들러를 정의하는 코드로 구성됩니다. 요청 핸들러는 컨텍스트 객체를 인수로 사용하고 데이터 원본을 호출하는 데 사용된 요청 페이로드를 반환합니다. 응답 핸들러는 실행된 요청의 결과와 함께 데이터 원본으로부터 페이로드를 다시 받습니다. 응답 핸들러는 페이로드를 GraphQL 응답으로 변환하여 GraphQL 필드를 해석합니다.

파이프라인 해석기

파이프라인 해석기를 구현할 때는 다음과 같은 일반적인 구조를 따릅니다.

• 사전 단계: 클라이언트가 요청을 보내면 사용 중인 스키마 필드(일반적으로 쿼리, 변형, 구독)의 해석기에 요청 데이터가 전달됩니다. 해석기는 데이터가 해석기를 통해 이동하기 전에 일부 사전 처리 작업을 수행할 수 있는 사전 단계 핸들러를 사용하여 요청 데이터 처리를 시작합니다.

• 함수: 사전 단계가 실행되면 요청이 함수 목록으로 전달됩니다. 목록의 첫 번째 함수는 데이터 원본에 대해 실행됩니다. 함수는 자체 요청 및 응답 핸들러를 포함하는 해석기 코드의 하위 집합입니다. 요청 핸들러는 요청 데이터를 가져와 데이터 원본에 대해 작업을 수행합니다. 응답 핸들러는 데이터 원본의 응답을 다시 목록으로 전달하기 전에 해당 데이터 원본의 응답을 처리합니다. 함수가 두 개 이상인 경우 요청 데이터는 목록의 다음 함수로 전송되어 실행됩니다. 목록에 있는 함수는 개발자가 정의한 순서대로 순차적으로 실행됩니다. 모든 함수가 실행되면 최종 결과가 사후 단계로 전달됩니다.

• 사후 단계: 사후 단계는 GraphQL 응답으로 전달하기 전에 최종 함수의 응답에 대한 몇 가지 최종 작업을 수행할 수 있는 핸들러 함수입니다.

해석기 핸들러 구조

핸들러는 일반적으로 Request 및 Response라는 함수입니다.

export function request(ctx) {
    // Code goes here
}

export function response(ctx) {
    // Code goes here
}

단위 해석기에는 이러한 함수 집합이 하나뿐입니다. 파이프라인 해석기에는 사전 단계와 사후 단계를 위한 이러한 함수 집합이 있고 함수별로 추가 집합이 있습니다. 시각적으로 확인해 볼 수 있도록 간단한 Query 유형을 살펴보겠습니다.

type Query {
	helloWorld: String!
}

이 쿼리는 유형 String의 helloWorld라는 필드 하나가 있는 간단한 쿼리입니다. 이 필드가 항상 'Hello World'라는 문자열을 반환하게 한다고 가정해 보겠습니다. 이 동작을 구현하려면 이 필드에 해석기를 추가해야 합니다. 단위 해석기에서는 다음과 같이 추가할 수 있습니다.

export function request(ctx) {
    return {}
}

export function response(ctx) {
    return "Hello World"
}

데이터를 요청하거나 처리하지 않기 때문에 request는 비워 두어도 됩니다. 또한 데이터 원본이 None이라고 가정할 수도 있는데, 이 코드를 간접 호출할 필요가 없다는 뜻입니다. 응답은 단순히 'Hello World'를 반환합니다. 이 해석기를 테스트하려면 다음 쿼리 유형을 사용하여 요청해야 합니다.

query helloWorldTest {
  helloWorld
}

이 쿼리는 helloWorld 필드를 반환하는 helloWorldTest라는 쿼리입니다. helloWorld 필드 해석기는 또한 실행 시 다음 응답을 실행하고 반환합니다.

{
  "data": {
    "helloWorld": "Hello World"
  }
}

이와 같은 상수를 반환하는 작업은 가장 간단하게 할 수 있는 작업입니다. 실제로는 입력, 목록 등을 반환하게 됩니다. 더 복잡한 예는 다음과 같습니다.

type Book {
  id: ID!
  title: String
}

type Query {
  getBooks: [Book]
}

여기서는 Books의 목록을 반환합니다. DynamoDB 테이블을 사용하여 책 데이터를 저장한다고 가정해 보겠습니다. 핸들러는 다음과 같을 수 있습니다.

/**
 * Performs a scan on the dynamodb data source
 */
export function request(ctx) {
  return { operation: 'Scan' };
}

/**
 * return a list of scanned post items
 */
export function response(ctx) {
  return ctx.result.items;
}

요청은 내장된 스캔 작업을 사용하여 테이블의 모든 항목을 검색하고 결과를 컨텍스트에 저장한 다음 응답으로 전달했습니다. 응답은 결과 항목을 가져와 응답에 반환했습니다.

{
  "data": {
    "getBooks": {
      "items": [
        {
          "id": "abcdefgh-1234-1234-1234-abcdefghijkl",
          "title": "book1"
        },
        {
          "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
          "title": "book2"
        },

        ...

      ]
    }
  }
}

해석기 컨텍스트

해석기에서 핸들러 체인의 각 단계에서는 이전 단계의 데이터 상태를 알고 있어야 합니다. 한 핸들러의 결과를 저장하고 다른 핸들러에 인수로 전달할 수 있습니다. GraphQL은 네 가지 기본 해석기 인수를 정의합니다.

해석기 기본 인수	설명
obj, root, parent 등.	상위 항목의 결과입니다.
args	GraphQL 쿼리의 필드에 제공된 인수입니다.
context	모든 해석기에 제공되며 현재 로그인한 사용자 또는 데이터베이스 액세스와 같은 중요한 컨텍스트 정보를 보유하는 값입니다.
info	현재 쿼리와 관련된 필드별 정보와 스키마 세부 정보를 포함하는 값입니다.

에서 AWS AppSynccontext (ctx) 인수는 위에서 언급한 모든 데이터를 포함할 수 있습니다. 요청별로 생성되는 객체이며 권한 부여 보안 인증, 결과 데이터, 오류, 요청 메타데이터 등과 같은 데이터를 포함합니다. 컨텍스트는 프로그래머가 요청의 다른 부분에서 오는 데이터를 조작할 수 있는 간단한 방법입니다. 이 스니펫을 다시 살펴보세요.

/**
 * Performs a scan on the dynamodb data source
 */
export function request(ctx) {
  return { operation: 'Scan' };
}

/**
 * return a list of scanned post items
 */
export function response(ctx) {
  return ctx.result.items;
}

요청에는 컨텍스트(ctx)가 인수로 제공되는데, 이는 요청의 상태입니다. 테이블의 모든 항목을 스캔한 다음 result의 컨텍스트에 결과를 다시 저장합니다. 그러면 컨텍스트가 응답 인수로 전달되고, 응답 인수는 result에 액세스하여 내용을 반환합니다.

요청 및 구문 분석

GraphQL 서비스에 쿼리를 생성하는 경우 먼저 구문 분석 및 검증 프로세스를 거친 후 실행해야 합니다. 요청이 구문 분석되고 추상 구문 트리로 번역됩니다. 스키마에 대해 여러 검증 알고리즘을 실행하여 트리의 내용을 검증합니다. 검증 단계가 완료되면 트리의 노드를 순회하여 처리합니다. 해석기가 간접적으로 호출되고, 결과가 컨텍스트에 저장되며, 응답이 반환됩니다. 다음 쿼리를 예로 들어 보겠습니다.

query {
  Person {  //object type
    name  //scalar
    age   //scalar
  } 
}

name 및 age 필드와 함께 Person이 반환됩니다. 이 쿼리를 실행하면 다음과 같은 트리가 나옵니다.

트리에서 보면 이 요청이 스키마의 루트에서 Query를 검색하는 것으로 보입니다. 쿼리 내에서 Person 필드가 해석됩니다. 이전 예제를 보면 사용자의 입력, 값 목록 등일 수 있습니다. Person은 필요한 필드(name 및 age)를 보유하는 객체 유형과 연결되어 있을 가능성이 높습니다. 이 두 개의 하위 필드를 찾으면 주어진 순서대로(name 다음 age) 해석됩니다. 트리가 완전히 해석되면 요청이 완료되고 클라이언트에게 다시 전송됩니다.