이 문서 내용은 좀 낡았습니다.
60일이나 편집 안된 오래된 망한 문서니 개발 문서인 경우 참고할 때 조심하세요. 최신 정보를 알고 싶으면 게시판에 글 써주세요


목차

1. 이전 문서
2. 개요
3. 목표
3.1. 오픈나무마크 렌더러의 Golang 이전
4. 고민 중인 사안
4.1. 어느 시점에서 Flask 대신 Gin으로 역할을 넘길 것인가
4.2. 파이썬 파트를 유지할 것인가
5. 해결된 사안
5.1. Golang이 DB 사용중인 동안 생기는 문제
5.2. Golang에서 넘겨준 데이터를 프론트로 변환할 곳 (결심)
6. 그러고보니 제일 중요한 이야기를 안 적었는데

1. 이전 문서

2. 개요

참고로 dev 빌드를 쓰고 있다면 이미 주요 기능에 Golang이 대거 쓰이고 있다

지금보는 이 문서의 로드도 Golang이 하고 있다 곧 렌더러도...

별로 아직까진 적용한 곳 많이 없는데 빨라진 것 같은 기분이 든다... 진짜 기분 탓인가?

3. 목표

  • API의 전면적인 Golang으로의 재작성
  • 구닥다리 API 기능 개선 및 API 추가
  • 그 외 라우터단의 db 직접 연결을 최소화하고 API를 이용하도록 개선

3.1. 오픈나무마크 렌더러의 Golang 이전

일단 현재 쓰는 오픈나무마크의 렌더러에서 굳이 내부에서 처리할 필요 없는 부분을 최대한 JS로 빼고 비효율적인 부분 최적화한 후에 이전하기로 했다

1. 분류, 목차 내부 렌더링은 JS로 이관
2. 현재 비효율적인 중괄호 wiki 문법 좀 개편
3. Golang으로 차근차근 이전

4. 고민 중인 사안

4.1. 어느 시점에서 Flask 대신 Gin으로 역할을 넘길 것인가

4.2. 파이썬 파트를 유지할 것인가

5. 해결된 사안

5.1. Golang이 DB 사용중인 동안 생기는 문제

정확히는 MySQL 상에서만 일어나는 문제 같은데 Golang에서 DB 사용중인 동안 파이썬에서 DB 요청하면 타임아웃 뜨는 것 같은 기분이 든다

이는 좀 더 정확하게 확인해봐야겠다

사실이였다... 고랭 파트에서 함수마다 DB 커넥션을 계속 열도록 만들었더니 Max DB 커넥션 문제로 터져버린다

수정해야겠다

수정 완료 했다 (좀 되었지만)

5.2. Golang에서 넘겨준 데이터를 프론트로 변환할 곳 (결심)

API를 Golang으로 작성한 다음 생기는 고민이 2가지가 있다

이 API 데이터를 내부에서 처리할 것이냐 JS로 클라이언트 단에 넘길 것이냐가 현재의 고민이다

전자는 DB 사용 파트만 내부 API 호출로 교체하면 되니까 간편한데 서버 부담이 크게 안 준다는 문제가 있고

후자는 다 좋은데 재설계 해야하니 시간이 오래 걸린다

그래서 고민 중이다...

기왕하는 김에 가능하면 JS로 넘기는 게 맞는 것 같다

안 그러면 퍼포먼스 개선 어느 정도 밖에 없으니까...

6. 그러고보니 제일 중요한 이야기를 안 적었는데

이미 다들 잘 쓰고 있고 대충 예상했겠지만

하위 호환성을 포기하지 않을 것이다

이미 그것은 파이썬애니웨어에서 Go 섞인 오픈나무가 잘 돌아가고 있음이 증명하고 있다