📝 Today I Learn

🗓️ 날짜: 2024-12-13

MVC 패턴: Model-View-Controller로 구성, 웹 애플리케이션에서 가장 널리 사용되는 아키텍처 패턴 중 하나
- Model: 데이터 관리
- View: 사용자 인터페이스
- Controller: Model-View 연결
전통적으로 SSR이 일반적 (서버에서 동적으로 HTML을 렌더링하여 뷰를 반환하기에)
브라우저(클라이언트)는 웹사이트를 보여주는 서버(클라이언트 서버)에 웹페이지를 만드는데 필요한 파일들(HTML, CSS, JavaScript 등)을 요청 -> 이 파일들을 받아서 브라우저는 웹페이지 레이아웃을 보여줄 수 있음
웹사이트에서 어떤 정보를 보거나 입력할 때는, 이 정보를 처리하고 저장하는 서버(백엔드 서버)로 데이터를 요청하고 응답을 받게됨
이런 과정을 통해, 웹사이트를 사용자에게 보여주는 부분(클라이언트)과 데이터를 처리하는 부분(백엔드)이 명확히 구분하게 됨 -> 클라이언트 서버와 백엔드 서버를 구분하여 개발하는 경우가 많아짐
프론트엔드 경로와 백엔드 경로를 구분해야함 (브라우저에서 백엔드서버로 요청 URL을 이용해 요청할 때 클라이언트 서버의 URL 값(예: localhost:3000)이 들어가지 않음!)

MCR 패턴: Model-Controller-Route로 구성, Node.js나 Express 같은 서버 사이드(백엔드) 프레임워크에서 좀 더 API 지향적으로 쓰이는 변형 개념
- Model: 데이터 관리
- Controller: API 요청 시, 해당 요청 비즈니스 로직 수행
- Route: 클라이언트 요청(HTTP 메서드 + URL 경로)을 컨트롤러와 매핑
CSR 시나리오에 잘 맞음 (서버가 JSON 형태의 API를 제공하는 데 특화되어있기에)
왜 View 대신 Route가 있을까?
- 서버가 HTML 뷰(템플릿)를 렌더링하지 않고, 주로 JSON 형태의 응답을 제공한다면 ‘View’ 레이어가 사실상 필요 없어짐
- 대신 View 레이어가 담당하던 역할이 ‘API 응답’을 통해 클라이언트(웹/앱)에 그대로 전달
- 이때 서버 측 코드에서 뷰 렌더링 대신 라우팅(Routing) 로직이 더 중요한 위치를 차지하게 됨