@things-factory/scheduler 7.1.34

package/helps/scheduler/scheduler.ko.md

@@ -0,0 +1,185 @@
+# 스케줄러 서비스
+
+- Scheduler에 등록되는 모든 이벤트들은 cron을 포함한 여러 형태의 스케줄 타입 및 값이 지정
+- 사용자가 지정한 스케줄 형태에 따라서 이벤트가 호출되며, 일반적으로 호출된 이벤트는 사용자가 등록 시에 지정한 rest api를 호출
+- 호출된 이벤트가 실패할 경우 정책에 따라서 일정 시간 이후 재시도 수행
+- 스케줄러 처리의 부하를 분산하기 위해서 새롭게 설계된 구조로서 스케줄러는 데이터베이스 기반의 큐 구조를 사용하여 모든 스케줄 데이터를 관리
+
+### 스케줄러의 주기적 처리에 대한 Diagram
+
+![Periodic Scheduler Diagram](./assets/updated-scheduler-diagram-periodic.png 'Periodic Scheduler Diagram')
+
+- 구조가 간결하고 추가적인 다른 서비스 없이 운용 가능하다는 점이 장점
+- 각 인스턴스가 휴지 기간 없이 주기적으로 깨어나서 데이터베이스 내에 스케줄 큐를 확인해야 한다는 점이 단점.
+
+### (대안) 스케줄러의 깨어나는 시점을 또다른 모니터링 인스턴스가 주기적으로 확인해서 모든 스케줄러에게 Publish하는 구조
+
+![Pubsub Scheduler Diagram](./assets/updated-scheduler-diagram-pubsub.png 'Pubsub Scheduler Diagram')
+
+- 모든 인스턴스는 모니터링 인스턴스를 통해서 받는 다음 스케줄의 타임스탬프 정보에 의해서 스케줄 처리를 수행.
+- 추가적인 서비스(redis) 필요하며, 개별 인스턴스는 지속적으로 다음 스케줄에 대한 정보를 가지고 있어야 함.
+
+## MSA 기반의 스케줄러 서비스
+
+![MSA Scheduler Service](./assets/scheduler-service-msa.png 'MSA Scheduler Service')
+
+- 기존의 어플리케이션 구조에서 스케줄링 잡을 처리하는 스케줄러 서비스가 클라우드 기반의 수평 스케일링 구조에서 기능 수행이 불가능.
+- 별도의 스케줄러 서비스가 필요. 이러한 스케줄 작업을 수행하는 서비스는 다수 존재하지만 스케줄러 역할만을 수행하는 분리된 서비스가 없음.
+- 클라우드 환경에서 사용 가능한 수평적인 확장이 가능한 서비스 개발이 필요.
+
+## 서비스 개요
+
+![Scalable Scheduler Service](./assets/scheduler-service-scalable.png 'Scalable Scheduler Service')
+
+- 스케줄러 서비스는 Restful 기반의 수평 확장이 가능한 스케줄러 서비스.
+- MSA 기반의 어플리케이션 환경에서 기존 어플리케이션이 수행하는 스케줄링 모듈에 대해서, 별도의 스케줄링 서비스를 분리해서 제공하는 서비스를 제공합니다.
+
+## 사용 가능한 용도
+
+- 크론(cron) 기반의 스케줄잡(Schedule Job) 핸들러
+- 특정한 날짜 혹은 특정한 주기로 실행되는 태스크 실행 엔진
+- 특정한 이벤트를 등록 관리하고, 이벤트를 기반으로 특정 기능을 실행하거나 데이터를 전달하는 브로커
+
+### Schedule
+
+#### Format
+
+스케줄을 등록하기 위한 포맷의 예는 다음과 같습니다.
+
+```json
+{
+  "name": "bbb",
+  "client": {
+    "operation": "op#1",
+    "application": "chef",
+    "group": "system",
+    "key": "12345678",
+    "type": "scheduler"
+  },
+  "type": "cron",
+  "schedule": "30 * * * * *",
+  "timezone": "Asia/Seoul",
+  "task": {
+    "type": "rest",
+    "connection": {
+      "host": "http://localhost:3000/api/unstable/run-scenario/DELAY-TEST-9",
+      "headers": { "Content-Type": "application/json", "accept": "*/*", "Authorization": "Bearer ..." }
+    },
+    "data": { "instanceName": "delay-test-999", "variables": {} },
+    "history_check": false,
+    "failed_policy": "retry",
+    "retry_wait": 60
+  }
+}
+```
+
+- name: 스케줄의 이름
+- client: 클라이언트 정보를 표현합니다. 실제 스케줄은 5개의 요소가 모두 일치할 때 동일한 스케줄로 인식
+  - operation: 공정과 같은 별도의 스케줄 용도를 표현
+  - application: 클라이언트 어플리케이션 이름
+  - group: 도메인 정보
+  - key: 스케줄 구분을 위한 별도의 키
+  - 타입: 해당 스케줄 자체에 대한 리소스 타입
+- type: 스케줄 타입으로서 크게, cron, now, date, delay, delay-recur으로 구성됩니다. 자세한 설명은 다음 항목을 참조
+- schedule: 스케줄 타입에 따라 별도의 문자열이 지정됩니다. 자세한 설명은 아래 'Scheduler Type'을 참조.
+- timezone: 스케줄 처리를 위한 타임존 문자열(예. Asiz/Seoul)을 지정.
+- task: 해당 스케줄이 처리되어야할 때 필요한 태스크 정보를 포함.
+  - type: 태스크의 타입으로서, 크게 rest, kafka, redis 중 하나를 지정. rest의 경우 post만 지원합니다.
+  - connection: 해당 태스크가 수행되기 위한 연결 정보
+    - host: 서버 연결 정보
+    - topic: kafka와 redis 타입일 때 지정.
+    - headers: rest 타입일 경우 선택적으로 지정.
+  - data: 해당 태스크 수행 시 전달되어야 하는데이터를 지정
+  - history_check: 스케줄의 등록, 실행, 삭제, 재실행에 대한 히스토리를 별도의 DB에 저장.
+
+### Schedule Type
+
+- delay: 특정한 시간(초) 동안 대기 후에 스케줄을 실행합니다.
+
+  ```json
+  {
+    ...
+    "type": "delay",
+    "schedule": "50",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- delay-recur: 특정 시간(초) 동안 대기 후에 실행되는 스케줄을 반복 합니다.
+
+  ```json
+  {
+    ...
+    "type": "delay-recur",
+    "schedule": "50",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- cron: cron format을 기반으로 스케줄이 동작합니다.
+
+  - 기본적인 5개 포맷을 사용합니다.
+  - 초 단위 스케줄리을 실행하기 위해서는 6개 시간 요소가 필요하면, 첫번째 요소가 초를 지정합니다.
+
+  ```json
+  {
+    ...
+    "type": "cron",
+    "schedule": "0 * * * *",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- date: 특정한 일자 및 시간을 지정.(ISO 포맷, YYYY-MM-DDThh:mm:ss)
+
+  ```json
+  {
+    ...
+    "type": "date",
+    "schedule": "2023-04-05T12:30:00",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- now: 바로 지금 해당 스케줄을 실행
+  ```json
+  {
+    ...
+    "type": "now",
+    "schedule": "",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+### Task Type
+
+- Rest
+
+  ```json
+  {
+    ...
+    "task": {
+      "type": "rest",
+      "connection": {"host": "http://localhost:3000/api/unstable/run-scenario/test-scenario-1", "headers": {"Content-Type": "application/json", "accept": "*/*"}},
+      "data": {"instanceName": "test-scenario-1", "variables": {}}
+    }
+  }
+  ```
+
+- Kafka & Redis
+
+  ```json
+  {
+    ...
+    "task": {
+      "type": "kafka",
+      "connection": {"host": "localhost:9092", "topic": "example-topic"},
+      "data": { ... }
+    }
+  }
+  ```

package/helps/scheduler/scheduler.md

@@ -0,0 +1,186 @@
+# Scheduler Service
+
+- All events registered in the Scheduler are specified with various schedule types and values, including cron.
+- Events are invoked based on the schedule type specified by the user, and typically, the invoked event calls the REST API designated during registration.
+- If an invoked event fails, it retries after a certain period, as defined by the policy.
+- To distribute the load of scheduler processing, a newly designed structure uses a database-based queue to manage all schedule data.
+
+### Diagram for Periodic Processing in the Scheduler
+
+![Periodic Scheduler Diagram](./assets/updated-scheduler-diagram-periodic.png 'Periodic Scheduler Diagram')
+
+- **Advantages**: The structure is simple and can be operated without additional services.
+- **Disadvantages**: Each instance must periodically wake up and check the schedule queue in the database without any idle period.
+
+### Alternative: Structure Where a Monitoring Instance Publishes Wake-Up Times to All Schedulers
+
+![Pubsub Scheduler Diagram](./assets/updated-scheduler-diagram-pubsub.png 'Pubsub Scheduler Diagram')
+
+- All instances process schedules based on the next schedule timestamp information received from a monitoring instance.
+- **Requirements**: Additional services (e.g., Redis) are necessary, and each instance must continuously hold information about the next schedule.
+
+## Scheduler Service in MSA
+
+![MSA Scheduler Service](./assets/scheduler-service-msa.png 'MSA Scheduler Service')
+
+- The traditional application structure for processing scheduling jobs cannot function in a cloud-based horizontal scaling architecture.
+- A separate scheduler service is needed. While there are many services for such tasks, there isn’t a dedicated service solely for the role of scheduling.
+- A scalable service that can be horizontally expanded in a cloud environment is required.
+
+## Service Overview
+
+![Scalable Scheduler Service](./assets/scheduler-service-scalable.png 'Scalable Scheduler Service')
+
+- Scheduler service is a horizontally scalable scheduling service based on RESTful architecture.
+- It provides a service that separates scheduling modules from existing applications in MSA-based environments.
+
+## Usable Scenarios
+
+- **Cron-Based Schedule Job Handlers**: For processing tasks at specific intervals.
+- **Task Execution Engines**: For executing tasks on specific dates or at specific intervals.
+- **Event-Driven Task Handlers**: For registering and managing events, and executing specific tasks or transferring data based on those events.
+
+### Schedule
+
+#### Format
+
+An example of the format for registering a schedule is as follows:
+
+```json
+{
+  "name": "bbb",
+  "client": {
+    "operation": "op#1",
+    "application": "chef",
+    "group": "system",
+    "key": "12345678",
+    "type": "scheduler"
+  },
+  "type": "cron",
+  "schedule": "30 * * * * *",
+  "timezone": "Asia/Seoul",
+  "task": {
+    "type": "rest",
+    "connection": {
+      "host": "http://localhost:3000/api/unstable/run-scenario/DELAY-TEST-9",
+      "headers": { "Content-Type": "application/json", "accept": "*/*", "Authorization": "Bearer ..." }
+    },
+    "data": { "instanceName": "delay-test-999", "variables": {} },
+    "history_check": false,
+    "failed_policy": "retry",
+    "retry_wait": 60
+  }
+}
+```
+
+- **name**: Name of the schedule.
+- **client**: Represents client information. A schedule is recognized as the same only if all five elements match.
+  - **operation**: Represents a specific schedule purpose, like a process.
+  - **application**: Name of the client application.
+  - **group**: Domain information.
+  - **key**: A separate key for schedule distinction.
+  - **type**: Resource type of the schedule itself.
+- **type**: Main types include `cron`, `now`, `date`, `delay`, and `delay-recur`. Detailed descriptions are in the "Scheduler Type" section.
+- **schedule**: A string specified based on the schedule type. See "Scheduler Type" for details.
+- **timezone**: Time zone string for schedule processing (e.g., `Asia/Seoul`).
+- **task**: Contains the necessary task information to execute when the schedule is triggered.
+  - **type**: Specifies the type of task, such as `rest`, `kafka`, or `redis`. For `rest`, only POST is supported.
+  - **connection**: Connection information for task execution.
+    - **host**: Server connection information.
+    - **topic**: Used for `kafka` and `redis` types.
+    - **headers**: Optional for `rest` type.
+  - **data**: Specifies the data to be passed during task execution.
+  - **history_check**: Saves the history of schedule registration, execution, deletion, and re-execution in a separate database.
+
+### Schedule Type
+
+- **delay**: Waits for a specific time (in seconds) before executing the schedule.
+
+  ```json
+  {
+    ...
+    "type": "delay",
+    "schedule": "50",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- **delay-recur**: Repeats a schedule after waiting for a specific time (in seconds).
+
+  ```json
+  {
+    ...
+    "type": "delay-recur",
+    "schedule": "50",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- **cron**: Operates based on the cron format.
+
+  - Uses the basic five-element format.
+  - For second-level schedules, a six-element format is required, where the first element specifies seconds.
+
+  ```json
+  {
+    ...
+    "type": "cron",
+    "schedule": "0 * * * *",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- **date**: Specifies a specific date and time (ISO format, `YYYY-MM-DDThh:mm:ss`).
+
+  ```json
+  {
+    ...
+    "type": "date",
+    "schedule": "2023-04-05T12:30:00",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- **now**: Executes the schedule immediately.
+
+  ```json
+  {
+    ...
+    "type": "now",
+    "schedule": "",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+### Task Type
+
+- **Rest**
+
+  ```json
+  {
+    ...
+    "task": {
+      "type": "rest",
+      "connection": {"host": "http://localhost:3000/api/unstable/run-scenario/test-scenario-1", "headers": {"Content-Type": "application/json", "accept": "*/*"}},
+      "data": {"instanceName": "test-scenario-1", "variables": {}}
+    }
+  }
+  ```
+
+- **Kafka & Redis**
+
+  ```json
+  {
+    ...
+    "task": {
+      "type": "kafka",
+      "connection": {"host": "localhost:9092", "topic": "example-topic"},
+      "data": { ... }
+    }
+  }
+  ```

package/helps/scheduler/scheduler.zh.md

@@ -0,0 +1,185 @@
+# 스케줄러 서비스
+
+- Scheduler에 등록되는 모든 이벤트들은 cron을 포함한 여러 형태의 스케줄 타입 및 값이 지정
+- 사용자가 지정한 스케줄 형태에 따라서 이벤트가 호출되며, 일반적으로 호출된 이벤트는 사용자가 등록 시에 지정한 rest api를 호출
+- 호출된 이벤트가 실패할 경우 정책에 따라서 일정 시간 이후 재시도 수행
+- 스케줄러 처리의 부하를 분산하기 위해서 새롭게 설계된 구조로서 스케줄러는 데이터베이스 기반의 큐 구조를 사용하여 모든 스케줄 데이터를 관리
+
+### 스케줄러의 주기적 처리에 대한 Diagram
+
+![Periodic Scheduler Diagram](./assets/updated-scheduler-diagram-periodic.png 'Periodic Scheduler Diagram')
+
+- 구조가 간결하고 추가적인 다른 서비스 없이 운용 가능하다는 점이 장점
+- 각 인스턴스가 휴지 기간 없이 주기적으로 깨어나서 데이터베이스 내에 스케줄 큐를 확인해야 한다는 점이 단점.
+
+### (대안) 스케줄러의 깨어나는 시점을 또다른 모니터링 인스턴스가 주기적으로 확인해서 모든 스케줄러에게 Publish하는 구조
+
+![Pubsub Scheduler Diagram](./assets/updated-scheduler-diagram-pubsub.png 'Pubsub Scheduler Diagram')
+
+- 모든 인스턴스는 모니터링 인스턴스를 통해서 받는 다음 스케줄의 타임스탬프 정보에 의해서 스케줄 처리를 수행.
+- 추가적인 서비스(redis) 필요하며, 개별 인스턴스는 지속적으로 다음 스케줄에 대한 정보를 가지고 있어야 함.
+
+## MSA 기반의 스케줄러 서비스
+
+![MSA Scheduler Service](./assets/scheduler-service-msa.png 'MSA Scheduler Service')
+
+- 기존의 어플리케이션 구조에서 스케줄링 잡을 처리하는 스케줄러 서비스가 클라우드 기반의 수평 스케일링 구조에서 기능 수행이 불가능.
+- 별도의 스케줄러 서비스가 필요. 이러한 스케줄 작업을 수행하는 서비스는 다수 존재하지만 스케줄러 역할만을 수행하는 분리된 서비스가 없음.
+- 클라우드 환경에서 사용 가능한 수평적인 확장이 가능한 서비스 개발이 필요.
+
+## 서비스 개요
+
+![Scalable Scheduler Service](./assets/scheduler-service-scalable.png 'Scalable Scheduler Service')
+
+- 스케줄러 서비스는 Restful 기반의 수평 확장이 가능한 스케줄러 서비스.
+- MSA 기반의 어플리케이션 환경에서 기존 어플리케이션이 수행하는 스케줄링 모듈에 대해서, 별도의 스케줄링 서비스를 분리해서 제공하는 서비스를 제공합니다.
+
+## 사용 가능한 용도
+
+- 크론(cron) 기반의 스케줄잡(Schedule Job) 핸들러
+- 특정한 날짜 혹은 특정한 주기로 실행되는 태스크 실행 엔진
+- 특정한 이벤트를 등록 관리하고, 이벤트를 기반으로 특정 기능을 실행하거나 데이터를 전달하는 브로커
+
+### Schedule
+
+#### Format
+
+스케줄을 등록하기 위한 포맷의 예는 다음과 같습니다.
+
+```json
+{
+  "name": "bbb",
+  "client": {
+    "operation": "op#1",
+    "application": "chef",
+    "group": "system",
+    "key": "12345678",
+    "type": "scheduler"
+  },
+  "type": "cron",
+  "schedule": "30 * * * * *",
+  "timezone": "Asia/Seoul",
+  "task": {
+    "type": "rest",
+    "connection": {
+      "host": "http://localhost:3000/api/unstable/run-scenario/DELAY-TEST-9",
+      "headers": { "Content-Type": "application/json", "accept": "*/*", "Authorization": "Bearer ..." }
+    },
+    "data": { "instanceName": "delay-test-999", "variables": {} },
+    "history_check": false,
+    "failed_policy": "retry",
+    "retry_wait": 60
+  }
+}
+```
+
+- name: 스케줄의 이름
+- client: 클라이언트 정보를 표현합니다. 실제 스케줄은 5개의 요소가 모두 일치할 때 동일한 스케줄로 인식
+  - operation: 공정과 같은 별도의 스케줄 용도를 표현
+  - application: 클라이언트 어플리케이션 이름
+  - group: 도메인 정보
+  - key: 스케줄 구분을 위한 별도의 키
+  - 타입: 해당 스케줄 자체에 대한 리소스 타입
+- type: 스케줄 타입으로서 크게, cron, now, date, delay, delay-recur으로 구성됩니다. 자세한 설명은 다음 항목을 참조
+- schedule: 스케줄 타입에 따라 별도의 문자열이 지정됩니다. 자세한 설명은 아래 'Scheduler Type'을 참조.
+- timezone: 스케줄 처리를 위한 타임존 문자열(예. Asiz/Seoul)을 지정.
+- task: 해당 스케줄이 처리되어야할 때 필요한 태스크 정보를 포함.
+  - type: 태스크의 타입으로서, 크게 rest, kafka, redis 중 하나를 지정. rest의 경우 post만 지원합니다.
+  - connection: 해당 태스크가 수행되기 위한 연결 정보
+    - host: 서버 연결 정보
+    - topic: kafka와 redis 타입일 때 지정.
+    - headers: rest 타입일 경우 선택적으로 지정.
+  - data: 해당 태스크 수행 시 전달되어야 하는데이터를 지정
+  - history_check: 스케줄의 등록, 실행, 삭제, 재실행에 대한 히스토리를 별도의 DB에 저장.
+
+### Schedule Type
+
+- delay: 특정한 시간(초) 동안 대기 후에 스케줄을 실행합니다.
+
+  ```json
+  {
+    ...
+    "type": "delay",
+    "schedule": "50",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- delay-recur: 특정 시간(초) 동안 대기 후에 실행되는 스케줄을 반복 합니다.
+
+  ```json
+  {
+    ...
+    "type": "delay-recur",
+    "schedule": "50",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- cron: cron format을 기반으로 스케줄이 동작합니다.
+
+  - 기본적인 5개 포맷을 사용합니다.
+  - 초 단위 스케줄리을 실행하기 위해서는 6개 시간 요소가 필요하면, 첫번째 요소가 초를 지정합니다.
+
+  ```json
+  {
+    ...
+    "type": "cron",
+    "schedule": "0 * * * *",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- date: 특정한 일자 및 시간을 지정.(ISO 포맷, YYYY-MM-DDThh:mm:ss)
+
+  ```json
+  {
+    ...
+    "type": "date",
+    "schedule": "2023-04-05T12:30:00",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+- now: 바로 지금 해당 스케줄을 실행
+  ```json
+  {
+    ...
+    "type": "now",
+    "schedule": "",
+    "timezone": "Asia/Seoul",
+    ...
+  }
+  ```
+
+### Task Type
+
+- Rest
+
+  ```json
+  {
+    ...
+    "task": {
+      "type": "rest",
+      "connection": {"host": "http://localhost:3000/api/unstable/run-scenario/test-scenario-1", "headers": {"Content-Type": "application/json", "accept": "*/*"}},
+      "data": {"instanceName": "test-scenario-1", "variables": {}}
+    }
+  }
+  ```
+
+- Kafka & Redis
+
+  ```json
+  {
+    ...
+    "task": {
+      "type": "kafka",
+      "connection": {"host": "localhost:9092", "topic": "example-topic"},
+      "data": { ... }
+    }
+  }
+  ```

package/package.json

@@ -0,0 +1,38 @@
+{
+  "name": "@things-factory/scheduler",
+  "version": "7.1.34",
+  "main": "dist-server/index.js",
+  "browser": "dist-client/index.js",
+  "things-factory": true,
+  "license": "MIT",
+  "author": "heartyoh <heartyoh@hatiolab.com>",
+  "description": "connector module for scheduler service",
+  "publishConfig": {
+    "access": "public",
+    "@things-factory:registry": "https://registry.npmjs.org"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/hatiolab/things-factory.git",
+    "directory": "packages/scheduler"
+  },
+  "scripts": {
+    "build": "npm run build:server && npm run build:client",
+    "copy:files": "copyfiles -e \"./client/**/*.{ts,js,json}\" -u 1 \"./client/**/*\" dist-client",
+    "build:client": "npm run copy:files && npx tsc --p ./client/tsconfig.json",
+    "build:server": "npx tsc --p ./server/tsconfig.json",
+    "clean:client": "npx rimraf dist-client",
+    "clean:server": "npx rimraf dist-server",
+    "clean": "npm run clean:server && npm run clean:client",
+    "migration:create": "node ../../node_modules/typeorm/cli.js migration:create ./server/migrations/migration"
+  },
+  "dependencies": {
+    "@operato/graphql": "^7.0.0",
+    "@operato/input": "^7.0.0",
+    "@operato/shell": "^7.0.0",
+    "@things-factory/auth-base": "^7.1.33",
+    "@things-factory/scheduler-client": "^7.1.34",
+    "@things-factory/shell": "^7.1.24"
+  },
+  "gitHead": "22830c9e51c9fffb3c95d1d1f8cacc7706f7d2d1"
+}

package/server/index.ts

@@ -0,0 +1,3 @@
+export * from './service'
+
+import './routes'

package/server/routes.ts

@@ -0,0 +1,28 @@
+const debug = require('debug')('things-factory:scheduler:routes')
+
+process.on('bootstrap-module-global-public-route' as any, (app, globalPublicRouter) => {
+  /*
+   * can add global public routes to application (auth not required, tenancy not required)
+   *
+   * ex) routes.get('/path', async(context, next) => {})
+   * ex) routes.post('/path', async(context, next) => {})
+   */
+})
+
+process.on('bootstrap-module-global-private-route' as any, (app, globalPrivateRouter) => {
+  /*
+   * can add global private routes to application (auth required, tenancy not required)
+   */
+})
+
+process.on('bootstrap-module-domain-public-route' as any, (app, domainPublicRouter) => {
+  /*
+   * can add domain public routes to application (auth not required, tenancy required)
+   */
+})
+
+process.on('bootstrap-module-domain-private-route' as any, (app, domainPrivateRouter) => {
+  /*
+   * can add domain private routes to application (auth required, tenancy required)
+   */
+})

package/server/service/index.ts

@@ -0,0 +1,25 @@
+/* EXPORT ENTITY TYPES */
+
+/* IMPORT ENTITIES AND RESOLVERS */
+import {
+  entities as SchedulerEntities,
+  resolvers as SchedulerResolvers,
+  subscribers as SchedulerSubscribers
+} from './schedule'
+
+export const entities = [
+  /* ENTITIES */
+  ...SchedulerEntities
+]
+
+export const subscribers = [
+  /* SUBSCRIBERS */
+  ...SchedulerSubscribers
+]
+
+export const schema = {
+  resolverClasses: [
+    /* RESOLVER CLASSES */
+    ...SchedulerResolvers
+  ]
+}

package/server/service/schedule/index.ts

@@ -0,0 +1,7 @@
+import { Schedule } from './schedule-type'
+import { ScheduleQuery } from './schedule-query'
+import { ScheduleMutation } from './schedule-mutation'
+
+export const entities = [Schedule]
+export const resolvers = [ScheduleQuery, ScheduleMutation]
+export const subscribers = []