내가 찜하기 기능 API를 구현하면서 서비스 단에서 작성한 코드이다.
LIKE API 를 작성하기 전에 http 메소드 중 POST(생성), PUT(데이터 전체 변경), DELETE(데이터 삭제), GET(리소스 조회), PATCH(데이터 일부 변경) 등의 메소드들이 본래 정해진 목적대로만 사용할 수 있다고 생각했다.
그래서 중복하여 클릭했을 경우, 데이터를 삭제하는 API를 만들고 싶었고, 하나의 기능에 하나의 행위! 라는 엄청난 고정관념을 고수하며 다음과 같은 방식을 고안했었음에도 불구하고 코드 한줄 치고 있지 않았다.
계속해서 나의 짱구를 굴려봤자 저 고정관념 하나로 복잡한 해결방법만 나올 뿐, 어떠한 결론에도 다다를 수 없었다.
그러다가 멘토님께 이러한 기능을 하는 API를 구현하고 싶은데 어떻게 할 지 잘 모르겠다. 라고 했더니 like 테이블에서 내부에 동일한 상품과 유저의 튜플이 없을 경우, 있을 경우에 따라 다른 실행을 하면 된다고 말해주셨다. (응????)
내 결정권과 경험의 부족, 약간의 보수적인 태도에서 나온 이번 깨달음은 이후의 내가 더 유연한 사고로 다양한 기능들을 구현할 수 있게 하는 시발점이 될 것이다.
이 프로젝트의 깨달음이, 나에게 큰 자산이 되길 빌면서! VELOG 작성!
const addLike = async (user, productId) => {
let result;
const check = await likeDao.checkLike(user, productId);
//동일 user와 상품으로 구성된 like가 존재하는지 체크한다.
if (check.length) {
result = await likeDao.deleteLike(user, productId);
//동일 user와 상품으로 존재하는 like가 있을 경우, 찜을 삭제한다.
} else {
result = await likeDao.putLike(user, productId).insertId;
} //없을 경우 생성한다.
return result;
};- likeService.js 중 찜하기 데이터 생성 부분 발췌
LIKE API를 작성하며 깨달은 점
- 조금 더 유연한 사고가 필요하다.
고정관념을 깨고 좀 창의적인 사고를 해보자! - SERVICE 로직에 대한 이해
다만 비즈니스 로직이니까...으로만 이해했고, 그게 없을 시 모든 것을 다 다오단에서 처리했던 처음의 나.
하지만 이 LIKE API를 만드는 과정에서확장성 있는 코드와심도 깊은 코드의 필요성에 대해서 이해할 수 있었다.
조금 더 행복하고 즐거운 개발 생활을 위해, 내가 쓰는 도구들과 친해질 필요가 있겠다고 생각했다.
언제나 멀었을 때 알지 못했던 즐거움들은, 더욱 가까워지면 왔었는데 기억의 휘발성 때문인지 인지하지 못하고 있었다. 더 친해지자, 네트워크!
개발은 나에게 어느것보다도 큰 즐거움이다.
즐겁고 재미있는 개발을 위해 조금 더 아프고 힘들 수 있지만, 그만큼 더 많이 보고 익숙해지자.
