TypeScript 전환을 위한 준비 #234

New Issue

2023-08-03T02:04:41+09:00

Hide_D commented

2023-08-03 02:04:41 +09:00

동적 import

현재 sammo\ActionItem\아이템명.php 가 그대로 옮겨간다 쳤을 때

getItemClass(type?: availableItemClassName) => ItemClass;

로 동작할 수 있는 무언가가 필요

기본적으로는 await import 로 쓸 수 있을 것 같지만, 그냥 이걸로 충분한가?

이게 준비되지 않아도 모든 클래스가 bundle 되면 되긴 한다지만...

trait? mixin?

iAction의 구현에 php에서는 \sammo\DefaultAction trait을 쓰고 있음

상속으로 구현해도 되긴 하지만 trai이나 mixin 개념이 바로 적용가능한지 확인이 필요함

현 시점에서 필요한 것은

item.onCalcDomestic이 정의되어 있으면 호출하고, 정의되어 있지 않으면 호출하지 않는 깔끔한 구조, 혹은
클래스에 메소드로 정의되어 있으면 트리거에 자동으로 등록되는 구조

둘중에 하나인데, 뒤쪽은 일단 순위가 낮고, 뒤쪽 방법이 명확하다면 사실 앞쪽 방법도 naive하게 구현해도 된다.

https://stackoverflow.com/questions/27522973/typescript-optional-function-in-interface

위 방법으로 시도해보고 되나 확인

아직 vue3로 전환되지 않은 구형 페이지용 template

궁극적인 형태로 SSR은 고려하고 있지 않다!, 나는 게임 서버와 게임 클라이언트를 만들고 있는 것이다!

구형 페이지들은 javascript가 크게 필요하지 않은 일반 출력만 가지고 있는 경우가 있다.
(예: 왕조 일람)

일단 이걸 vue3로 완전히 변환하는 것보다, 일단 시간을 버는 용도로 php 수준과 유사한 template 코드가 필요.

ejs면 충분한가?

위의 코드와 SPA를 이어두는 방법

vue3로 만들어진 페이지들은 비교적 쉽게 SPA화할 수 있을텐데, 기존 페이지를 어떻게 묶을 것인가이다.

일단은 MPA로 만들되 express.js에서 일단 제어해주면 될텐데, 장기적으로는?

현재 고려하는 안은 페이지를 세단위로 나누는 것

/v/경로 - SPA가 모두 끝난 것, 저 아래의 경로는 vue router가 관리
/l/경로 - express.js + template로 렌더된 구형 페이지. l로 시작하는 페이지는 특별한 이유가 없다면 남아있어선 안된다
/p/경로 - vue3이지만 mpa 형태로 작성된것
*.php - 이전에 view로 사용되던 페이지에 한해서 express.js ? 혹은 caddy 에서 적절하게 redirect

daemonize 전까지 사용할 방법, 그리고 이후 변환을 위한 사전 준비

일단 php을 그대로 ts로 이식하는 것에 가까운 만큼 daemon을 만들 수 없을 것 같다

당장은 API/Global/ExecuteEngine.php 경로를 그대로 가져오는 방식을 고려하지만, 어쨌든 daemon으로 넘어갈 준비가 필요.

어떻게 하면 두 사이를 원만히 옮겨 갈 수 있을까?

live update 방안

어떻게 update를 해야하나?

현재 개념 상으로는 어쨌든 각각의 체섭 하나가 하나의 express.js를 운영하게 될 것이다.

순서 상으로

새로운 버전의 파일을 준비
클라이언트용 파일 번들, 서버용도 필요하다면 번들
새 버전용 express.js를 정지 상태로 실행
기존 버전용 express.js 정지 혹은 대기 명령
프론트단 접속기(아마도 caddy)에서 접속 방향을 새 버전용 express.js로 변경
새 버전용 express.js를 가동 상태로 변경
기존 버전용 express.js를 종료
이후 클라이언트에서 자연스럽게(?) 버전이 바뀌었음을 확인하고 페이지 새로 고침

이어야 할 것이다.

다만 이 부분이 조금 애매한데, express.js가 필요한 곳은 어디까지나 /api/ 로 시작되는 경로일 뿐이고, 좀 더 고려한다면 /l 로 시작하는 SSR 파일뿐이다. /v/와 /p/에 대해서는 caddy가 맡아주는게 맞지 않을까..?

만약 그렇다면 https://caddyserver.com/docs/api 여기서 api를 최대한 조작해서 접속단을 관리해줘야한다.

SSO

어떻게?

어차피 세션이 다른 상황이니 루트 사이트에다가 jwt를 받고 서명에 따라 세션을 발급하는 방법이 제일 무난할수도

스레드 구성

예전에 xdebug로 엔진 프로파일을 돌려본 결과 생각보다 DB 외 처리 로직이 많았음(아마도 게임이라!)

따라서 게임 내부 로직은 daemon과는 별개로 어쨌든 worker thread가 필요할 것으로 예상

예상되는 thread는 다음과 같음

메인 thread(node.js - express.js)
게임 내부 로직용 thread
전투 시뮬레이터 요청용 thread
내부적으로 reader writer lock이 있으면 편리하게 관리될 듯.
- reader writer core(?)writer 3단계로 나눌 수 있다면 더 좋겠지만..

