회고록

😃 이번 프로젝트에서 알림 기능이 있었다. 그래서 찾아보니 SSE로 구현을 해야한다는것. SSE라는걸 알림 구현하면서 첨 알게되서 정리를 해보았다!! 일단 서버와의 실시간 통신을 위해 살펴봐야할 기술 3가지가 있다. 실시간 통신 1. websoket 클라이언트와 서버와의 양방향 통신이 가능. 기존 HTTP 통신과 달리 클라이언트와 서버와의 지속적인 연결을 통해 데이터를 주고 받을 수 있다. ws 프로토콜을 통해 웹소켓 포트에 접속해 있는 모든 클라이언트(subscribe)에게 이벤트 방식으로 응답한다 처음 연결시 한번의 핸드셰이크만 수행하면 되기 때문에 통신 오버헤드가 낮다. 2. polling 클라이언트가 주기적으로 서버에게 request를 날려 응답을 받는 방식. 일정하게 요청을 보내므로 서버에 데이..

✨interceptor✨ 요청이 전송되기전, 응답이 처리되기전 실행되는 함수. 즉 요청을 할때 헤더를 바꾸거나 응답이 처리되기전 무언가 에러처리를 바꾼다거나 데이터를 바꿀 수 있는 미들웨어 역할을 한다. 그래..그래서 요청 전에 뭘 어떻게 한다는건데.. axios.interceptors.request 로 요청 전 처리 axios.interceptors.request.use( (config) => { // 요청전에 토큰을 처리 config.headers.Authorization = `Bearer ${getToken()}`; return config; }, (error) => { // 에러 처리 return Promise.reject(error); } ); 요청이 전송되기 전 config객체를 받아서 hea..

6주간 대장정의 팀프로젝트가 끝났다. 정말 우여곡절이 많은 팀플이었다,,ㅎㅎ^^ 5주차부터 백엔드와 회원쪽 연동을 시작했고 5주차 중반부터 본격적으로 그외 기능들 연동을 시작했다. 데모데이 일주일 남겨두고 시작한것,,^^ 일단 5주차 연동을 시작할때 팀원들에게 프론트가 이정도 일정에 어디어디까지 연동 가능하다. 라고 말을 하고 시작했다. 왜냐하면 연동이 늦어지기도 했고 남은 일정안에 진행이 가능한 계획을 공유하고 시작하는게 좋다고 생각했다. 프론트가 2명이긴 했지만 거의 내가 99%..를 다했기 때문에.. 사실 정말 중간에 포기하고 싶긴했지만..😇 다행히 우리 서비스에서 크게 어려운 기능이 없었고, 백엔드 팀원분 중 한명이 너무 잘 도와주셔서 연동하는데 무리가 없었다. 그리고 msw로 백엔드 API를 목..

CORS란 cross-origin-resource-sharing의 약자. 직역해보면 서로 다른 도메인간의 자원을 공유하는것을 의미한다. 브라우저가 CORS에러를 내뿜는것은 서로 도메인이 다른데? 이거 너네 공유 안됨. 이라고 판단하고 에러를 내뱉는 것이다 브라우저는 보안때문에 도메인/포트번호/프로토콜 하나라도 다를경우 다른 교차 출처(cross-origin)이라고 판단을 하고 cross-origin-HTTP 요청을 제한하는것. 어떻게 브라우저가 에러를 내뱉는 것일까 CORS는 브라우저에서 보안을 이유로 사용자들을 보호하기 위해 만든 정책이다. 이 정책이 없다면 누구나 요청이 가능해지기 때문에 사이트들을 똑같이 만들어 사용자의 로그인을 유도해 정보를 추출해 갈 수 있다. 이로 인해 CORS 정책을 도입했고..

지금 마음 회고할 곳이 필요해서,,팀프로젝트 4주차 후기를 쓴다,,😭 1주차가 기획단계 2~4주차가 개발 프로세스 기간이다,, 4주차 쯤이면 백엔드와 프론트엔드 연동이 활발하게 이루어져야 하는 기간인데 백엔드에서 배포가 늦어져 아직 목데이터로 프론트 개발중이다..... 6주차쯤 데모데이를 한다는데 완성이 가능할런지 너무나 걱정이된다. 왜냐,,로그인/채팅/알림/회원/로그인 유지 등 서버와의 연결이 활발하게 이루어져야 되는 작업들이 남아있기 때문,, 나는 JWT로 로그인 구현해본적이 없을 뿐더러 채팅, 알림도 처음 구현해보는거라,, 구현이 완성이 잘 될지 걱정이다,, 일단 로그인이나 채팅 같은경우 로직을 짜놓긴 했는데,, 실제 서버에서 토큰이 올경우 분명 에러가 생길거라고 확신하기 때문에,,(왜냐하면 처음이..

parallel route에 대해서 next.js 13부터 parallel route(병렬 라우팅) 기능이 생겼다. 이것이 뭐냐?? 말 그래도 병렬적으로 라우팅 한다는것!!! 한 레이아웃에서 여러 페이지를 병렬적으로 렌더링 할 수 있다는 것이다. next.js에서 제공한 이미지를 보면 layout.js라는 한 레이아웃에서 team 페이지와 analytics페이지를 병렬적으로 렌더링 하고 있다. 그러니까 한페이지에 team과 analtics가 개별적으로 렌더링이 되고 있다는것! 병렬적으로 렌더링 하고 싶은 파일은 @폴더/page.js 로 만들어주어야 하는 규칙을 가지고 있다. @폴더/page.js로 만들어진 파일은 layout.js파일에서 props로 받을 수 있다. 사용법은 이게 끝이다. ㅎ 만약 병렬적..

이번 프로젝트에 지마켓 산스 웹폰트를 사용했다. 그런데..분명 크롬에서는 폰트가 잘 나왔었는데 사파리에서는 적용이 안되서 나왔다. 궁서체처럼 나오는것이 너무 맘에 안들었다. ㅡㅡ 굉장히 구려보이고요 일단 저 궁서체 같은 폰트를 해결하고자 sans-serif를 적용했다. 고딕체로 나오도록. 그러나 내가 원하는건 지마켓 산스 웹폰트가 나와야 하는것!!!!! app/layout.tsx 파일에 로컬폰트를 아래와 같이 적용했다. //app/layout.tsx const customFont = localFont({ src: [ { path: '../../public/fonts/GmarketSansLight.woff', weight: '300', style: 'normal', }, { path: '../../publ..

이번에 app router를 사용하면서 기본적으로 data를 fetch가 필요한 경우 서버컴포넌트에서 Data Fetching Patterns을 사용했다. 그런데 문제가 있었다.. geolocation API를 사용해서 위도 경도 값을 받아온 다음 openweather API를 받아와야 하는 상황.(위도 경도로 해당 지역의 날씨를 받아와야 함) 이것을 서버컴포넌트에서 해야하는가 클라이언트 컴포넌트에서 해야하는가 고민을 했다. openweather API를 받아오는것만 생각하면 data fetch니까 서버컴포넌트가 맞는거 같은데 geolocation API가 브라우저에서 제공하는 API이다 보니 클라이언트 측에서 openweather API를 사용하는것이 맞지 않나?? 두 생각이 머릿속에서 충돌 됬다 (오..