002. 플라네타리움(Planetarium)

• 홈페이지: https://planetariumhq.com/
• 나인코퍼레이션 채용 안내: https://bit.ly/join-planet

플라네타리움은 게임의 생명주기와 수익 모델을 혁신하려는 오픈 소스 블록체인 플랫폼입니다. 블록체인 기반 게임 제작을 위한 C# 라이브러리인 Libplanet을 기본으로, 블록을 조회하고 확인하기 위한 Libplanet Explorer, 그리고 웹페이지를 통해 편리하게 블록을 확인할 수 있는 Libplanet Explorer Frontend로 구성되어 있습니다.

• 플라네타리움 GitHub: https://github.com/planetarium
• Libplanet 문서: https://docs.libplanet.io/

Libplanet으로 작성된 간단한 예제로 클리커 게임을 제공하고 있습니다.

• Planet Clicker: https://github.com/planetarium/planet-clicker
  • 소개: https://github.com/planetarium/planet-clicker/blob/master/EXAMPLE.md

과제

프로그래밍 과제는 Libplanet Explorer Frontend(이하 LEF)의 빌드를 병렬화하여 소요 시간을 단축해야 했습니다. Libplanet Explorer가 제공하는 GraphQL 엔드포인트를 이용해 LEF는 블록 내에 있는 값을 웹페이지로 보여줍니다.

이 프로젝트는 주로 TypeScript로 작성되어 있으며, React 기반 웹 사이트 생성 프레임워크인 Gatsby로 만들어져 있습니다. TypeScript와 React, 그리고 Gatsby 모두에 익숙하지 않은 관계로 쉽지 않으리라 예상했습니다.

LEF는 GitHub Action을 통해 리포지터리에 새로운 코드들을 새 정적 웹페이지 코드로 빌드합니다.

• GitHub Action: https://github.com/features/actions

해결 과정

기존 GitHub Action으로 실행되는 빌드를 살펴보니, 평균 6분 내외의 시간이 걸렸습니다. 빌드 과정을 자세히 살펴보면 총 3회의 Gatsby 빌드가 이루어짐을 알 수 있습니다. 리포지터리 내의 설정파일에 등록된 엔드포인트 개수만큼 빌드를 여러 번 수행하고 있었습니다.

• 기존 빌드: Merge pull request #67 from jckdotim/number-panel

우선 GitHub Action을 로컬에서 실행하며 테스트하기 위해, act를 이용하려고 했습니다. 하지만 새로 만들어진 GitHub Action v2를 지원하지 않아 사용할 수 없어, 로컬에서 빌드를 재현하는 데는 실패했습니다.

• Issue #74, Support Actions v2

일단 처음 제안받은 대로 Gatsby의 빌드 결과물을 출력하는 디렉토리의 이름을 바꿔 병렬로 실행하려고 했습니다. 하지만 --output-dir 등의 옵션을 지원하지 않아 하나의 Action 내에서 멀티 쓰레드나 멀티 프로세스로 실행하면, 같은 폴더에 파일을 중복으로 쓰며 문제가 생길 수 있었습니다. 그리고 하나의 Gatsby 빌드 자체가 이미 멀티 코어 활용하여 병렬로 이뤄지고 있었기 때문에, 단순한 멀티 프로세스 처리로는 효율을 높이기 어렵다고 판단했습니다.

• Issue #1878, Configuable output folder
• Gatsby Multi-core build

현재 구조를 유지한다면 빌드를 개선한다 해도 엔드포인트가 늘어난 만큼 빌드해야 하는 부담이 있기 때문에, 애초에 구조를 달리해 하나의 사이트에서 여러 엔드포인트를 바꿔 접속할 수 있도록 수정하는 방향으로 계획을 변경했습니다.

엔드포인트 별로 다른 구조의 데이터를 제공한다면 이렇게 처리하긴 어렵겠지만, 각각의 엔드포인트는 같은 Libplanet Explorer로 구성되어있기 때문에 LEF에서 사용하고 있던 Apollo client의 접속 URI만 달리하여 사용해보고자 했습니다.

이미 만들어진 Apollo client에 주소만 변경하여 사용할 수 있으면 좋겠다는 다른 프로젝트의 이슈도 발견했지만, 이번에는 클라이언트를 새로 만들어 교체하는 쪽으로 구성했습니다.

• Issue #296, Update / set dynamic uri
• Issue #1267, how to override the uri of the apollo client’s network interface?

드롭다운 UI를 통해 여러 엔드포인트를 보여주고, 새 엔드포인트를 선택하면 React의 useEffect를 통해 새 클라이언트를 만들어 설정하게 했습니다. LEF는 Microsoft의 UI Fabric을 사용하고 있어, 도움말을 통해 손쉽게 컴포넌트를 구성해서 추가할 수 있었습니다.

• Pull request #79, Create pages for each endpoint
• 변경된 후 빌드: Merge pull request #79 from lqez/use-multiple-endpoints
• UI Fabric Dropdown 예제

구조를 변경하였으므로, 추후 엔드포인트가 늘어나도 빌드에는 부담이 없도록 개선되었습니다.

추가 작업

• 블록체인에 저장된 사용자 데이터를 통한 잔존율 분석에 대해 이야기를 나누었습니다.
  • What is retention analysis? (mixpanel)

더 알아보기

• ShellCheck
  • 웹페이지 쪽에서 쉽게 엔드포인트 정보를 다루기 위해 .tsv 형식을 JSON 형식으로 변경하는 쉘 스크립트를 작성했습니다. 이때, ShellCheck를 통해 작성한 쉘 스크립트의 문제를 쉽게 찾아내고 어떻게 고쳐야 할지 확인할 수 있었습니다.
  • 프로그램으로 설치: https://github.com/koalaman/shellcheck#user-content-installing
  • 에디터 확장: https://github.com/koalaman/shellcheck#user-content-in-your-editor
• Netlify
  • 현대적인 웹 서비스를 위한 다양한 백엔드 서비스를 제공합니다.
  • 정적 웹 페이지를 GitHub Action을 통해 빌드하고 GitHub Pages로 서빙하는 것이 가능하지만, pull request에 대해 미리보기 페이지를 만들 수는 없습니다. 이런 경우에 Netlify Site deploys를 사용하면 각각의 pull request에 대해 미리보기 페이지를 만들어, 어떤 결과물이 나올지 손쉽게 확인할 수 있는 장점이 있습니다.

영상