moleculer-api는 MSA 환경에서 마이크로 서비스들의 API 스키마 조각을 수집하고, 무중단으로 통합 API를 업데이트하여 제공하는 웹 서버 컴포넌트입니다.

서비스 API 스키마는 분산 서비스 프로시저의 호출, 또는 중앙 메시징 서비스에 대한 이벤트 발행 및 구독을 응용 프로토콜(REST, GraphQL, WebSocket 등)에 맵핑합니다. 서비스 API 스키마는 JSON 포맷으로 구성되어있으며, 응용 프로토콜 별 API 맵핑과 그에 대한 접근 제어로 구성되어 있습니다.

서비스 API 스키마 예시

Gateway는 특정 서비스 API 스키마의 추가, 제거 및 업데이트시 기존 통합 API 스키마에 병합을 시도하고, 성공시 무중단으로 라우터를 업데이트하며 그 결과를 원격 서비스에 다시 보고합니다.

주요 기능

• 분산 서비스의 API 스키마를 수집하고 병합하여 API를 실시간으로 업데이트

• Polyglot 하거나 서로 다른 서비스 브로커에 기반한 서비스들의 API 스키마를 수집하고 병합 할 수 있음

• 개발 편의 및 충돌 방지를 위한 API 브랜칭 및 버저닝 기능

License

The project is available under the .

1. Install the package

yarn add moleculer-api

npm i --save moleculer-api

Add moleculer-api package from npm.

2. Run the gateway

And write entry script like above. For now, let's skip setting detailed options.

3. Check the log and few endpoints

With default options configuration, A gateway will run on localhost 8080 port with HTTP protocol. And basic placeholder scheme for GraphQL plugin, playground for GraphQL and a default status check endpoint will be set.

• An endpoint to show the status each API integrations. It will show the integration status from oldest version to latest version with detailed integrations belong to each versions by each branches (only master branch initially).

• A playground endpoint which is set from GraphQL Protocol Plugin.

Examples

예시 코드는 ../src/examples를 참고 할 수 있습니다.

2. Access Control Policy

접근 제어 플러그인별 스키마 양식은 Access Control Policy 섹션을 참조하십시오. 이 섹션에서는 기본 플러그인의 구동 방식을 개괄적으로 설명합니다.

프로토콜의 확장성과 접근제어 정책의 정합성을 위해서, 접근 제어 정책은 프로토콜별 엔드포인트가 아니라 액션과 이벤트를 주체로 적용됩니다.

접근 제어 정책의 평가는 API Gateway의 메모리에 LRU 방식으로 캐시되며 한 요청에서 중복 수행되지 않습니다. 캐시 키를 생성 할 때 요청을 정확히 구분하기 위해서 컨텍스트(인증 정보) 및 호출 페이로드 등의 정보가 반영됩니다.

적용되는 플러그인의 순서는 유효합니다. 우선하는 플러그인에서 실패 할 경우 다음 플러그인의 정책은 평가되지 않습니다. 접근 제어 플러그인의 기본 옵션에서 OAuth2 Scope 플러그인(scopes)이 FBAC 플러그인(filter)보다 우선합니다.

A. OAuth2 Scope

OAuth2 Scope 플러그인은 각 정책의 scopes에 나열된 스코프를 context.scopes가 하나 이상의 스코프를 포함하는 경우 접근을 허용합니다.

B. FBAC

FBAC 플러그인은 각 정책의 filter 항목에 맵핑된 Inline JavaScript Function String을 VM에서 실행하고 그 Boolean 값으로 접근 제어 여부를 판단합니다. 평가중 에러가 발생하거나 Boolean 값이 리턴되지 않는 경우, API Gateway에서 출처 노드로 전달되며 접근이 거부됩니다.

디버깅 중에 Inline JavaScript Function String에서 console 객체를 사용해 메세지를 출력하는 경우, 그 메세지는 console 객체에 바인딩된 report 커넥터가 출처 노드로 전달합니다.

