당신의 친절한 이웃, 코딩맨

당연히! 중복 요청, 필요 없는 요청은 줄이는 게 맞다. 개발할 때도 그렇고, 테스트할 때도 반드시 신경 쓰는 게 프런트 엔드 개발자라면 가져야 할 기본 소양 아닐까?지금 서비스는 탠스택 쿼리 (Tanstack Query)를 쓰고 있다, 캐싱에 짜릿함을 맛보고 UX를 개선했다는 즐거움을 느끼고 있는 와중. api 요청 수를 줄여달라는 요청이 프런트 팀에게 왔다. 현 상황에서 서비스를 전체적으로 보았을 때, 필요한 요청만 보내고 있어보였다. 여기서 앞으로 확장성을 가지고, 유지 보수성을 챙기면서도 요청수를 잘 관리할 수 있는 방법이 있을까 했지만 쉽게 떠오르지 않았다.클로드 코드도, 코덱스도 원하는 답변이 없었고, 요청 하나하나 '깎는 느낌의 작업들을 추천해 줄 뿐이었다' 이런 방식은 이런 상황은 요청을 ..

프런트엔드에서 상태관리는 늘 쉽지 않았다. 그리고 계속 쉽지않아진다.처음에는 redux-toolkit이 가장 안전한 길처럼 보였다. 표준화된 구조, 많은 레퍼런스, 팀원들도 익숙했고.하지만 프로젝트가 커지면서 “안전함”보다 “답답함”이 더 크게 느껴지기 시작했다. 내가 담당한 내부 관리툴은 리스트/검색/필터/페이지네이션이 기본이고,여러 곳에서 같은 데이터를 읽고 쓰는 화면들이 많았다.이런 화면에서 redux-toolkit은 이렇게 느껴졌다.slice가 늘어나고 action이 늘어난다서버 상태와 UI 상태가 한 덩어리처럼 섞이기 시작한다“불러오는 데이터 속도가 저하되면서 개선을 내가 할 수 있는게 있을까?” 라는 의문이 계속 든다그러다 결론이 났다.클라이언트 전역 상태와 서버 상태는 분리하자.그리고 그 기..

프런트 엔드 개발자들은 보통 여러 개의 레포지토리를 갖게 된다. 이유는 다양하다. 서비스가 다양할 수 있고, 기존의 서비스를 여러 개로 분할해서 배포/관리하거나, 내부 업무를 위해 화면을 만들 때도 있기 마련이다. 내 예시로는, 패치 로그를 기록하고 검색해서 볼 수 있는 패치 로그 사이트, 서비스 화면, 관리툴, 권한툴, 디자인 시스템,... 이외에 몇 개 더 있다. 레포지토리가 많아지면 과연 좋을까? 처음엔 독립적으로 여러개의 툴을 따로따로 관리해서 작업하는 레포지토리가 분리되니까 더 효율적일 것이라 생각했다. 쉽게 생각하면 프런트 개발자 5명이서 5개의 레포지토리에서 작업을 하니 절대 컨플릭트 날일도 없고, 독립된 환경에서 병렬로 일이 진행된다 생각했었다. 문제는 사소한 곳에서 시작된다. 각각 레..