백엔드
Language : TypeScript
Library & Framework : NestJS, Express.js
Test: Jest ,Supertest
Database : Mysql,erdcloud , DataGrip
ORM : TypeORM
Authentication: passport.js, JWT, 세션
Proxy Sever : Nginx
우선 이번 백엔드 파트에서 사용할 언어 및 프레임워크, 인프라들이다.
파트 별로 왜 해당 언어 와 프레임워크 인프라들을 사용했는지를 기록해보자.
Language : TypeScript
JavaScript에 타입을 추가한 언어
- 정적 타입 시스템
변수, 매개변수 및 함수 반환 값에 대한 타입을 명시적으로 지정할 수 있어 코드의 가독성을 높이고 버그를 미리 예방.
- 코드 예측 및 자동 완성
코드 작성을 돕는 개발 도구와 통합되어 있어, 코드 예측과 자동 완성 기능을 제공해서 빠르게 코드를 작성하고 실수를 줄인다.
- 타입 추론
변수의 타입을 자동으로 추론할 수 있어서 타입 지정의 번거로움을 줄여주고 필요한 경우 수동으로 타입을 명시할 수도 있다.
- 유지 보수 용이성
정적 타입 검사를 통해 코드 변경으로 인한 예기치 않은 오류를 방지하므로 유지 보수가 용이하다.
+ TypeScript 이슈 체크
현재 TypeScript가 퇴출될 가능성에 대해 대두 되고 있다.
그 원인은 데이비드 하이네마이 한슨(루비온레일즈를 만든 )이라는 분이 터보에서 타입스크립트가 퇴출 된다는 블로그 포스팅을 올렸다.
이미 해당 깃허브 터보 레포지토리에는 타입스크립를 제거한 뒤 마지까지 시킨 상태이다.
또한 Svelte4(프론트엔드 프레임워크)에서도 타입스크립트를 버린다고 한다.
위 사진과 같이 이미 해당 레포지토리에는 좋아요 보다 싥어요가 압도적으로 많은것을 알수 있다.
즉, 이미 너무 많은 사람들이 거부를 하고 있다는 것이다.
또한 Svelte4에서는 Svelte를 사용하는 과정에서 타입스크립트를 사용하지 못하게 한다는게 아니라 Svelte 개발하는 개발자들이 타입스크립트가 아닌 자바스크립트로 개발을 한다는 것이 과하게 소문이 난것 이었다.
즉, Svelte를 사용하는 일반 프론트엔드 개발자에게는 아무런 영향이 없는 이야기 인 것이다.
결론 : TypeScript를 사용안할 이유가 없다.
위 통계 자료는 rollbar 에서 정리한 자바스크립트로 개발한 프로젝트에서 가장 많이 발생한 에러 TOP10이다.
결론적으로 타입에러가 가장 많이 나기 때문에 저 통계자료 하나로만 봐도 TypeScript의 사용은 필수불가결하다.
Library & Framework : NestJS, Express.js
TypeScript를 사용하여 서버 사이드 애플리케이션을 빌드하기 위한 프레임 워크
- 모듈 기반 아키텍처
모듈 기반의 구조를 채택하여 애플리케이션을 컴포넌트로 나눌 수 있어 코드의 모듈화와 재사용성을 높일 수 있다.
라우팅, 컨트롤러, 서비스, 프로바이더 및 미들웨어를 하나로 묶는 기능을 제공하여 코드를 체계화하고 유지 관리에 용이하다.
- 의존성 주입
의존성 주입(Dependency Injection)을 지원하므로 클래스 간의 의존성을 쉽게 관리할 수 있어 테스트 가능한 코드 작성 용이.
- GraphQL 및 WebSockets 지원
RESTful API 뿐만 아니라 GraphQL 및 WebSockets를 지원하여 다양한 통신 프로토콜에 대한 서비스를 구축할 수 있다.
- 설계 및 테스트 용이성
모듈화된 구조와 의존성 주입을 통해 코드 설계와 테스트가 용이하며, 테스트 가능한 코드 작성이 쉽다.
- 확장성
NestJS는 강력한 확장성을 가지고 있어서 큰 규모의 애플리케이션을 구축하고 유지 관리할 수 있다.
주요 백엔드 프레임워크의 깃허브 STAR 현황
깃허브 스타의 history을 보면 nest의 스타 상승률이 높은걸 확인할 수 있다.
현재 2023.09.19일 기준 이미 djandgo를 제외하고는 스타수가 가장 많은것 또한 확인할 수 있다.
Django의 장단점
(장점)
파이썬 라이브러리 사용 가능
기본적인 기능들을 미리 만들어 제공해 쉽고 빠르게 개발
FullStack 이 가능
(단점)
파이썬 기반이다보니 속도가 다소 느리다
세세한 조정이 힘들다.
Django ORM만 사용할 수 있다는 점
Full System 지식이 필요하다는 점
NestJS 장/단점
(장점)
Express, Fastify와 호환된다는 점
TypeScript, OOP, FE 등이 지원된다는 점
좋은 아키텍쳐와 구조를 가지고 있어 처음부터 시작하지 않아도 된다는 점
(단점)
아키텍쳐로 인한 러닝커브
NodeJS에 비해 strict한 구성(NodeJS의 철학 : 간결함과 실용주의)
출처 : https://velog.io/@sinichy7/Django-vs-NodeJS-vs-NestJS
현재 NEST를 선택한 가장 큰 이유
1. 프론트엔드와 같은 언어(타입스크립트)로 개발
2. 이전 node(express)를 사용한 경험이 있다.
3. 국내 대기업에서 사용 압도적 1위인 spring과 비슷한 디자인 패턴
ORM : TypeORM
TypeScript와 JavaScript를 위한 객체 관계 매핑(ORM) 라이브러리로, 데이터베이스와의 상호 작용을 추상화하고 객체 지향적으로 다룰 수 있게 해주는 도구이다.
- 객체 지향적 접근
데이터베이스 테이블과 데이터를TypeScript 클래스와 객체로 매핑해줌으로써 데이터베이스 작업을 객체 지향적으로 수행.
- 다양한 데이터베이스 지원
다양한 데이터베이스 시스템을 지원하며, MySQL, PostgreSQL, MongoDB, 등과 같은 데이터베이스와 통합이 가능하다.
- 타입 안전성
TypeScript와 함께 사용할 때 TypeORM은 타입 검사를 통해 런타임 오류를 사전에 방지해 줌으로써
코드의 안정성을 높이고 버그를 줄여준다.
- 강력한 쿼리 빌더
SQL 쿼리를 생성하는 빌더를 제공하여 복잡한 쿼리를 쉽게 작성하고 실행할 수 있다.
- 데이터베이스 마이그레이션
데이터베이스 스키마를 버전 관리하고 마이그레이션하는 기능을 제공하여
데이터베이스 스키마를 업데이트하고 유지 관리하기 용이하다.
- 관계 지원
다양한 유형의 관계(일대일, 일대다, 다대일 등)를 지원하며, 데이터 간의 복잡한 관계를 쉽게 모델링할 수 있다.
위 장점들과 더불어 모든 쿼리를 sql로 짜면 코드량도 길어질 뿐더라 가독성도 좋지 않다고 느껴진다.
또한 백엔드와 프론트엔드 두 파트 모두 같은 언어인 TypeScript를 사용하고 있어 쿼리 언어 또한 TypeScript문법을 그대로 사용하여 진행하면 개발 속도와 디버깅에 도움이 되어서 사용한다.
.
.
.
.
Authentication: JWT Token
https://softmoca.tistory.com/294
위와 같이 세션과 JWT토큰의 특징과 장단점을 비교해 보았을 때 결론적으로 한 계정에서 여러 사용자들의 로그인에 대한 컨트롤이 필요 없으며 모바일 애플리케이션까지의 확장을 고려하면 JWT가 가장 적합한것 같아서 JWT를 사용해서 인가를 하기로 결정하였다.
Proxy Sever : Nginx
오픈 소스로 제공되는 웹 서버 및 리버스 프록시 서버 소프트웨어이다.
- 성능
Nginx는 경량이면서 고성능 웹 서버로 알려져 있으며, 다수의 동시 연결 및 요청을 처리할 수 있어 정적 콘텐츠를 빠르게 제공하고 부하 분산을 위한 우수한 성능을 제공.
- 리버스 프록시
Nginx는 리버스 프록시로 사용되어 백엔드 서버로 요청을 전달하고 응답을 다시 클라이언트에게 보내는 역할을 할 수 있어 애플리케이션 서버의 로드 밸런싱과 보안을 강화할 수 있다.
- 가벼움
Nginx는 리소스 사용이 적으며 메모리 효율적으로 동작한다.
따라서 서버 자원을 효율적으로 활용하면서도 빠른 응답 시간을 유지한다.
- 보안
Nginx는 보안 기능을 내장하고 있어 DDoS 공격 및 웹 어플리케이션 보안을 강화할 수 있다.
- 방화벽: Nginx를 사용하여 요청을 필터링하고 악성 트래픽을 차단.
- SSL/TLS: HTTPS를 지원하고 SSL/TLS 인증서를 관리하여 데이터 보안을 유지.
- 접근 제어: 웹 리소스에 대한 접근 제어 및 인증을 구현할 수 있다.
Test: Jest ,Supertest
테스트 관련 기술 스택은 아직 공부해보지 못했지만 가장 많은 사용량과 레퍼런스가 있는Jest ,Supertest를 선택하였다.
'캡스톤 설계 [건물별 소통 플랫폼 BBC]' 카테고리의 다른 글
데브옵스& 인프라 기술스택 및 아키텍쳐 (0) | 2024.03.07 |
---|---|
프론트엔드 기술스택 (0) | 2024.03.07 |
API 명세서 [REST API] Ver.1 (0) | 2024.03.07 |
데이터베이스 ERD 설계 Ver.1 (0) | 2024.03.07 |
로우파이 프로토 타입 [스케치(Lo-Fi)] (2) | 2024.03.07 |