서론

🔗 linkav.net

이전에 Springboot와 Next.js 글에서 풀스택을 개발한 경험을 적었었는데
해당 프로젝트에 대한 소개이다.

최소한의 기능만을 갖춘 상태라 초라하고 보잘것없을 수 있으나
그래도 이런 때 글을 남겨두면 나중에 다시 봤을 때 재밌어서
자기만족반 + 소개용반 감성으로다가 글을 적어보려고 한다.

LinkAV (Link Archive Vault) 는 어떤 서비스?

LinkAV는 링크를 저장하고 관리할 수 있는 서비스이다.

약자에서 드러나듯이 (Vault는 hasicorp의 vault에서 따왔다)
브라우저에서 히스토리나 북마크로 관리하고 싶지않은 url들을

web에서는 대시보드
~~chrome-extension에서는 단축키 + 팝업~~ (준비 중이다 ✊✊)

위와 같은 방식들로 편리하고 안전하게 관리할 수 있다.

더 설명이 필요없을 것 같다.
말보다는 눈으로 보는 게 쉽고 빠르다.

지면 소개

Landing Page
Sign In & Sign Up
Dashboard

Landing Page

랜딩페이지를 만들어 봤다.
참고한 디자인은 아래와 같다.

Upstash
- Typography에 gradation을 주는 것
Typehero
- Header 영역 컨셉

헤더영역의 경우 일단 Dashboard 도메인에서는 공유가 된다.
sticky하게 만들지는 고려중이다.

헤더영역 오른쪽에 위치한 AccountBox 영역은
Login과 Signup을 드러내서 분리했다.

검색을 해본 결과 DropdownMenu로 처리하거나
그냥 버튼을 한개만 두고 리다이렉션 된 곳에서 Tabs로 처리하는 방식도 있었다.
추후에 고민해볼 지점인 것 같다.

보다시피 기능이 Dashboard 하나뿐이라 헤더가 휑한 것을 볼 수 있다.
하나씩 채워나갈 생각이다.

Landing Page의 AccountBox에서 Sign In과 Sign Up을 누르면
위와 같은 카드뷰가 나타난다. main영역만 교체되는 것이다.

여러 에러 핸들링에 대한 Toast와
zod validation error로 생성되는 FormMessage 등
세부적인 사항들은 생략했다.

Sing In과 Sing Up의 차이가 잘 구별되지 않아서
이 지점도 개선해야할 사항인듯 하다.

Dashboard

이렇게 설계한 주요 목적은 다음과 같다

쉽게 URL을 추가 / 수정 / 삭제할 수 있어야 한다
추가한 URL을 쉽게 클릭할 수 있어야 한다
각 URL은 category가 지정가능해야 한다
지정된 category는 각 URL 카드별로 직관적으로 보여야 한다

Video Card

Table과 Grid Card 뷰 사이에서 갈등이 좀 있었으나
클릭하기 쉽고 직관적으로 보여야 한다는 생각 때문에
후자로 결정했다.

위의 사진은 카드 안 오른쪽 상단의
DotsVertical 아이콘을 눌렀을 때 나타나는 뷰이다.

직관적으로 수정하고 삭제할 수 있도록 카드 안쪽에 배치했다.

Video Update & Delete Dialog

직관적으로 Update와 Delete를 할 수 있다.

Update의 경우 카드가 가지고 있는 state들을
input의 defaultValue로 넣어주는 동작이 구현되어 있다.

Add Link

대시보드 왼쪽 상단의 Add Link 버튼을 누르면
위와 같은 Dialog를 만들어 준다. Update Dialog와 거의 유사하다.

Avatar

Filter & Pagination

아직 구현이 되지 않았다. 이유에는 다음과 같은 것들이 있다.

1. api 디자인의 결함

bad-rest-api-design

일단 보다시피 api 디자인이 좋지 않다.

versioning이 되어있지 않다
어떤 것은 param으로, 어떤 것은 dto로 처리한다
- 정확히는 명확한 컨벤션 및 기준에 의거한 판단을 하지 않았다
필터와 페이징을 처리하도록 구현되어 있지 않다
ETC
- GlobalExceptionHandler 및 ControllerAdvice에 대해
  validation (@Valid) 플로우가 제대로 잡혀있지 않다

