BE기술 선택 근거

PackageManager

• npm 🥇
  • 가장 익숙하며, 압도적인 점유율로 활발한 커뮤니티 생태계에서 도움을 받을 수 있음.

Web Framework

• NestJS 🥇

  • 가장 큰 대안인 Express에 비해 구조화된 아키텍처를 가짐. 이러한 구조는 개발자로 하여금 일관성있고 안전한 코드를 작성할 수 있는 예방책이 되고, 큰 프로젝트일 수록 이러한 예방책은 있는것이 좋다고 생각함.
  • DI Container가 존재하는 프레임워크를 사용해보고 싶었음.
  • JavaSpring과 가장 유사한 패턴과 구조를 가졌음. 팀원들 중 Java Spring 유경험자가 있었고, 비교적 빠른 적응을 위해 선택함.

• Express

  • 구조가 매우 간단하며, 높은 생산성을 가짐.
  • 개발자가 거의 모든부분을 직접 핸들링 할 수 있음.
  • 리소스가 가볍고, 빠른 성능을 보여줌.

Language

• TypeScript 🥇
  • 앞서 선택한 NestJS가 Typescript를 사용하는것을 중심으로 개발된 프레임워크임.
  • 타입의 강제성을 부여하고, Interface, Enum 등 기존의 Vanilla js에는 존재하지 않는 다양한 OOP적 프로그래밍이 가능해짐.
  • OOP를 따르는 것이 협업간 간편한 구조화, 높은 가독성(작업 효율성), 잘 형성되어있는 생태계 등의 이유로 타당하다고 생각함.

ORM

• TypeORM 🥇

  • 전통적인 Object-Relational 매핑 방식을 가진 ORM으로, Spring의 JPA와 흡사한 구조를 가짐. (이 역시 JPA경험이 있는 캠퍼들이 있었음.)
  • 여러가지 기본적인 CRUD쿼리를 위한 인터페이스를 제공함.
  • Prisma가 제공하는 다양한 TypeORM의 한계점을 돌파하기 위한 부분들은, 필요성을 느낀 후 마이그레이션 해도 늦지 않다는 의견이 수립됨.

• Prisma

  • TypeORM과 같은 전통적인 ORM의 다양한 고질병(지연 로딩, 엔티티 모델 등...)을 해결하기 위해 다양한 기능들을 제공함.
  • 더욱 높은 추상화 레벨로, DAO 계층에서 더 가독성 높은 코드를 작성할 수 있음.

DBMS

RDBMS 자체는 어떤것을 사용해도 크게 상관없다는 의견이 주류였음.

• MySQL 🥇

  • 대부분의 캠퍼가 사용해본 경험이 있는 DBMS를 사용하는 것이 6주라는 제한된 기간안에 생산성 측면에서 좋을 것이라 기대했고, 이 조건에 부합하는 것이 MySQL 뿐이었음.

• PostgreSQL

  • 논리적인 서버 분리가 가능함.

InMemory DB

• Redis 🥇
  • 다양한 데이터 타입을 지원하며, Pub/Sub 기능 역시 강력하게 지원함.
  • 영속성을 지원하는 여러가지 방법이 존재함.
  • 역시나 가장 안정적이고 널리 사용되는 기술이며, 많은 Best-Practice 레퍼런스들을 기대할 수 있음.

Cloud

• Naver Cloud Platform 🥇

  • 부스트캠프측에서 무료 크레딧을 제공함.
  • 대부분의 기능을 지원하고 있음.
  • 다만 비용이 조금 비싼편이라, 추후 크레딧이 모두 차감되면 AWS로 이전하자는 의견이 수립됨.

• AWS

  • 압도적인 점유율, 다양한 레퍼런스, 기술적 지원
  • 비교적 저렴한 비용

CI/CD

• Github Actions 🥇

  • Github 친화적이며, 간단한 스크립트만으로 다양한 동작들을 구현할 수 있음.
  • 마켓플레이스서 다양한 액션들을 제공함.
  • Github Actions를 사용해본 경험이 있는 캠퍼가 있었음.
  • 비교적 다양한 커스터마이징을 제공하는 Jenkins에 비해 우리 서비스는 Github Actions 만으로도 원하는 동작을 모두 구현할 수 있으리라 생각함.

• Jenkins

  • GitHub 뿐만 아닌 다양한 SCM도구와 통합이 가능
  • 전통적인 CI/CD 파이프라인 구축용 도구이며, 그에 따라 방대한 양의 레퍼런스와 커뮤니티가 존재함.