Web Audio API

• 음성편집과 관련하여 별도의 라이브러리를 사용하지 않기로 요구사항에 존재하여 Web Audio API를 활용

Sass

• CSS Pre-processor를 활용하여 스타일링 하기로 결정.
• 웹팩 설정을 통해 번들링 하여 사용

canvas

• 오디오 파형을 자르거나 복사하거나 붙여넣기 등 다양한 편집 인터렉션이 필요한데 성능면에서 canvas가 유리할 것이 판단
• 오디오 파형을 조작하는데 시간대에 따라 픽셀 단위로 조절해도 충분할 것이라 판단

Vanila JS

• 라이브러리, 프레임워크 없이 자바스크립트 만으로 프로젝트를 구현하기로 결정

React.js

• 프로젝트 특성상 단일 페이지형태이며 SPA로 개발할 필요가 없다
• React의 장점은 빠른 렌더링 속도에 있는데 프로젝트에서 빈번한 렌더링이 일어나는 부분은 오디오 파형을 그려주는 부분이다. canvas로 파형을 그려주기 때문에 어차피 다시 그려주고 렌더링하므로 이점을 얻기가 미미하다고 판단.
• 프레임워크, 라이브러리 활용없이 Javascript로만 구현하기로 결정

React-Router

• 단일페이지 형태이고, 추후에 login페이지가 추가된다 하더라도 페이지 수가 적기 때문에 React-Router를 사용할 필요가 없다고 판단.
• 무작정 라이브러리를 사용하면 프로그램이 무거워지고, 동작이 느려질 수 있다. 추후에 로그인 기능을 통해 페이지가 필요하다면 history API를 활용하여 직접 클라이언트 라우팅을 구현하기로 결정

Redux

• Redux를 활용하려면 학습 비용이 존재하고, flux 구조를 활용하면서 프로젝트가 복잡해질 수 있다.
• 프로젝트의 특성상 복잡한 상태관리가 필요없을 것이라 판단하여 Observer or Pub/Sub 패턴을 활용하여 상태관리 store를 구현하기로 결정

Styled-components

• React를 사용하지 않으면서 자연스럽게 사용하지 않기로 결정

Nginx

• 로그인 없이 온라인으로 오디오 파형을 편집할 수 있도록 로그인 기능을 구현하지않기로 결정.
• Nginx를 활용하여 정적파일만 제공하기로 결정

로그인 기능을 구현하지 않기로 결정하여 백엔드 프로젝트 삭제

• Node.js
  • Express를 활용하여 백엔드 API 서버를 구현하기로 결정
• TypeORM
  • TypeScript를 도입하면서 백엔드도 TypeORM을 도입하여 견고한 백엔드 서버를 구축하기로 결정
• MySQL
  • 배포서버는 MySQL을 활용하기로 결정
• SQlite
  • 로컬 개발용으로는 빠르게 개발하고, 테스트 할 수 있도록 하기위해 SQlite를 사용하기로 결정
• pm2
  • pm2를 활용하여 백엔드 서버 프로세스 관리를 하도록 결정

• 테스트 라이브러리는 Jest를 활용하기로 결정

• TypeScript를 도입하여 타입 정의를 통한 안정적이고, 자동완성 및 코드의 가독성을 높여서 생산성 향상 및 좋은 개발경험을 얻기위해 사용하기로 결정

• 코드의 일관성을 유지하기 위한 lint 설정을 하기로 결정
• prettier를 설정하여 코드의 포맷팅과 관련해 prettier의 자동 수정 기능의 도움을 받아 코드의 일관성을 맞추기로 결정
• lint-prettier 통합설정을 통해 lint로 코드의 품질을 검사하고, prettier로 포맷팅을 검사하여 수정하기로 결정