proj 2. youtube

1. 프로젝트를 하게 된 배경

리액트를 공부하는 용도로 youtube api를 활용해서

youtube를 구현해보았다.

다른 작업과 병행하다보니 기획부터 배포까지의 총 작업기간은 6일정도 소요되었다.

2. 배운 점 및 느낀 점

이번 프로젝트를 통해 새롭게 배우고 경험한 것은 크게 6가지다.

1. youtube api 활용
2. mock 데이터 생성 및 활용
3. React에서의 테일윈드 CSS 적용
4. 폴더구조와 url 구조 기획
5. MVP 형태 개발
6. .env 활용

프로젝트에서는 아래의 4가지 api를 활용하였다.

• 인기 동영상 데이터
• 검색 키워드에 따른 데이터
• 연관된 동영상 데이터
• 채널 데이터

일목요연하게 api가 정리 되어 있어서

필요한 api를 쉽게 찾을 수 있고, 필요한 데이터 수도 간편하게 지정할 수 있다.

 

다만 불편한 점은 전세계 모든 개발자가 youtube api를 사용하면 서버 과부하가 걸릴 수 있기 때문에

하루에 api를 호출할 수 있는 횟수가 제한되어있다.

하루당 query 한도는 10,000이고,

각 api에 호출 될 때마다 사용되는 quota양이 명시되어 있다.

우리나라는 자정이 아닌, 오후 4시 정각에 할당량이 다시 초기화된다.

 

매일 초기화가 되어도 작업하다보면 쉽게 한도에 다다르기 때문에

mock 데이터를 활용하여 작업하였다.

mock 데이터는 실제로 api를 send버튼을 통해 호출하여 나온 응답값을 저장하여 만들었다.

디자인을 위해 활용한 테일윈드 css는 바닐라 자바스크립트에서 활용한 적이 있었다.

리액트에서 적용하는 방법이 크게 다르지 않았고,

클래스명을 따로 작명하지 않아도 되는 점에서 무척 편했다.

 

하지만 세세하게 내가 원하는 수치를 적용하고 싶을 때는 커스텀해야해서

이 부분은 좀 불편했다.

 

기능을 구현하면서 폴더구조와 url구조를 생각보다 많이 수정했다.

기획보다 일단 먼저 기능을 구현하는 것이 우선순위가 되어서 그랬던 것 같다.

 

수정 전

function App() {

return (

<SearchInpProvider>

<Routes>

<Route path="/" element={<Home />} />

<Route path="/result/:keyword" element={<Result />} />

<Route path="/watch/:videoid" element={<Watch />} />

</Routes>

</SearchInpProvider>

);

}

수정 후

function App() {

return (

<SearchInpProvider>

<Routes>

<Route path="/" element={<Home />} />

{/* <Route path="/result/:keyword" element={<Result />} /> */}

<Route path="/result/:keyword" element={<Home />} />

<Route path="/watch/:videoid" element={<Watch />} />

</Routes>

</SearchInpProvider>

);

}

수정하는 것이 어렵지는 않지만 프로젝트 시간을 소모하게 되기 때문에

먼저 구체적으로 url 구조까지 기획하는 것이 좋을 것 같다.

기획 시간이 생각보다 길어지게 되겠지만

나중에 유지보수하는 시간을 그 이상으로 줄이는 방법인 것 같다.

 

이번 프로젝트를 진행하면서

구현해야하는 기능 단위를 소단위로 쪼개는 것의 중요성을 깨달았다.

큰 기능만 생각하면 작업하면서 막연해질 때가 있는데

그 때마다 소단위 명세를 나누면서 작업하는 것이 작업하는데 큰 도움이 됐다.

 

또한 MVP 형태를 생각하며 최대한 할 수 있는 것에 집중하는 것 또한 작업하는데 도움이 됐다.

MVP는 "Minimum Viable Product"의 약어로, 최소한의 기능을 갖춘 제품을 의미한다.

 

마지막으로 이번 프로젝트를 통해 경험한 것은

api키를 .env를 활용하여 숨긴 것이다.

youtube api를 사용할 때 api키를 발급받아 사용해야 하는데,

이 때 나만의 고유한 key가 노출되면 안되기 때문에 .env로 깃허브에 커밋이 되지 않도록 할 수 있다.

 

또한 이전에 .env에 환경변수로서 key를 저장하지 않은채 푸시했던 커밋들은

커밋내역에서 자동으로 숨겨지지 않기 때문에

이미 푸시된 상태에서 키를 숨기고자 한다면 커밋을 다시 revert하거나 굉장히 복잡한 과정이 필요하다.

보안과 관련된 사항인만큼 실무에서는 더욱 신경써야 할 요소이다.

3. 어려웠던 점

프로젝트를 하면서 어려웠던 점은 아래의 두가지였다.

1. 코드의 재사용성 증대

2. 반응형 웹 구현

 

중복되는 코드의 양이 작업하면서 증가되는데

감소 시키는 방법이 즉각적으로 떠오르지 않아서 힘들었다.

검색해보니 리액트쿼리, 유즈쿼리, outlet, 클래스 모듈화 등을 활용하는 방법이 있다.

다음엔 위와 같은 방법을 활용해서 코드의 질을 개선시킬 수 있도록 해야겠다.

 

또한 미디어쿼리를 활용해서 반응형으로 구현하는 것이 쉽지 않았다.

브레이크 포인트를 사전에 구체적으로 정의하지 않았어서

시간이 더 소요된 것 같아서 다음에는 브레이크 포인트를 더 고려하며 기획하는 것이 효율적일 것 같다.

 

4. 결론

이번 프로젝트를 통해 다음 프로젝트에서는

url구조와 폴더 구조 등을 더 구체적으로 꼼꼼하게 신경쓰며 기획단계에 시간을 더 투자해야 할 것 같다.

 

또한 나는 영상이 발행된 날짜를 Date 객체를 활용해서 직접 구현했지만

손쉽게 timeago라는 프레임워크를 통해서도 구현할 수 있다는 것을 알게됐다.

그 외 list 생성시 각각의 item의 key로 id를 부여할 때 활용할 수 있는

id 생성 프레임워크도 새롭게 알게 되었는데

다음 프로젝트에서는 리액트쿼리 등 이번에 시도하지 못한 것들을 적용해서 프로젝트 완성도를 높여보고 싶다!