Integration Process

병합 규칙은 다음과 같습니다.

• discover

  • discover 발생 즉시 병합 요청이 생성됩니다.

  • 프로토콜 플러그인을 따라 스키마 포맷에 대한 검증을 거칩니다.

    • 포맷 에러는 병합 요청 메세지 리스트에 포함됩니다.

    • 접근 제어를 우회하는 엔드포인트에 대한 경고가 병합 요청 메세지 리스트에 포합됩니다.

  • 검증 성공시 병합 요청이 큐에 삽입되면서 특정 시간(2초를 기본값) 동안 debounce 후 순차적으로 처리됩니다.

    • 큐에서 특정 서비스에 대한 병합 요청이 다수인 경우 마지막 요소만 유효합니다.

    • 프로토콜 플러그인에서 integrationDependencyResolver가 구현된 경우 (eg. GraphQL) 큐 안에서 처리 순서가 조정 될 수 있습니다.

  • 검증 실패시 report 단계로 건너 뜁니다.

• hash

  • 서비스 API 스키마에서 branch, description, deprecated등의 메타 정보를 제외한 스키마 객체 전체를 MD5 해싱하여 고유한 버전 해시를 생성합니다.

• update

  • master 브랜치의 스키마는 경우에는 모든 브랜치에 병합이 시도됩니다.

    • 이 때 master

• report

  • 병합 요청의 메세지 리스트를 기반으로 디버그 메세지를 생성합니다.

  • 병합 요청의 출처 노드로 디버그 메세지를 report합니다.

• Branch Strategy Diagram

  브랜치간 병합 전략을 표로 도식하면 다음과 같습니다.

  표에서 a@v1는 a 서비스 스키마 중 v1 버전을 의미합니다.

Request Lifecycle

1. Extension

Server Extension은 웹 서버를 생성 및 확장하는데 쓰입니다. 서버 생성 옵션을 통해 제어 할 수 있습니다.

http, https, http2 (WIP)

A. REST

REST API 맵핑에는 subscribe를 제외한 call, publish, map 커넥터를 이용 할 수 있습니다.

basePath를 기반으로 이하 REST 엔드포인트가 생성됩니다.

description은 문서 생성시 활용되며 Markdown을 지원합니다 (옵션).

Call

GET /players/1 요청이 player.get 액션을 { id: 1 } 페이로드와 함께 호출하고 성공시 그 결과를 반환합니다.

depreacted는 문서 생성시 활용됩니다 (옵션).

라우트 path를 구성하는 규칙은 를 참고 할 수 있습니다.

GET /players/me 요청이 player.get 액션을 { id: <인증 컨텍스트의 player.id> } 정보로부터 페이로드와 함께 호출하고 성공시 그 결과를 반환합니다.

Map

또는 map 커넥터 (Inline JavaScript Function String)를 통해 인증 컨텍스트의 player 객체를 바로 반환 할 수 있습니다. 이후에 다시 다루는 Inline JavaScript Function String은 API Gateway의 Node.js VM 샌드박스에서 해석됩니다.

Publish

POST /players/1 (body: { message: "blabla" }) 요청은 player.message 이벤트를 { userId: id: <인증 컨텍스트의 player.id>, message: "blabla" } 페이로드와 함께 publish하고 성공시 발송된 페이로드를 응답합니다.

Params

REST API의 params 맵핑에는 @path, @body, @query, @context 객체를 이용 할 수 있습니다.

이하 protocol 항목에 외부에 제공하려는 API를 작성하고 call, publish, subscribe, map 커넥터에 맵핑합니다. 각 커넥터에 대한 추가적인 내용은 아래 섹션에서 다룹니다.

API Schema and Handler

1. Design Principle

Moleculer API Gateway는 아래 원칙을 기반으로 고안되었습니다.

