bysxx / next14-ts-template-fullstack

⚡ Fullstack Next.js 14 + TypeScript + MongoDB Template (with SEO)

About Me 👋

• 저는 프론트엔드 중심의 소프트웨어 엔지니어 백윤성입니다.
• Next.js 13+, TypeScript를 주로 사용하여 웹 애플리케이션을 설계 및 개발하고 있습니다.
• Server Components, Suspense, Server Action과 같은 기술에 관심이 많습니다.

---

Latest Posts 📰

• Waku | 가장 작은 리액트(SSR) 프레임워크
• 2024년 1분기 회고
• 프론트엔드 출신의 CTO는 왜 없을까
• 레거시 코드는 회사가 살아남았다는 증거다
• React의 Virtual DOM은 어디에 저장될까?
• React 19가 다가온다
• 2024 프론트엔드 트렌드
• 2023 개발자 회고
• 배민도 React Native 해요? - 우아콘 2023
• localhost를 벗어나자

next14-ts-template-fullstack's Issues

Review

리뷰 전, 저는 몽고 디비에 대한 지식이 전무한 점 참고 부탁드립니다 (__)

서버 개발자가 본 api 구성에 대한 생각입니다. 정답은 아니고, 참고 정도만 하셔도 됩니다 :)

1. 매우 소규모 프로젝트일 때 유효할 것 같다.

• 우선 모듈 복잡도와 외부 의존성이 늘어나면 안정성이 많이 떨어질 것 같습니다. 근데 이건 풀스택 프로젝트라면 안고가야하는 문제 같기도 합니다.

2. 제가 코드를 잘 이해한 건지 모르지만, db-connect 함수가 디비 커넥션을 캐싱으로 유지시키는 커넥션 풀 역할이라고 생각했습니다.

• 제가 이해한 것이 맞다면 이 풀 사이즈가 조정될 수 있으면 좋을 것 같습니다.
• 또한, db-connect가 실패했을 때, 재요청 로직도 있는 것이 어떨까 싶습니다.
• 사실 ORM을 사용하지 않으신 이유도 그런 점에서 궁금했습니다. ORM에서는 이런 기능을 모두 지원하고 있습니다.
• 제가 잘못 이해한 것이라면 무시해주셔도 됩니다(__)

3. ( 물론 Example이라서 아주 간소하게 만드셔서 그런 걸수도 있지만 ) 데이터베이스, GCP, AWS 와 같이 외부 의존성을 갖는 비즈니스 로직이 있다면, 해당 외부 의존성을 감싸는 모듈을 구성하고, 이 모듈을 주입받는 서비스 계층을 따로 분리하는 것을 추천드립니다.

• API 와 가장 가까운 서비스 계층을 두고 여기에 외부 의존성 서비스 계층과 비즈니스 로직을 담는 서비스 계층을 각각 주입하여 관리합니다.
• 이렇게 했을 때의 장점은 side-effect 를 발생시키는 외부 의존성 서비스가 캡슐화되어있어서, 비즈니스 로직을 담는 서비스 레이어만을 테스트해볼 수 있는 것 같습니다.
• 물론 외부 의존성을 캡슐화했으니, 재요청 이나 정교화 에러 핸들링을 통해 내부적인 안정성을 높일 수도 있을 것 같습니다.