동기분과 함께 새로운 사이드 프로젝트를 진행하기 위해, repository 를 구성하는 과정에서 한번 front web 과 server 를 하나의 repository 에서 관리해보고자 하였다. 다만 현재 진행하려는 서비스가 monorepo 개념이 필요한 것인지는 의문이었으며, 조금 더 monorepo의 활용방안과 의의를 알기 위해 계속 공부중이다. 이번 포스팅에서는 간단하게 Nx 를 활용하여 초기 Next.js, Tailwindcss, React-query 를 세팅한 경험을 다루고자 한다. 조금 더 monorepo에 대한 개념이 잡힌다면 그때 monorepo에 대한 자세한 포스팅을 준비해야겠다. (왜 turborepo 대신 Nx 를 선택했는지부터..) Nx 의 workspace 를 생성하면서.. yarn..
사이드프로젝트(Closet)가 배포까지 완료되어, 이제 마무리 단계라고 생각할 때 쯔음 여러 의류를 저장한 다음 무한 스크롤을 시험해보려 하고 있었다. 데이터가 10개 이상은 저장되었어야 그 이상의 데이터를 저장한 다음 이제 목록 페이지로 이동하여 의류들을 살펴보려고 하는데, 이미지가 s3 에서 제대로 업로드 되지 않고 깨지는 현상이 발생했다. 오류를 살펴보니 502 gateway out. 특별한 코드 문제가 없는것을 보니 결국은 제 시간안에 이미지를 처리하지 못한다는 것인데, (pm2 monit 에서는 오류가 발생하지 않고) 무엇이 문제일지 잘 파악이 되질 않았다. 문득 front 인스턴스의 pm2 shell 속도가 급격하게 감소하는 것을 보고, 뭔가 front 인스턴스에 과부화가 생긴것은 아닐까 의심..
프로젝트에서 프론트엔드 부분을 담당하면서 작업을 이어가다 보면, 어느 순간 무한 스크롤 기능을 구현해야 하는 순간이 오게 된다. 아무런 방법을 모른다고 가정 할 때, 머리속에서 방법에 대해 떠올려보면 아마도 가장 먼저 생겨나는 방법은 웹 브라우저 내 스크롤바의 위치에 따라 데이터를 fetch 해오는 과정이 떠오를 것 같다. 물론 아닐수도 있지만 나는 그랬다.. 그야 아주 직관적인 방법이기 때문이다. 스크롤 바가 화면 맨 아래로 이동이 되었을 때, 그 순간 추가적으로 데이터를 가져오게 되면 그게 무한 스크롤이지 않을까. 브라우저에는 이렇게 스크롤 바의 위치를 표현해주는 API 를 제공한다. 이벤트에 구독하여 매 움직이는 순간마다 위치를 가져올 수 있는데, 이를 이용하면 충분히 직관적인 스크롤 이벤트를 구현..
수많은 사용자가 사용하는 웹 사이트가 있다고 가정해보자. 이러한 웹 사이트는 수많은 유저들에 의해 다양한 요청이 서버에 도착할 것이고, 서버는 이에 맞는 응답을 네트워크를 통해 전달할 것이다. 네트워크의 제한된 대역폭에 비해 출력량이 많아진다면 당연하게도 네트워크 지연이 발생하게 된다. 즉 대역폭 병목현상이 발생하게 된다. 물론 이벤트성 페이지에서 12시 정각에 상품 구매창이 열린다던지, 대학 수강신청과 같이 한 순간에 대량의 유저가 몰리는 경우와 같이 어쩔수 없이 지연이 발생하게 되는 상황은 지연이 발생할 수 밖에 없는 과정을 인정하고 이에 대한 해결책을 강구해야할 것이다. (이벤트 페이지의 구매창 클릭 버튼을 맨 밑에 위치시키는 등으로 급격하게 너무 쉽게 사용자가 몰리는 상황을 예방하는 방법도 있겠다..
평소와 같이 이미지 파일을 업로드하는 과정에서, 갑자기 cors 에러가 발생하더니 추후 image 의 네트워크 탭을 확인해본 결과 413 Request Entity Too Large 에러가 발생하였다. 원인을 생각해보니 처음보는 에러여서 당황하였지만, 의미를 해석해보니 용량이 너무 커서 요청할 시 에러가 발생했다는 것을 보고, 이미지의 용량이 너무 커서 발생한 문제겠구나 생각했다. 그런데 같은 이미지를 예전에 업로드할 때는 이러한 오류가 발생하지 않았는데, 현재 처음으로 발생하고 있고, 이전과의 차이점이 무엇일까 생각했을 때 nginx 셋팅이 떠올랐다. nginx 는 기존 프론트나 백의 서버에서 앞단에 서버 하나를 더 추가한다고 생각하면 되는데, 이 nginx 는 node 를 통해 다루는 절차를 제외한 ..
useEffect 는 컴포넌트의 라이프사이클을 함수형 컴포넌트 내에서 조절할 수 있도록 제공되는 react hook 중 하나이며, 실제 react 로 컴포넌트를 구현하는 과정에서 아주 유용하고 자주 사용되는 hook 이라고 할 수 있다. 매 컴포넌트가 랜더링 될 때마다 필요한 sideEffect 를 다룬다던지(서버와의 통신), state 나 props 의 변화로 인한 다른 요소의 업데이트가 필요한 경우, 실제 컴포넌트가 unmounting 될 때의 상황에서 useEffect 는 필수적으로 활용되곤 한다. 그치만 실제 작업을 해보다보면 알겠지만, 이것저것 기능을 추가하고 서로 연계를 하다보면 어느새 컴포넌트 내 useEffect 가 너무 과다하게 사용하고 있는것은 아닌가 의문이 들 때가 있다. 필요해서 사..
새벽 늦게까지 작업을 하다가 이제 마무리하려고 mysql workbench 내에서 실험적으로 저장하였던 데이터들을 삭제하던 도중 갑자기 workbench 의 연결이 끊키게 되었다. 다시 restart 를 해보려고 하니 위와 같은 오류가 발생하였다. PID 파일이 업데이트 되기 전에 서버가 종료되었다는 의미인데. 뭔가 급작스럽게 종료가 되면서 발생한 문제가 아닌가 싶다. 근데 난 mysql server 를 종료한 적이 없는데... 맥북의 문제인가 싶긴 하다. (뽑기를 잘못한것을 최근에서 느끼고있다!) 다음날 오전까지 계속해서 오류에 대한 해결책들을 나름 적용시켜보았지만, 해결되지 않았고 그동안 좀 이리저리 mysql 를 건든적이 있어서 이참에 과감하게 mysql 를 다시 삭제하고 설치하기로 마음을 먹었다...
이전 포스팅에서 redux를 간단하면서 의사코드 수준을 구현하면서 설명한적이 있다. 매번 리덕스를 사용할 때마다 action, dispatch, reducer 등등 용어부터 햇갈리면서 그 흐름 역시 파악하기 쉽지 않았는데, 구현 경험을 토대로 좀 더 리덕스에 가까워진 느낌을 받았었다. 이후 리덕스의 사용 시간을 점차 늘려나가면서 코드적으로도 익숙해지고 있는 중이다. 리덕스를 구현해보면서 느낄 수 있었던 점 중 또 하나는 리덕스는 동기적인 흐름이라는 점이다. dispatch 를 통해 실행된 reducer 는 순수함수이기에 동기적이다. 즉, 상태값에 대한 예상된 결과값을 도출하기가 쉽다는 장점이 있다. 하지만 서버와의 연결 등 비동기적으로 상태값을 변경해야할 상황이 많이 있다. 아무리 좋은 원격 상태관리이념..