C. WebSocket

    WebSocket: {
      // TODO: WIP
    },

B. GraphQL

GraphQL API 맵핑에는 call, publish, subscribe, map 커넥터를 이용 할 수 있습니다.

TypeDefs

GraphQL 프로토콜에서 typeDefs 속성에 서비스에 필요한 정의(scalar를 제외한 타입, 인터페이스, 열거형 등 모든 형태)을 추가하거나 기존 타입(API Gateway에서 제공하는 기본 타입과 분산 서비스에서 제공한 타입들)을 확장 할 수 있습니다.

Resolvers

이하 리졸버에 각 타입들의 필드를 call, publish, subscribe, map 커넥터에 맵핑합니다.

리졸버가 할당되지 않은 필드들은 source 객체에서 동일한 이름의 속성으로부터 주입됩니다.

Call

GraphQL API의 Query 및 Mutation 타입의 필드들에는 publish 및 call 또는 map 커넥터를 이용 할 수 있습니다. params 맵핑에는 @source, @args, @context, @info를 이용 할 수 있습니다.

Map

GraphQL 프로토콜에서 map 커넥터 (Inline JavaScript Function String)는 간략하게 field: { map: <FN_STRING> } 대신에 field: <FN_STRING> 방식으로 작성 할 수 있습니다.

위처럼 Union, Interface 구현 타입을 해석하기 위한 특수 필드에도 Inline JavaScript Function String를 사용합니다.

Batched Call (DataLoader)

위처럼 인증 정보를 포함한 @context나 GraphQL 필드 인자인 @args를 활용해 동일한 액션을 서로 다른 방식으로 맵핑 할 수 있습니다.

또한 call 메소드는 GraphQL 요청에서 발생하기 쉬운 N+1 쿼리를 방지하기 위해 요청을 배치로 처리 할 수 있도록 설계되었습니다. (ref. )

한 컨텍스트에서 여러번 호출되는 액션에 배칭을 지원하면 응답 속도를 획기적으로 높힐 수 있습니다. 배칭을 활성화하기 위해서는 call 커넥터의 batchedParams 필드에 배치 처리가 가능한 필드의 이름을 작성하고, 연결된 서비스 액션이 배열로 들어오는 인자 묶음을 처리 할 수 있도록 합니다.

위와 같은 GraphQL 요청은 player.get 액션을 { id: [context.user.player.id, 1, 2, 3], ...(other common params) } 페이로드와 함께 한번만 호출하게 됩니다. 연결된 액션이 [{ ... }, { ... }, { ... }, { ... }] 묶음으로 응답을 주면 각 필드에 해당하는 응답이 할당됩니다.

만약 id: 3인 플레이어가 없는 경우 배치 요청을 처리하는 과정에서 에러를 발생시켜 제어 흐름을 멈추는 대신에, 에러를 발생키지않고 배치 응답에 포함시키고 나머지 제어 흐름을 마무리합니다. [{ ... }, { ... }, { ... }, { message: "...", isBatchError: true, ... }] 처럼 isBatchError: true 속성을 갖는 에러 객체를 응답에 포함합니다.

Subscribe

GraphQL API의 Subscription 타입의 필드에서는 subscribe 커넥터를 사용 할 수 있습니다. params 맵핑에는 마찬가지로 @source, @args, @context, @info를 이용 할 수 있습니다. @source에 이벤트 객체가 맵핑됩니다.

@source 객체는 { event, payload }로 구성됩니다. Broker에 따라 기타 속성이 추가 될 수 있습니다.

subscribe 커넥터에서는 위처럼 수신된 이벤트 페이로드를 다시 map 커넥터로 변환 할 수 있습니다. subscribe 커넥터 안에서 map 커넥터가 사용되지 않는 경우 이벤트 객체 전체(source)를 반환합니다.

