현재 노트: KR-110.50 a
상위 분류: KR-110.50 명언 내보내기 프로젝트

#개인프로젝트

처음 무료, 리소스에 신경을 쓰지 않기 위해 사용한 인프라는 GitHub Pages였습니다.

계획한 아키텍처의 동작은 다음과 같았습니다.

1. GitHub에 data.json 과 관련 로직처리하는 소스를 저장
2. github.io링크를 통해 해당 data.json에 접근
3. 함수를 이용하여 data.json에서 데이터를 필터링
4. 로컬에서 해당 함수 사용

처음에는 기술적인 부분이 가장 큰 관건이라 생각하고 GitHub Pages 구현과 데이터 필터링만 구현된다면 이 후는 수월할 것이라 생각했습니다만!
결론부터 말하면 결국 4번에서 큰 문제를 만나게 돼어 인프라를 변경 할 수 밖에 없었습니다...
특히 정적 사이트와 동적 사이트를 구분하지 않고 구현을 시도한 점을 꺠달았습니다.
아래의 내용은 의사결정과 구현을 흐름에 따라 기술한 내용입니다.

먼저 GitHub Pages를 세팅한 후 다음과 같은 화면이 나오는데 까지 성공하였습니다.

이 단계에서는 간단하게 GitHub Pages 세팅하기 , _config.yml 설정하기 등과 같은 세팅 위주의 것들만 수행하면 쉽게 구현 할 수 있었습니다.

github.io링크를 통해 data.json에 접근할 떄 고민된것은 fetch를 쓸 것인지 Axios를 쓸것인지 였습니다.

구현 자체는 간단한 단계였지만 두 방법 중 어느것을 선택할지가 어려웠습니다.
많은 검색결과에서도 다양한 의견들이 있었지만 결론적으로는 fetch를 사용하기로 했습니다.
찾아본 결과 Axios의 경우 더 편하고 다양한 기능이 제공되기는 하지만, 따로 설치해야 한 다는 점과 Promised 기반의 WHATWG에서 정의한 http 클라이언트인 fetch기반으로 사용해서 구현 후 안되는 것이 있다면 Axios를 시도하는게 좋다고 생각하여 fetch로 구현하기로 하였습니다.

이후 시도한 것은 window객체의 값에서 쿼리값을 찾아 필터리하는 동작을 하는 함수를 테스트해보는 것이었습니다.

아래의 함수를 통해 원하는 동작이 수행됨을 확인 할 수 있었습니다.
URLSearchParams 함수를 통해 window객체의 search바의 정보를 가져오고 쿼리 id값을 이용하여 fetch 함수를 수행하여 data.json값을 가져온 것과 비교하는 동작이었습니다.
아래의 함수 동작 결과 제대로 반환됨을 확인하였고 이제 그럼 끝난 것인가 싶었습니다만...

const url = "https://murphybread.github.io/fetchable-custom-quotes/data.json";
const urlParams = new URLSearchParams(window.location.search);
const id = urlParams.get("id");

async function fetchQuote() {
  const urlParams = new URLSearchParams(window.location.search);
  const id = urlParams.get("id");

  try {
    const response = await fetch(url);
    const quotes = await response.json();

    const quote = quotes.find((q) => q.id === id);

    if (quote) {
      console.log(quote.content);
    } else {
      console.error("Quote not found with id:", id);
    }
  } catch (error) {
    console.stack("Error fetching data:", error);
  }
}

fetchQuote();

이 함수를 어디에 구현할 것 인가?에서 문제가 발생하여 기획을 전부 수정하던가 인프라를 변경해야하는 문제에 직면 했습니다.

처음 기획에서는 2가지 상황에서 동작하기를 원했습니다.

1. Obsidian이라는 본인이 사용하는 로컬 기반의 Note툴에서 도메인 API로 접근
2. 웹에서 도메인 API로 접근

이런 상황에서 위의 함수를 구현하기 위해서는 1번이나 2번이나 어려운 상황이였습니다.

1번의 경우는 감도 잡히지 않았기에(예를 들어 노션같은 툴에서 함수를 저장해놨다가 API를 호출하는데 사용하려는 상황) 2번이 가능한지를 고려해봤습니다.
왜냐하면 현재 사용되는 블로그에 표기될 내용이기에 웹에서 해당 함수를 구현할 수 있는 방법이 있었습니다만...

결론적으로는 2번또한 어렵다고 판단하였습니다. 왜냐하면 중요한 검색 조건인 id쿼리가 url에서 입력받는데, 노트에서는 해당 url이 고정이 되기 때문에 따로 url이 아닌값을 입력받는 형태로 구현해야했고,
그렇다면 url아닌 형태로 입력받기 위한 컴포넌트등을 만들어야했기 때문입니다. 기존의 티스토리 같은 블로그라 일부 수정이 가능하지만 이런 복잡한 구현까지는 기획 의도를 벗어나는 일이라고 판단하였습니다.

이번 기획의 경우 클라이언트쪽에서는 최대한 편하게 주소의 API로 접근해야했고, GtiHub Pages의 경우 정적 사이트이다보니 처음부터 이 인프라가 적절한 선택이 아니었던 것을 깨달았습니다.
그래서 결론적으로는 처음에 기획에서 언급 됐던 Vercel Functions 기반의 동적 사이트를 구축하기로 하였습니다.