어려웠던 점
1. Steam API 불러오는 과정에서 CORS 에러 발생
문제
=> 클라이언트에서 Steam API로 요청 시 CORS 오류 발생, API는 Reading이 됬지만
시각화가 안되는 현상
해결 방법
-
glitch를 통해 Express 프레임워크를 사용한 프로젝트 서버를 만들고 배포한 후 API 요청
-
클라이언트에서 glitch 서버에 API 요청하여 데이터 수신
-
데이터 18만개 수신이 됬기에 성능에 문제 발생 염려, 그 중 top 100 개를 불러와 시각화
2. Typescript 로 인한 코드 가독성 문제
문제
=> 타입스크립트의 도입에 의한 코드 가독성 문제와 코드가 길어져 복잡해 보일 수도 있음
해결 방법
=> type 폴더를 만들어 타입을 파일에 따로 저장 
=> 타입을 별도로 저장하여 적재적소로 사용할때 불러와서 사용한다. 파일이름은 파일명.d.ts로 타입예측이 최대한 가능하도록 만든다.
좋았던 점
1. reactQuery 사용하면서 좋았던 점
말이 필요 없을 정도다.. 코드 한줄이면 데이터를 사용가능했기에 다른 대용으로 Recoil도 있었지만 redux도 충분히 전역상태관리가 가능했고, 기회비용을 따지자면 Recoil 익히는 시간에 비해 redux 전역관리를 하는 시간이 더욱 적을 거라고 생각했기에 redux-toolkit과 reactquery를 사용했는데 이번 프로젝트로 인해 더욱 사용에 익숙해졌다.
2. Supabase
어려웠던 점
1, 데이터베이스 정규화
- 사용용도에 맞게 적제 적소로 테이블을 구성하는게 가장 어려운 부분이었다. 왜냐하면 백앤드와 프론트 사이에 중간점을 찾고 가장 최적의 데이터베이스 정규화에 신경써야하는 부분이 많았다. 예를 들어 각 테이블마다 필요한 부분들이 있겠지만 너무 많은 테이블은 성능에 문제가 생기고 그렇다고 합치기엔 front 딴에서 사용할 때 불편하기 때문이다.
2. 해결 방법
- supabase에서는 두 테이블을 엮어서 데이터를 불러오는게 가능하다.
- select 절에서 두 테이블의 필요한 부분만 가져와서 시각화를 시도해보았고 그 컬럼에 맞게 별도로 저장된 타입스크립트도 추가하여 진행해보았다.
- 테이블대로 따로 테이터를 불러올 필요 없이 별도로 지정하여 crud를 하니 코드의 간결성이 훨씬 좋아졌다.
느낀점
- 개발자는 저마다 어떤 목적을 가지고 프로젝트를 만들어본다. 강의를 듣고 이론에 대한 책을 보는 것도 좋지만 우리는 테크니션이기에 항상 코드를 쳐보며 어떤 것인지 느껴야한다고 생각했다.
남은 기간도 화이팅하며 프로젝트를 완성해나갈 예정이다.