Filter

        filter: `({ action, params, context, util }) => {
          if (action === "player.remove") {
            return context.user.player.isAdmin && context.user.player.id != params.id;
          } else if (action === "player.create") {
            return context.user && (!context.user.player || context.user.player.isAdmin); 
          }
          return true;
        }`,
      },

다음으로 filter 접근 제어 플러그인에 따라 action|event, params, context, util을 주입하여 함수를 실행하며, true 값이 반환되는 경우 통과합니다. FBAC은 ACL이나 RBAC처럼 대중화되지는 않았으나, ABAC의 확장 모델로 이해할 수 있습니다. 매우 유연하여 분산 환경에 적합하며 프로덕션에서 검증된 방식입니다.

filter 접근제어 플러그인 역시 map 커넥터처럼 Gateway의 Node.js VM 샌드박스에서 실행됩니다. filter 함수를 평가하는 중에 에러가 발생하는 경우 디버그 메시지가 Gateway에서 출처 노드로 전달되며 접근이 거부됩니다.

위처럼 player 서비스의 API 스키마는 꼭 player 서비스의 액션만 호출하지 않습니다. 따라서 player API에서 노출하는 team 서비스의 액션에 대한 접근 제어 역시 player 스키마에서 정의하게 됩니다.

publish, subscribe 커넥터의 정책에는 actions 대신 events 필드가 작성됩니다.

위처럼 filter가 생략된 경우 scopes만 적용되며 filter는 통과한 것처럼 평가됩니다.

접근제어 플러그인을 비활성화하는 것은 위 정책을 작성하는 것과 동일합니다.

디버깅 중에 Inline JavaScript Function String에서 console 객체를 사용해 메세지를 출력하는 경우, 그 메세지는 Gateway의 VM 안에서 출력되지 않고 Gateway가 출처 노드로 전달합니다.

