이제 마지막으로 Add 페이지에서 의류를 데이터에 저장할 때와, Details 페이지에서 데이터를 수정하여 데이터베이스에 저장하는 과정에 대해서 포스팅하고자 한다. 이번 포스팅을 마지막으로 Add, Details 페이지에 대한 구현 과정도 마무리 하려고 한다. 전체 테이블 구조도 데이터 저장은 테이블을 잘 확립하였다면 어렵지 않다. 시퀄라이즈의 테이블 관계가 잘 맺어져 있다면 알아서 잘 저장되기 때문이다. 기본적으로 현재 구성된 테이블관계는 복잡하지 않다. 의류의 전반적인 데이터를 나타내는 테이블이 있고, 각 의류마다 저장되는 여러장의 이미지를 저장하는 테이블, 의류의 카테고리마다 입력된 실측 데이터를 저장하는 테이블로 구성되어있다. 한개의 의류를 저장할 때 여러개의 이미지가 있을 수 있다. 따라서 의류..
앞서서 이미지를 서버에 업로드하고, multer 를 통해 이미지를 저장한 다음, vision AI 를 통해서 현 이미지를 분석하여 이미지의 주소와 분석결과를 클라이언트에서 받아 Preview Card 를 렌더했었다. 그리고 그 전 이미 의류이름과 가격 등등 입력값들을 React-Hook-Form 을 통해서 관리하고 있었고, 이제 실제 데이터베이스에 입력값을 저장할 일만 남아있다. 그리고 저장된 의류 데이터를 수정할 수 있어야 했기에 기존 입력 데이터를 불러와 input 창에 기입되어 있는 상태로 렌더하는 경우도 고려해야했다. 정리해보자면, 받아온 이미지 주소와 함께 React-hook-form 에서 관리하는 입력값들을 서버 데이터베이스에 저장 상세 페이지에서 정보를 수정하고자 할 경우, 수정 이벤트 발생..
평소와 같이 이미지 파일을 업로드하는 과정에서, 갑자기 cors 에러가 발생하더니 추후 image 의 네트워크 탭을 확인해본 결과 413 Request Entity Too Large 에러가 발생하였다. 원인을 생각해보니 처음보는 에러여서 당황하였지만, 의미를 해석해보니 용량이 너무 커서 요청할 시 에러가 발생했다는 것을 보고, 이미지의 용량이 너무 커서 발생한 문제겠구나 생각했다. 그런데 같은 이미지를 예전에 업로드할 때는 이러한 오류가 발생하지 않았는데, 현재 처음으로 발생하고 있고, 이전과의 차이점이 무엇일까 생각했을 때 nginx 셋팅이 떠올랐다. nginx 는 기존 프론트나 백의 서버에서 앞단에 서버 하나를 더 추가한다고 생각하면 되는데, 이 nginx 는 node 를 통해 다루는 절차를 제외한 ..
이미지를 업로드 하는 방법에 대한 고민을 해결하였으니, 이제 실제 이미지를 서버에 업로드 하면서 추가적으로 구현하고 싶은 목표를 이루도록 해보자. 목적에 맞는 의류 이미지를 업로드 할 수 있도록 가이드 하는 방법 이번 프로젝트에서 이미지는 중요한 역할을 한다고 생각한다. 실제 유저가 어떤 의류가 저장됬는지 가장 한눈에 살펴볼 수 있는 것이 이미지이고, 그렇기 때문에 의류를 저장하기 전에 Preview 를 보여주는것은 기본이며, 개인적으로는 혹여나 실수로 전혀 관련없는 이미지를 제출해버리는 것을 방지해주는 것도 좋지 않을까 생각했다. 의도는 좋으나 방법이 떠오르질 않았는데, 이미지를 파악해서 컴퓨터가 알아서 이미지를 분석해서 이 이미지는 의류인지 아닌지를 파악하는것을 지금 내가 직접 코드를 작성하기에는 무..
지난 포스팅때는 React-Hook-Form 을 활용하여 Add 페이지와 Detail 페이지 내에서 활용될 입력 컴포넌트 ItemForm 을 구현하였다. 구현하는 과정에서 의류 카테고리에 따라 실측 입력폼을 렌더해야 하는 문제에 대한 고민과 이를 해결하고자 어떤식으로 코드를 구상하였는지도 다루어 보았다. 다만, 아직 ItemForm 에서 해결해야 할 문제들이 남아있는데, 크게 3가지 정도라 할 수 있겠다. 의류에 대한 정보를 수정하고 싶을 때, 수정 버튼을 누르면 ItemForm 내 기존 의류의 정보가 기입되어있어야 하며, 수정하여 변경할 수 있어야 한다 중요한 부분이 이미지를 업로드 하는 과정인데, 우선 이미지 업로드 버튼 뿐 아니라 웹사이트 내에서는 이미지를 드래그에서 업로드 하는 방식도 추가하고 싶..
입력 폼은 웹페이지를 구성할 때 빠지지 않고 포함되며, 그렇기에 html 내 input 의 type 들 역시 기본적인 입력부터 시작하여 number, tel, select, color, file 등등 다양하게 존재한다. 상황마다 달라지겠지만 기본적으로는 이메일과 비밀번호를 입력하는 로그인부터, 유저의 다양한 정보들을 한번에 전송해야 하는 입력폼을 생성해야할 때도 존재한다. 진행중인 closet 프로젝트에도 입력폼은 반드시 포함되었어야 했는데, 당연하게도 로그인 및 회원가입때의 입력폼과, 프로젝트의 핵심이라 할 수 있는 의류들의 정보들을 입력하게 될 add 페이지와 입력했던 의류정보를 수정하게 될 detail 페이지에서 사용될 입력폼이 필요했고, 그렇기에 좀 더 입력폼을 구현하는데 수월한 방법이 없을 까 ..
Nest.js 를 통해서 각 페이지의 레이아웃을 설정하는 것은 간단하다. _app 에서 공통으로 들어갈 레이아웃을 설정해주면 모든 페이지에 레이아웃이 작용하게 된다. 다만 상황에 따라서 페이지마다 다른 레이아웃을 적용해야할 수도 있다. 예를 들자면 상단 Nav 컴포넌트를 Login 페이지에 포함시키고 싶지 않다면, Login 페이지는 이에 맞는 레이아웃이 적용이 되어야 한다. 하지만 _app 에서 레이아웃을 적용시킨다면 Login 페이지까지 레이아웃이 적용되어버린다. 편하게 레이아웃을 적용하려고 하는 노력이 오히려 불편한 상황을 야기한다! 다행이도 Next.js 는 이러한 상황을 고려하여 각 페이지에 따른 subLayout 을 적용할 수 있도록 설정 할 수 있는데, 이번 프로젝트를 진행하면서 Login ..
로그인 여부에 따라 페이지를 리다이렉트 하는 방법은 저번 포스팅에서 한번 다뤄본적이 있다. 문득 모든 페이지마다 getServerSideProps 를 통해서 redirect 를 지정하는 것이 아니라, 한번에 처리할 수 있는 방법이 있지 않을까 하여 찾다보니 Next.js 에서의 Middleware 에 대해서 알게 되었고, 실험적으로 사용해본 과정과 능숙하게 사용을 하지 못해서 느껴진 한계점을 한번 포스팅해보고자 한다. Next.js 의 middleware 미들웨어는 기존 express 에서 다루었던 것과 같이, 모든 요청과 응답 사이에서 작용을 한다. 미들웨어를 활용하면 응답을 받기 전 그 응답에 대하여 마음대로 커스터마이징을 할 수 있다. 캐쉬된 페이지를 로드하는것보다도 더 먼저 실행되기 때문에, 대표..
