[SpringBoot] MVC vs API

SpringBoot에서는 최근 MVC 보다는 API를 구현하는 쪽으로 가고 있다.

○ MVC

• MVC : Controller → Model(DB) → View : controller가 db에 데이터를 요청해서 view에 보여준다.
  
• Spring Boot Web (WebFlux) : 사용자의 요청을 받아서 처리하는 기능
• Tomcat → WAS 서블릿 컨테이너 역할

Servlet (서블릿)

• 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술
• 서블릿 컨테이너 (Servlet Container) : Servlet Instance (서블릿 인스턴스)를 생성하고 관리하는 역할을 수행한다.
  • 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
  • 서블릿 객체는 싱글톤 패턴으로 관리된다.
  • 멀티 스레딩을 지원한다.
• 톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행한다.
• 스프링에서는 DispatcherServlet 이 서블릿 역할을 수행한다.
• → 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml 의 설정값을 공유한다.
• DispatcherServlet

  1. DispatcherServlet으로 요청(HttpServletRequest)이 들어오면 DispatcherServlet은 핸들러 매핑(Handler Mapping)을 통해 요청 URI에 매핑된 핸들러를 탐색한다.

     (Handler는 Controller를 의미한다.)

     • HandlerMapping은 요청 정보를 기준으로 어떤 컨트롤러를 사용할 지 선정하는 인터페이스이다. 여러 구현체를 가진다.

  2. 핸들러 어댑터 (HandlerAdapter)로 컨트롤러를 호출한다.

  3. 핸들러 어댑터에 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공해 반환한다.

  4. 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 View Resolver를 통해 뷰를 받아 리턴한다.

○ API

💡 뷰가 없는 REST 형식의 @ResponseBody를 사용하여, 뷰 리졸버를 호출하지 않고 MessageConverter를 거쳐 JSON 형식으로 변환해서 응답한다.

@RestController (@ResponseBody + @Controller)를 쓴다.

• @ResponseBody 를 사용하면 뷰 리졸버( viewResolver )를 사용하지 않음
  대신에 HTTP의 BODY에 문자 내용을 직접 반환(HTML BODY TAG를 말하는 것이 아님)
  - @ResponseBody 를 사용하고, 객체를 반환하면 객체가 JSON으로 변환됨
  - HTTP의 BODY에 문자 내용을 직접 반환
  - viewResolver 대신에 HttpMessageConverter (인터페이스)가 동작
  - 기본 문자처리: StringHttpMessageConverter
  - 기본 객체처리: MappingJackson2HttpMessageConverter (JSON → POJO 객체)
  - byte 처리 등등 기타 여러 HttpMessageConverter가 기본으로 등록되어 있음
• 참고: 클라이언트의 HTTP Accept 해더와 서버의 컨트롤러 반환 타입 정보 둘을 조합해서 HttpMessageConverter 가 선택된다.

---

💡 WebFlux

WebFlux란?

• Spring WebFlux는 Spring 5에서 새롭게 추가된 모듈입니다.
• WebFlux는 클라이언트, 서버에서 reactive 스타일의 어플리케이션 개발을 도와주는 모듈이며, reactive-stack web framework이며 non-blocking에 reactive stream을 지원합니다.
• 장점 : 고성능, spring 과 완벽한 통합, netty 지원, 비동기 non-blocking 메세지 처리
• 단점 : 오류처리가 다소 복잡하다.
• 스프링5는 Spring Boot 2 부터 도입이 되었으며, Spring Boot 2 의 stack 는 아래와 같습니다.

💡Spring MVC vs. WebFlux

Spring MVC와 WebFlux의 공통점은 @Controller, Reactive 클라이언트입니다. 둘 다 Tomcat, Jetty, Undertow와 같은 서버에서 실행할 수 있습니다. Spring MVC에서는 명령형 논리, JDBC, JPA를 가질 수 있습니다. Spring WebFlux에서는 기능적 엔드 포인트, 이벤트 루프, 동시성 모델을 가질 수 있습니다. Spring WebFlux는 Netty 서버에서 실행할 수 있다는 장점이 있습니다.

<Spring MVC 또는 WebFlux를 사용하는 경우>

1. 이미 작동중인 Spring MVC 애플리케이션이 있다면 Spring WebFlux로 변환 할 필요가 없으며,  Spring MVC는 작성하고 디버그하는 쉬운 방법 인 명령형 프로그래밍을 사용합니다.

2. non-blocking 웹 스택을 생성하고자한다면, 선택 가능한 서버 (Netty, Tomcat, Jetty, Undertow 및 Servlet 3.1+ 컨테이너)를 제공하는 Spring WebFlux를 선택할 수 있습니다. 웹 엔드 포인트) 및 반응 라이브러리 (Reactor, RxJava 또는 기타)를 선택할 수 있습니다.

3. Spring WebFlux는 Java 8 lambda 또는 Kotlin과 함께 사용하는 가볍고 기능적인 웹 프레임 워크에 유용합니다.

4. 마이크로 서비스 애플리케이션에서 우리는 Spring MVC와 Spring WebFlux 컨트롤러의 혼합 애플리케이션을 가질 수 있습니다. Spring WebFlux 엔드 포인트도 가질 수 있습니다.

5. 애플리케이션이 JPA, JDBC 또는 네트워킹 API에 의존하는 경우 Spring MVC가 최선의 선택이다.

(Webflux 는 Asynchronous Non-blocking I/O 을 방식을 활용하여 성능을 끌어 올릴 수 있는 장점이 있다. 그런데 이 말은 즉, Non Blocking 기반으로 코드를 작성해야 한다. 만약 Blocking 코드가 있다면 Webflux를 사용하는 의미가 떨어지게 된다. 얼마 전까지는 Java 진영에 Non Blocking 을 지원하는 DB Driver가 없었지만, 최근에 R2DBC 가 릴리즈되어 이제는 Java 에서도 Non Blocking 으로 DB 를 접근할 수 있게 되었다.)