Scopes

    call: [
      {
        description: "admin can remove player, newbie and admin can create player",
        actions: ["player.**"],
        scopes: ["player", "player.admin"],

위 정책은 player.** 패턴(player.get, player.list, player.message.list 등과 일치)의 액션을 호출하는 call 커넥터가 사용되는 모든 엔드포인트가 수행되기 전에 공통적으로 평가됩니다. 우선 scopes 접근 제어 플러그인에 따라 context에 주입된 (moleculer-iam 같은 컨텍스트 플러그인을 통해) OAuth 토큰이 획득한 스코프를 확인하고 일치되는 스코프가 하나라도 있는 경우 통과합니다.

• 0.1.x Pre-alpha

  • Service Broker

    • Service Registry which can discover and distinguish equally named but different services

    • Collect action params and response, subscribed events examples

    • Delegate action call with Dataloader batching support

    • Delegate event publishing

    • Delegate event subscription with either handler or async iterator

    • Delegate health check

    • Reporter which reports errors and information to origin services

    • Inline function parser (VM)

    • Explicit/implicit parameters mapping from service action validation schema

    • Support multiple Service Broker for a single gateway

    • MoleculerJS Delegator

  • Schema Registry

    • Validate service API schema and report

    • Integrations compile and major plugins

  • Logger

    • Winston: also can be used with MoleculerJS delegator logger

  • API Server

    • Branch, Version specific routes while reusing handlers

    • HTTP, WebSocket components (express, ws modules)

• 0.2.x Alpha

  • Middleware

  • Helmet (disabled by default)

• 0.3.x Beta

  • Integration example with moleculer-iam (OIDC provider)

  • Schema Registry plugins
• [] 1.0.x First Stable release

  • API Server additional protocols

    • HTTPS

1. MoleculerJS

MoleculerJS 어댑터로 API Gateway 함께와 아래의 피어 모듈을 활용 할 수 있습니다.

• moleculer-iam - OIDC 및 Identity Provider를 제공하는 IAM 모듈, 인증 컨텍스트에 연동 가능

• - 파일 업로드/다운로드/관리 모듈 (GCP Storage bucket backend / File System backend 지원)

• - 국제화 데이터베이스 관리 및 조회 모듈 (MySQL/Maria DBMS 필요)

• - 확장 가능한 Admin Console WebApp (React.js)

  • API document component 기본 제공 ( 호환)

  • IAM component 기본 제공 ( 호환)

Service Brokers

API Gateway는 최초에 Moleculer MSA 라이브러리를 배경으로 개발되었지만, 확장성을 위해서 강한 디커플링을 방침으로 개발되고 있습니다.

API Gateway는 분산 서비스 및 중앙 메시징 서비스와의 네트워킹을 서비스 브로커에게 위임합니다. 서비스 브로커는 분산 서비스들의 네트워킹을 위임 받으며, call, publish, subscribe, discover, report 등의 주요 네트워킹 인터페이스(커넥터)를 가진 어댑터와 결합됩니다.

Service Broker

서비스 브로커는 분산 서비스들의 네트워킹을 위임 받으며, call, publish, subscribe, discover, report 등의 주요 네트워킹 인터페이스(커넥터)를 가진 어댑터와 결합됩니다.

2. Delegator

브로커는 위 커넥터들의 특정 인터페이스를 구현하는 단일한 객체로 구현됩니다.

A. Moleculer

• MoleculerAPIGateway 서비스를 minxin에 포함해 moleculer.ServiceSchema를 확장 할 수 있습니다.

• MoleculerServiceBroker를 이용해 직접 moleculer.ServiceSchema를 구현 할 수 있습니다.

B. Others

기타 MSA 라이브러리를 응용해 ServiceBroker 인터페이스를 구현 할 수 있습니다.

1. APIGatewayOptions

APIGatewayOptions type is a kind of container for all the subordinate components' options.

1.1. APIGatewayOwnOptions

Options for the gateway itself rather inner components.

2. ServiceBrokerOptions

Service Broker options are consist of common properties and delegator specific properties. The common properties show below.

2.1. ServiceRegistryOptions

2.2. BatchingPoolOptions

2.3. InlineFunctionOptions

2.4. ReporterOptions

2.5. ServiceBrokerDelegatorConstructorOptions

Specific options for the Service Broker Delegator. Can choose only one among supported delegators. Currently delegator is supported.

2.5.1. MoleculerServiceBrokerDelegatorOptions

delegator can be configured with moleculer broker own options and few extra options like below.

3. SchemaRegistryOptions

Service Registry options are consist of own options for the registry itself and Protocol, Policy, this two type of Plugin constructor options.

3.1. ProtocolPluginConstructorOptions

A ProtocolPlugin handles mapping Public API to calling internal services' procedure, publishing and subscribing event messages.

WIP

3.2. PolicyPluginConstructorOptions

A PolicyPlugin handles access controls (authorization) while calling internal services' procedure, publishing and subscribing event messages.

WIP

4. APIServerOptions

WIP

5. LoggerConstructorOptions

WIP

1. Connectors

A. Context Connectors

요청 상태를 기반으로 API 요청에 활용되는 커넥터입니다. 접근 제어 및 stateless 커넥터를 연계 할 수 있습니다.

GraphQL의 Subscription 타입이나 WebSocket 프로토콜 등을 사용하지 않거나, 분산 시스템에 중앙 메시징 서비스를 제공 할 수 없는 경우엔 publish, subscribe 커넥터를 구현하지 않아도 무관합니다.

B. Stateless Connectors

요청 상태가 없는 커넥터입니다.

Plugin

플러그인은 서비스 API 스키마의 포맷과 기능을 확장하는데 쓰입니다. 플러그인은 위임된 스키마에 대한 검증, 해석, 작동 방식을 정의하고 구현합니다.

각 프로토콜 플러그인은 해당 프로토콜 스키마의 양식을 정의하고, 스키마 병합, 요청 프록시, 의존성 파악, 서버 확장 핸들러 등을 구현합니다.

각 접근 제어 플러그인은 해당 접근 제어 스키마의 양식을 정의하고, call, publish, subscribe 커넥터의 정책을 해석하고 접근 제어를 판단하는 핸들러를 구현합니다.

1. Protocol Plugin

프토토콜 플러그인별 스키마 양식은 섹션을 참조하십시오. 이 섹션에서는 기본 플러그인의 구동 방식을 개괄적으로 설명합니다.

A. REST

REST 프로토콜은 분산 서비스에 대한 call, publish 커넥터를 특정 엔드포인트에 맵핑합니다. HTTP 요청의 Paylo,ad는 미들웨어를 통해 파싱되어 params 커넥터를 통해 변환되어 call, publish 커넥터로 전달됩니다.

엔드포인트가 중복되는 경우 병합을 발생시킨 출처 노드로 디버그 메세지가 report되며 병합에 실패합니다.

API Catalog를 통해서 엔드포인트 별 적용된 정책 및 커넥터와 그 파라미터에 대한 설명을 제공합니다.

TODO: $headers, $status, $body field for REST response

B. GraphQL

GraphQL 프로토콜은 분산 서비스에 대한 call 및 publish, subscribe 커넥터를 특정 타입의 필드에 맵핑합니다. HTTP 요청의 Payload는 미들웨어를 통해 파싱되어 params 커넥터를 통해 변환되어 call, publish, subscribe, map 커넥터로 전달됩니다.

GraphQL 스키마 생성에 실패하는 경우 병합을 발생시킨 출처 노드로 디버그 메세지가 report되며 병합에 실패합니다.

API Catalog를 통해서 각 GraphQL Type 별 적용된 정책 및 커넥터와 그 파라미터에 대한 설명을 제공합니다.

서비스 API 스키마를 통해서 GraphQL Custom Scalar 정의를 추가 할 수 없습니다. Gateway 생성시 플러그인 옵션을 통해 Scalar 정의를 추가하거나 오버라이드 할 수 있습니다. 기본적으로 DateTime, Date, Time, JSON가 포함되어있습니다.

C. WebSocket

TODO: WIP

B. API Handler

Dynamic Handler

동적 핸들러는 웹 서버의 모든 base 경로를 관리하며, 미들웨어 및 플러그인, 엔드포인트 간의 경로 충돌을 방지합니다. 동적 핸들러는 조건에 따라 브랜치 핸들러 및 버전 핸들러를 생성 및 삭제하며 동적으로 라우트 테이블을 구성합니다.

동적 핸들러는 클라이언트의 요청에 따라 미들웨어를 수행하고, 브랜치 핸들러로 요청을 프록시합니다.

C. Reflection

API Gateway Health Check

Gateway 웹서버 자체의 상태 확인용 HTTP 엔드포인트를 내장하고 있습니다. 로드밸런서나 Kubernetes 등의 컨테이너 오케스트레이션 환경에서 활용 할 수 있습니다.

A. Schema Integration

서비스 API 스키마는 서비스 브로커에 의존해 Gateway로 수집되고 처리됩니다. Moleculer 어댑터로 작성된 서비스 브로커의 경우 기본적으로 ServiceSchema의 metadata.api 필드에서 서비스 API 스키마가 수집되기를 기대합니다.

서비스 API 스키마의 병합은 서비스 노드의 연결, 종료, 스키마 변경시 발생합니다. 서비스 API 스키마는 자신의 스키마를 병합 할 브랜치를 스키마에 명시합니다. Gateway에는 기본적으로

제거 할 수 없는 기본 브랜치는 master 브랜치입니다. 이외의 브랜치를 명시하여 브랜치를 생성하거나 업데이트 할 수 있습니다. 브랜치 관련 내용은 아래에서 다시 다룹니다.

Load-Balancing

동적으로 스키마를 수집하고 API를 업데이트하는 Gateway는 동일한 서비스 인스턴스가 분산 시스템에 여러개 존재할 때 문제를 드러냅니다.

예시

• player 서비스가 A, B 두 호스트에서 분산 시스템에 연결되어 디버깅되고 있다면, Gateway는 player 서비스 API 스키마를 A 호스트의 스키마, B 호스트의 스키마에 따라 빈번하게 변경하게 되어 원격지의 두 개발자는 디버깅에 문제를 겪습니다.

  • 해결 방법은 로컬에 전용 게이트웨이를 직접 실행하고 분산 시스템과의 연결(eg. VPN 터널)을 종료하는 방법입니다.

• player 서비스의 get 액션의 파라미터 및 응답 스펙이 A 호스트에서 디버깅 중인 경우, 클라이언트의 요청이 분산 시스템에 기존에 배포된 X 노드의 player 서비스의 get 액션으로 프록시되는 경우도 역시 문제가 됩니다.

  • 해결 방법으로 로드밸런싱의 우선 순위를 자신의 호스트로 강제하는 기능을 요청시 클라이언트 IP나 파라미터를 이용해 구현하는 방법이 있습니다. 이 방법은 이전 버전의 Gateway에서 시도되었으나 만족스럽지 않았습니다.

위의 여러 전략을 실험해본 후 Gateway는 브랜치 및 태그을 통해 개발시 충돌 회피를 지원하고, 추가로 브랜치별 로드밸런싱 정책을 적용합니다.

• call

  • master 브랜치에서는 API 엔드포인트에 연결된 서비스 액션을 호출 할 때 master,(none) 브랜치에 API를 제공한 서비스 노드를 우선으로 요청을 프록시합니다.

Development

1. Yarn Scripts

• yarn dev [example=simple] - Start development (nodemon with ts-node)

• yarn build- Uses typescript to transpile service to javascript

• yarn lint - Run TSLint

• yarn test - Run tests & generate coverage report

• yarn test --watch - Watch and run tests

Contribution

Please send pull requests improving the usage and fixing bugs, improving documentation and providing better examples, or providing some testing, because these things are important.

1. Streaming Request

Handling streaming request is up to delegator. To support streaming request, delegator should handle { createReadStream(): ReadableStream, ...meta: any } params as their own way.

1.1. REST file upload example

When multipart/form-data request with 'file' field is mapped to above REST API schema. REST protocol plugin will delegate action call with params as below.

1.2. GraphQL file upload example

When is mapped to above GraphQL API schema. GraphQL protocol plugin will delegate action call with params as below.

For WebSocket protocol, see 4.

2. Streaming Response

Handling streaming response is up to protocol plugins. For REST protocol, any response from delegator like below will be handled as stream response with { "Content-Type": "application/octet-stream", "Transfer-Encoding": "chunked" } headers.

For GraphQL protocol, above features just ignored.

For WebSocket protocol, see 4.

3. Modify Response Header/Status

Also for REST protocol, can modify response with $headers, status properties in delegator response.

It is not only for the streaming response. below delegator response will also modify response headers.

For GraphQL protocol, this feature is just ignored. For WebSocket protocol, this feature is just ignored.

4. Bidirectional Streaming

WebSocket protocol supports bidirectional streaming. // TODO: documentation

D. Access Control Policy

위에 정의한 각 프로토콜들의 엔드포인트는 서비스 브로커의 call, publish, subscribe 커넥터를 호출합니다. 이 때 호출되는 각 커넥터들에 대해서 접근 제어 정책을 정의 할 수 있습니다.

접근 제어 정책은 먼저 호출하는 커넥터에 따라서 action

QMIT Inc.

A company which analyzes data of sports players to help recovery, training.

Maintainers

Contributors

Nobody yet

0.3.2 - 2020-12-13

Added

• Created gitbook documentation:

What is the difference compared to '' project?

WIP...