하나의 Request가 있으면 그에 대응하는 Response가 있다. 다시 말해,Request가 없으면 Response를 보내지 않는다.
연결을 유지하지 않기 때문에 리소스를 줄일 수 있어서 많은 트래픽을 빠르게 처리가 가능하다.
2. Stateless ( 무상태 )
연결을 한번 하고 끊기 때문에, 이전에 일어났던 일( 상태 )를 저장하고 있지 않는다.
매번 새로운 요청을 처리한다. ( 세션, 쿠키, DB로 해당 요청에 대한 정보를 임의로 저장해 처리하긴 한다. )
3. HTTP 프로토콜의 메세지 구조
HTTP 프로토콜의 메세지 구조는 위 그림과 같다.
이 중에서 중요하게 살펴볼 부분은 헤더( header ) 부분인데, 메세지에 필요한 모든 부가 정보가 들어있고, 그림처럼 넣고 싶은 내용을 임의로 추가 할 수도 있다.
General Header
Date : 현재 시간
Pragma : 캐시제어( no-cache ), HTTP/1.0에서 쓰던 것으로 HTTP/1.1에서는 Cache-Control이 쓰인다.
Cache-Control : 캐시 제어 + no-cache( 모든 캐시를 쓰기 전에 서버에 해당 캐시를 사용해도 되는지 확인 ) + public( 공유 캐시에 저장해도 됨 ) + max-age( 캐시의 유효시간을 명시 ) + private( '브라우저' 같은 특정 사용자 환경에만 저장 ) + must-revalidate( 만료된 캐시만 서버에 확인 ) + no-store( 캐시를 저장하지 않음 )
Transfer-Encoding : body 내용 자체 압축 방식 지정. 본문에 데이터 길이가 나와서 야금야금 브라우저가 해석해 화면에 뿌려줄 때 이 기능을 사용한다. ( 'chunked'면 본문의 내용이 동적으로 생성되어 길이를 모르기 때문에 나눠서 보낸다는 의미 )
Upgrade : 프로토콜 변경시 사용
Via : 중계( 프록시 )서버의 이름, 버전, 호스트명
Content-Encoding : 본문의 리소스 압축 방식( transfer-encoding은 body 자체이므로 다르다 )
Content-type : 본문의 미디어 타입(MIME) 예) application/json, text/html
Content-Length : 본문의 길이
Content-Language : 본문을 이해하는데 가장 적절한 언어. 예) ko
Expires : 자원의 만료 일자
Allow : 사용이 가능한 HTTP 메소드 방식 예) GET, HEAD, POST ...
Last-Modified : 최근에 수정된 날짜
ETag : 캐시 업데이트 정보를 위한 임의의 식별 숫자
Connection : 클라이언트와 서버의 연결 방식 설정 HTTP/1.1은 kepp-alive로 연결을 유지하는게 디폴트
● Request Line : 어떤 웹서버로 접속( Host 부분 )해서, 어떠한 방식( HTTP / 1.1 )으로, 어떠한 메소드( GET )를 통해 무엇을( /doc/test/.html ) 요청했는지에 대한 메시지가 담겨있다. ( GET /test.html http 1.1 )
● Host : 요청하려는 서버 호스트 이름과 포트번호
● User-agent : 클라이언트 프로그램 정보 예) Mozilla / 4.0, Windows NT5.1 ( 이 정보를 통해 서버는 클라이언트 프로그램( 브라우저 )에 맞는 최적의 데이터를 보내줄 수 있다. )
● Referer : 바로 직전에 머물렀던 웹 링크 주소( 해당 요청을 할 수 있게된 페이지 )
● Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열 예) */* - 모든 타입 처리가능, application/json - json데이터 처리 가능
● Accept-charset : 클라이언트가 지원가능한 문자열 인코딩 방식
● Accept-language : 클라이언트가 지원가능한 언어 나열
● Accept-encoding : 클라이언트가 해석가능한 압축 방식 지정 예) gzip, deflate
await this.postsService.findAllPosts(); 는 PostsController 클래스의 postService 인스턴스에서 findAllPost 메서드를 호출한다.
컨트롤러는 하위 계층의 내부 구조에 대해 신경쓰지 않는다. 대신, 외부에 공개된 메서드를 호출하기만 한다. 이것이 가능한 이유는 추상화( Absctraction )의 특성 덕분이다.
PostsController 클래스는 전달된 요청( Request )을 처리하기 위해 PostsService를 호출하도록 구현했다. 여기서 컨트롤러가 비즈니스 로직을 직접 수행하지 않고, 클라이언트의 요청을 서비스 계층으로 바로 전달 하도록 구현한 것을 확인 할 수 있다.
결국, PostsController 클래스는 클라이언트의 요청( Request )을 서비스 계층으로 전달하는 역할을 수행하며, 서비스 계층이 어떠한 내부 구조를 통해 비즈니스 로직을 수행하는지는 상위 계층인 컨트롤러에게는 중요하지 않다.
서비스( Service )
서비스 계층( Service Layer )
다른 이름으로는 비즈니스 로직 계층( Business logic layer )은 아키텍처의 가장 핵심적인 비즈니스 로직을 수행하고 클라이언트가 원하는 요구사항을 구현하는 계층이다.
프레젠테이션 계층( Persentation Layer )과 데이터 엑세스 계층( Data Access Layer ) 사이에서 중간 다리 역할을 하고, 서로 다른 두 계층이 직접 통신하지 않게 만들어 준다.
서비스( Service )는 데이터가 필요할 때, 저장소( Repository )에게 데이터를 요청한다.
어플리케이션의 규모가 커질수록, 서비스 계층의 역할과 코드의 복잡성도 점점 더 커지게 된다.
어플리케이션의 핵심적인 비즈니스 로직을 수행하고, 클라이언트들의 요구사항을 반영해 원하는 결과를 반환해주는 계층이다.
서비스 계층의 장단점
서비스 계층의 장점
사용자의 유즈 케이스( Use Case )와 워크플로우( Workflow )를 명확히 정의하고 이해할 수 있도록 도와준다.
비즈니스 로직이 API 뒤에 숨겨져 있으므로, 서비스 계층의 코드를 자유롭게 수정하거나 리팩터링할 수 있다.
저장소 패턴( Repository Pattern ) 및 가짜 저장소( Fake Repository )와 조합하면 높은 수준의 테스트를 작성할 수 있다.
서비스 계층의 단점
서비스 계층 또한 다른 추상화 계층이므로, 잘못 사용하면 코드의 복잡성을 증가시킬 수 있다.
한 서비스 계층이 다른 서비스 계층에 의존하는 경우, 의존성 관리가 복잡해질 수 있다.
서비스 계층에 너무 많은 기능을 넣으면 빈약한 도메인 모델( Anemic Domain Model )과 같은 안티 패턴이 생길 수 있다.
Express로 구현하는 서비스 계층
Service
사용자의 요구사항을 처리하는 핵심 부분
DB 정보가 필요할 때는 Repository에게 요청한다.
PostsController 클래스가 클라이언트의 요청( Request )을 PostsServer 클래스에게 전달하는 과정을 살펴봤다.
이번에는 서비스 계층( Service Layer )에게 비즈니스 로직을 어떻게 수행하고, 필요한 데이터를 어떻게 저장소( Repository )로부터 요청하는지 확인해보도록 하자.
posts.service.js
// src/services/posts.service.js
import { PostsRepository } from '../repositories/posts.repository.js';
export class PostsService {
postsRepository = new PostsRepository();
findAllPosts = async () => {
// 저장소(Repository)에게 데이터를 요청합니다.
const posts = await this.postsRepository.findAllPosts();
// 호출한 Post들을 가장 최신 게시글 부터 정렬합니다.
posts.sort((a, b) => {
return b.createdAt - a.createdAt;
});
// 비즈니스 로직을 수행한 후 사용자에게 보여줄 데이터를 가공합니다.
return posts.map((post) => {
return {
postId: post.postId,
nickname: post.nickname,
title: post.title,
createdAt: post.createdAt,
updatedAt: post.updatedAt,
};
});
};
createPost = async (nickname, password, title, content) => {
// 저장소(Repository)에게 데이터를 요청합니다.
const createdPost = await this.postsRepository.createPost(
nickname,
password,
title,
content,
);
// 비즈니스 로직을 수행한 후 사용자에게 보여줄 데이터를 가공합니다.
return {
postId: createdPost.postId,
nickname: createdPost.nickname,
title: createdPost.title,
content: createdPost.content,
createdAt: createdPost.createdAt,
updatedAt: createdPost.updatedAt,
};
};
}
이번 서비스 계층( Service Layer )에서 PostsService 클래스가 PostsRepository의 findAllPosts, createPost 메서드를 호출하는 것을 확인할 수 있다. 해당 코드는 서비스가 비즈니스 로직을 수행하는 데 필요한 데이터를 저장소 계층( Repository Layer )에게 요청해 가져오는 것을 확인 할 수 있다.
또한, 서비스 계층에서는 return posts.map(post => {}); 와 같이 데이터를 가공하는 작업이 이루어진다.
만약, 저장소 계층에서 받은 데이터를 그대로 클라이언트에게 전달한다면, 사용자의 비밀번호와 같은 민감한 정보까지 노출되는 보안 문제가 발생해, 서버의 보안성이 떨어지는 결과를 낳는다.
저장소( Repository )
저장소 계층( Repository Layer )
데이터 엑세스 계층( Data Access Layer )이라고 불린다. 주로 데이터베이스와 관련된 작업을 처리하는 계층이다.
데이터 접근과 관련된 세부 사항을 숨기는 동시에, 메모리상에 데이터가 존재하는 것처럼 가정해 코드를 구현한다.
저장소 계층을 도입하면, 데이터 저장 방법을 더욱 쉽게 변경할 수 있고, 테스트 코드 작성시 가짜 저장소( Mock Repository )를 제공하기가 더 쉬워진다.
어플리케이션의 다른 계층들은 저장소의 세부 구현 방식에 대해 알지 못하더라도 해당 기능을 사용할 수 있다. 즉, 저장소 계층의 변경 사항이 다른 계층에 영향을 주지 않는 것이다. ( 객체 지향의 개념 중 추상화( Abstraction)와 관계가 있다. )
저장소 계층은 데이터 저장소를 간단히 추상화한 것으로, 이 계층을 통해 모델 계층과 데이터 계층을 명확하게 분리할 수 있다.
대표적인 저장소 계층의 메서드
add(), create() : 새 원소를 저장소에 추가한다.
get(), find() : 이전에 추가한 원소를 저장소에 가져온다.
저장소 계층의 장단점
저장소 계층의 장점
데이터 모델과 데이터 처리 인프라에 대한 사항을 분리했기 때문에 단위 테스트( Unit test )를 위한 가짜 저장소( Mock Repository )를 쉽게 만들 수 있다.
도메인 모델을 미리 작성해, 처리해야할 비즈니스 문제에 더 잘 집중할 수 있다.
객체를 테이블에 매칭하는 과정을 원하는 대로 제어할 수 있어서 DB 스키마를 단순화할 수 있다.
저장소 계층에 ORM을 사용하면 필요할 때 MySQL과 Postgre와 같은 다른 데이터베이스로 쉽게 전환할 수 있다.
저장소 계층의 단점
저장소 계층이 없더라도 ORM은 모델과 저장소의 결합도를 충분히 완화시켜 줄 수 있다. ( ORM이 없을 때 대부분의 코드는 Raw Query로 작성되어 있기 때문 )
ORM 매핑을 수동으로 하려면 개발 코스트가 더욱 소모된다. ( 여기서 설명하는 ORM은 이전에 사용한 Prisma와 같은 라이브러리를 말한다. )
Express로 구현하는 저장소 계층
Repository
데이터베이스 관리( 연결, 해제, 자원 관리 ) 역할을 담당한다.
데이터베이스의 CRUD 작업을 처리한다.
3계층 아키텍처의 마지막 계층인 저장소 계층( Repository Layer )이다.
이전에 작성했던 코드에서 서비스 계층( Service Layer )인 PostsServices에서 PostsRepository를 호출해 데이터를 요청하는 것을 확인할 수 있었다.
이번에는 저장소 계층( Repository Layer )이 어떻게 데이터베이스의 데이터를 가져와 상위 계층에게 반환하는지 확인해보도자.
posts.repository.js
// src/repositories/posts.repository.js
import { prisma } from '../utils/prisma/index.js';
export class PostsRepository {
findAllPosts = async () => {
// ORM인 Prisma에서 Posts 모델의 findMany 메서드를 사용해 데이터를 요청합니다.
const posts = await prisma.posts.findMany();
return posts;
};
createPost = async (nickname, password, title, content) => {
// ORM인 Prisma에서 Posts 모델의 create 메서드를 사용해 데이터를 요청합니다.
const createdPost = await prisma.posts.create({
data: {
nickname,
password,
title,
content,
},
});
return createdPost;
};
}
이번 저장소 계층( Repository Layer )에서는 PostRepository 클래스에서 Prisma의 메소드를 사용해 데이터를 조회하거나 생성하는 것이 가장 핵심적인 내용이다.
위 예제에서는 단일 테이블만 활용해 Prisma를 사용했기 때문에 코드가 복잡해지지 않았다. 당연히 어플리케이션의 규모가 커지거나, 데이터베이스의 구성이 복잡해지면 저장소 계층의 구조 또한 복잡해진다.