### 동적 import 현재 `sammo\ActionItem\아이템명.php` 가 그대로 옮겨간다 쳤을 때 `getItemClass(type?: availableItemClassName) => ItemClass;` 로 동작할 수 있는 무언가가 필요 기본적으로는 await import 로 쓸 수 있을 것 같지만, 그냥 이걸로 충분한가? 이게 준비되지 않아도 모든 클래스가 bundle 되면 되긴 한다지만... ### trait? mixin? `iAction`의 구현에 php에서는 `\sammo\DefaultAction` trait을 쓰고 있음 상속으로 구현해도 되긴 하지만 trai이나 mixin 개념이 바로 적용가능한지 확인이 필요함 현 시점에서 필요한 것은 - `item.onCalcDomestic`이 정의되어 있으면 호출하고, 정의되어 있지 않으면 호출하지 않는 깔끔한 구조, 혹은 - 클래스에 메소드로 정의되어 있으면 트리거에 자동으로 등록되는 구조 둘중에 하나인데, 뒤쪽은 일단 순위가 낮고, 뒤쪽 방법이 명확하다면 사실 앞쪽 방법도 naive하게 구현해도 된다. [https://stackoverflow.com/questions/27522973/typescript-optional-function-in-interface](https://stackoverflow.com/questions/27522973/typescript-optional-function-in-interface) 위 방법으로 시도해보고 되나 확인 ### 아직 vue3로 전환되지 않은 구형 페이지용 template _궁극적인 형태로 SSR은 고려하고 있지 않다!, 나는 게임 서버와 게임 클라이언트를 만들고 있는 것이다!_ 구형 페이지들은 javascript가 크게 필요하지 않은 일반 출력만 가지고 있는 경우가 있다. (예: 왕조 일람) 일단 이걸 vue3로 완전히 변환하는 것보다, 일단 시간을 버는 용도로 php 수준과 유사한 template 코드가 필요. ejs면 충분한가? ### 위의 코드와 SPA를 이어두는 방법 vue3로 만들어진 페이지들은 비교적 쉽게 SPA화할 수 있을텐데, 기존 페이지를 어떻게 묶을 것인가이다. 일단은 MPA로 만들되 express.js에서 일단 제어해주면 될텐데, 장기적으로는? 현재 고려하는 안은 페이지를 세단위로 나누는 것 - /v/경로 - SPA가 모두 끝난 것, 저 아래의 경로는 vue router가 관리 - /l/경로 - express.js + template로 렌더된 구형 페이지. l로 시작하는 페이지는 특별한 이유가 없다면 남아있어선 안된다 - /p/경로 - vue3이지만 mpa 형태로 작성된것 - *.php - 이전에 view로 사용되던 페이지에 한해서 express.js ? 혹은 caddy 에서 적절하게 redirect ### daemonize 전까지 사용할 방법, 그리고 이후 변환을 위한 사전 준비 일단 php을 그대로 ts로 이식하는 것에 가까운 만큼 daemon을 만들 수 없을 것 같다 당장은 `API/Global/ExecuteEngine.php` 경로를 그대로 가져오는 방식을 고려하지만, 어쨌든 daemon으로 넘어갈 준비가 필요. 어떻게 하면 두 사이를 원만히 옮겨 갈 수 있을까? ### live update 방안 어떻게 update를 해야하나? 현재 개념 상으로는 어쨌든 각각의 체섭 하나가 하나의 express.js를 운영하게 될 것이다. 순서 상으로 - 새로운 버전의 파일을 준비 - 클라이언트용 파일 번들, 서버용도 필요하다면 번들 - 새 버전용 express.js를 정지 상태로 실행 - 기존 버전용 express.js 정지 혹은 대기 명령 - 프론트단 접속기(아마도 caddy)에서 접속 방향을 새 버전용 express.js로 변경 - 새 버전용 express.js를 가동 상태로 변경 - 기존 버전용 express.js를 종료 - 이후 클라이언트에서 자연스럽게(?) 버전이 바뀌었음을 확인하고 페이지 새로 고침 이어야 할 것이다. 다만 이 부분이 조금 애매한데, express.js가 필요한 곳은 어디까지나 /api/ 로 시작되는 경로일 뿐이고, 좀 더 고려한다면 /l 로 시작하는 SSR 파일뿐이다. /v/와 /p/에 대해서는 caddy가 맡아주는게 맞지 않을까..? 만약 그렇다면 https://caddyserver.com/docs/api 여기서 api를 최대한 조작해서 접속단을 관리해줘야한다. ### SSO 어떻게? 어차피 세션이 다른 상황이니 루트 사이트에다가 jwt를 받고 서명에 따라 세션을 발급하는 방법이 제일 무난할수도 ### 스레드 구성 예전에 xdebug로 엔진 프로파일을 돌려본 결과 생각보다 DB 외 처리 로직이 많았음(아마도 게임이라!) 따라서 게임 내부 로직은 daemon과는 별개로 어쨌든 worker thread가 필요할 것으로 예상 예상되는 thread는 다음과 같음 - 메인 thread(node.js - express.js) - 게임 내부 로직용 thread - 전투 시뮬레이터 요청용 thread - 내부적으로 reader writer lock이 있으면 편리하게 관리될 듯. - reader writer core(?)writer 3단계로 나눌 수 있다면 더 좋겠지만..

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: devsam/core#234