내 Git 호스트가 정적 사이트 생성기라면?

sorcery는 저장소가 갱신될 때 개요, 브랜치별 최신 디렉터리 트리, 구문 강조된 소스 코드를 정적 HTML로 생성하는 Git 저장소 뷰어임 작은 개인 서버에서 Forgejo가 디스크 부족과 스크래퍼 부하로 중단되는 문제에 대응해, 사전 생성 비용을 치르고 이후 요청은 저렴한 정적 파일 전송으로 처리함 모든 과거 버전을 미리 렌더링하지 않고, 읽기 전용 JavaScript Git 클라이언트가 공개된 .git 디렉터리와 보조 JSON을 읽어 저장소 이력을 브라우저에서 렌더링함 높은 지연 시간과 packfile 탐색 비용을 줄이기 위해 Git 객체 일괄 조회 API도 제공하므로, 정적 파일 중심이지만 완전히 정적인 구현은 아님 협업 기능은 제외하고 쓰기는 별도의 Git over SSH로 분리하며, 개인 코드를 휴대전화로 살펴보고 링크로 공유하는 용도에 집중함 개인 Git 인프라를 줄이려는 이유 개인 개발 인프라를 직접 운영하는 이유는 us-east-1까지 대체로 120ms 이상 걸리는 지연 시간과 시스템 관리 자체의 즐거움임 2015년 Gogs로 시작한 개인 인스턴스가 Gitea를 거쳐 Forgejo로 바뀌었으며, 여러 소속 그룹에도 GitLab과 Forgejo를 배포해 왔음 공동체의 협업용 Git 서비스는 여전히 가치가 있고, Forgejo는 그 역할에 잘 맞음 하지만 작은 개인 서버의 Forgejo는 갱신되지 않은 저장소를 재패킹하다 충돌하면서 디스크 공간이 부족해지고, 상시 유입되는 스크래퍼 부하로 중단되거나 메모리 부족을 겪음 개인 용도에는 이슈, PR, 릴리스, 위키 같은 GitHub 호환 기능이 필요하지 않으며, 사용하지 않는 기능에도 일정한 비용을 부담하게 됨 작업 증명 없이 공개 웹에 코드 게시하기 Forgejo의 자원 고갈에 흔히 쓰이는 대응책은 Anubis 같은 웹 애플리케이션 방화벽으로 JavaScript 작업 증명을 통과해야 접근할 수 있게 하는 방식임 이 방식은 사용자 기기에 거의 쓸모없는 연산을 강요하고, 실행을 거부하면 필요한 정보도 볼 수 없게 한다는 점에서 열린 웹의 철학에 어긋남 JavaScript를 지원하지 않는 브라우저는 완전히 차단될 수 있고, JIT JavaScript를 지원하지 않으면 지나치게 긴 대기 시간이 생길 수 있음 이런 제약은 현대 웹의 소수 브라우저 중심 편중을 심화함 읽기가 쓰기보다 압도적으로 많은 작업에서 방화벽에 의존하는 것은, 애플리케이션이 실제 인터넷...