RISK IT

레이어 별 발생 에러 1. Controller Error 컨트롤러는 표현 계층, 즉 입력과 출력에 관련한 부분을 담당. HTTP 통신을 처리하는 웹 서버의 관점에서는 http request (요청 입력), http response (응답 출력)을 담당하는 레이어이다. 따라서 통신이 처음 시작될 때, 사용자로 부터 받은 정보를 클라이언트(프론트엔드)가 전달해주면, 해당 입력에 대한 유효성 검증을 처리하며 에러 및 예외가 발생할 수 있다. 예시 KEY_ERROR가 대표적 사용자 입력이 잘못되었다면, 주로 400번대 http status code를 보냄 2. Service Error 서비스 레이어는 주로 비즈니스 로직과 규칙을 설정하는 곳. 이 곳에는 보통 기획에 따른 비즈니스 규칙에서 비롯된, 개발자가 직접..

작업 내용 상품 정보를 불러오는 엔드포인트를 리팩토링 하는 작업을 진행중이었다. 특정 서브 카테고리의 상품 조회와 필터링(query parameter) 기능을 구현 완료하고 다른 엔드포인트들도 포스트맨으로 실행시켜보았다. 그런데 productId로 상품 디테일을 불러오는 엔드포인트가 갑자기 작동하지 않는 문제가 발생했다. 상품 디테일 조회 엔드포인트는 처음에 잘 작동했고, 이번에 건들지도 않았는데 자꾸 통신이 실패하는 것이었다. 2월 9일에 올린 TIL에 적었듯이 잘 조회가 됐던 내용이었다. (그 후로 테이블에 main, sub category id도 추가) ⬇️ 제품 상세 페이지 조회 코드 const getProductById = async (productId) => { return await mysq..

작업 내용 어제 상세페이지 조회까지 잘 마무리 하고 PR를 올렸는데, 엔드포인트를 수정하라는 리뷰를 받았다. 우선 새로 두 가지를 알게 되었다. 첫째, 엔드포인트와 url이 같은 것인줄만 알았는데, 그렇지 않았다. 둘째, query parameter 사용법 1. 엔드포인트와 URL 보통 url 과 uri의 차이로 구분짓는다. uri가 url을 포함하고 있는 상위 개념이다. 엔드포인트는 uri에 포함된다. 따라서 엔드포인트와 url이 같지 않을 수도 있다. 2. query parameter 지금까지 나는 path parameter를 사용했었다. query parameter는 특정 조건의 상품을 조회하는 필터링 작업이 필요할 때 많이 사용한다.

작업 내용 제품 상세 페이지에 필요한 정보를 불러오는 쿼리문을 작성했다. 굉장히 많은 테이블의 조합이라서 쉽지 않은 작업이었다. 내가 할 수 있을까 하는 생각도 들고, 머리도 싸매면서 많은 시간을 들여서 작성했다. 그러다 원하는 결과가 마침내 나왔을 때의 쾌감 때문에 개발자를 하는 것 같다. 오늘 작성한 코드 중 제일 긴 쿼리문 하나. ⬇️ 제품 상세 페이지 조회 코드 SELECT p.id, sub_c.name AS sub_category, sub_cat.name AS main_category, p.name, p.image_url, p.description, prod_f.feeling_of_use, prod_s.scents, p.main_ingredient, p.ingredient, prod_o.opti..

작업 내용 데이터베이스 구축 작업이 merge된 이후에 상품 조회와 관련된 쿼리문을 작성하기 시작했다. Foundation 1, 2차 때도 SQL 과제를 열심히 따라가긴 했지만 제대로 이해했다는 느낌은 없었다. 그래서 그런지 query문 작성하는게 쉽지는 않았다. 물론 지난 번에 고민했던 내용들이 있어서 확실히 성장한 느낌은 들었다. 기본 products table에 있는 상품 조회하는 코드, sub 카테고리별로 조회하는 코드를 작성해 보았다. 아래 예시는 메인 카테고리의 상품들을 조회하는 코드 const getProductsForBodyHands = async () => { return await mysqlDataSource.query( ` SELECT p.sub_category_id, JSON_ARR..