위와 같은 문제들이 있는데 이들을 기능 추가 전에
먼저 리팩토링 하면서 잡아내고 싶었다.

2. 선행되어야 하는 리팩토링들

비단 Controller 문제만은 당연히 아니다.

이번에 리팩토링을 하며 Mapstruct와 QueryDSL을 도입했고
이에 맞춰서 Service, Repository 또한 수정을 해야한다.

entity에서 lazyloading과 관련한 N+1 문제
QueryDSL 레벨에서 Projection을 해서 service로 보내기
- 현재는 어떤 것은 entity를 그대로 리턴하고 어떤 것은 dto로 리턴한다
점점 불어나는 dto들을 inner class로 리팩토링
dto에 대한 naming convention을 잡아주기

이런 것들이 먼저 선행되어야 한다고 생각했다.

나머지 후기

FE에 좀더 깔끔한 구조를 ..

이번 릴리즈를 하며 조금 더 clean한 아키텍쳐를
FE에서 유지하도록 리팩토링 했다.

BE에 Category라는 새로운 Entity가 추가되면서
FE쪽에서 날리는 service, dto, zod의 schema 들도 같이 수정해야 했고
겸사겸사 리팩토링을 진행했다.

eza로 Tree를 긁어와 봤다.

❯ eza -T -L 2 -I "node_modules|docs|scripts|README.md|*.js|*.json|*.yaml|*.mjs|*.ts|*.tsx|*.css"
.
├── app
│  ├── api
│  ├── dashboard
│  ├── signin
│  └── signup
├── components
│  ├── auth
│  ├── common
│  ├── dashboard
│  └── ui
├── dto
├── hook
├── lib
├── public
│  └── images
├── service
├── state
├── styles
├── test
│  ├── e2e
│  ├── integration
│  └── unit
└── types

테스트에 대하여

BE 작업을 해놓고 FE에서 작업을 하다보니
어쩔 수 없이 예상하지 못한 api 설계들과 예외 처리들이 추가됐다.

뿐만 아니라 이러는 과정에서 놓쳤던 실수 지점들이 발견되고
이에 수정을 하다보니 테스트 코드들이 많이 깨지게 되었다.

모두 통과하던 45개의 테스트에서 9개가 실패하는 상태

이 글 서론에서 언급한
테스트 플로우는 부채로 남게 되었다.
왜냐면 테스트 작성말고도 해내야 하는게 산더미로 쌓여있기 때문이다.

아마 난 당분간 ci에서

./gradlew clean build -x test

를 하지않을까..

물론 domain -> repository -> service -> controller 흐름으로
unit / integration 테스팅 하는 방식과 흐름을 학습한 것은
좋은 자산으로 남을 것임은 분명하다.

mock을 해나가며 stub 객체를 셋업해서
테스트가 실패하는 케이스를 작성해
성공하게끔 코드를 짜내가는 과정은 흥미로웠다. 그리고 실제로 도움이 되었다.

동시에 초반에 의미없이 짜버린 테스트코드들 또한 많았다.
그래서 시간을 어느정도 날려먹은 것 또한 사실이다.

Storybook을 도입하자

추가로 글을 쓰면서 느낀건데 storybook을 도입해야겠다는 생각이 들었다.

현재 도메인이 1개고 컴포넌트가 많지 않아서 다행이지
컴포넌트가 훨씬 많아지고 플로우가 다양해지면
답이 없을 것 같고 앞으로 포스팅이 불가능할 것 같다.
(Figma로 관리중이지도 않기에 더욱 그렇다.)

마무리

사실 이 서비스의 진짜 핵심은 chrome-extension에 있다.
chrome-extension만이 해줄 수 있는 강력한 기능들이 너무 많기 때문이다.

시작할 때 웹을 먼저 프로토타이핑 해서 mvp를 달성하는 걸 목표로 잡았었고,
이제 그 목표까지 task는 3개가 남았다.

Filter, OrderBy, Pagination
OAuth 로그인 방식 추가
Rate Limit

달성 후에 익스텐션 개발을 다시 가속화 해보려고 한다.

🚀 LinkAV Beta 릴리즈 🚀

서론