2024 07 25

2024-07-25¶

Play 구동 원리¶

참고: https://www.playframework.com/documentation/2.8.x/Home

요청 처리 방식 오버뷰¶

/로 요청
Play internal HTTP Server가 request 받음
Play 요청을 routes 파일을 통해서 resolve: URI <-> Controller 매핑
Action에 대한 대답으로 index 페이지 반환 (Twirl template)
HTTP 서버가 HTML 응답

GPT 대답¶

Play는 Akka Toolkit 위에서 만들어진 친구
- 비동기/병행성/분산 처리에 용이한 어플리케이션으로 설계
- 완전히 비동기적이라서 결과값을 기다리지 않고 계속 처리
- Scalability, Effiency를 높임
- non-blocking I/O 모델을 통해 많은 쓰레드가 아니더라도 많은 동시 요청 처리가 가능
Spring 처럼 서블릿을 쓰진 않음
Play는 독자적인 HTTP 프로그래밍 모델을 사용
- 요청이 인입
- Play Server (기본적으로 Akka-HTTP)가 요청을 받아서 Akka Actor System으로 처리 전달
- 요청이 특정 쓰레드에 메여서 처리되는 것이 아니라, 시스템 내 아무 액터에게 넘겨버린다는 것!
Play는 HTTP 요청/응답을 Action Generator를 통해 진행
- Action은 기본적으로 Request를 받아서 Result를 뱉는 Function이라고 생각하면 됨
Play는 그들의 독자적 서버와 아카 액터 모델을 레버리지 하고 이를 캡슐화 시켜서 높은 병렬성을 제공
- 이는 기존의 thread-per-request 모델과는 사뭇 다름. (하나 요청왔다 -> 쓰레드 매핑해서 너가 다 처리해줘~)
Play는 Stateless함.
- Play는 server-side 세션이나, stateful component를 사용하지 않아.

Play vs Spring¶

참고: https://amans07.medium.com/play-with-play-an-introduction-to-play-framework-ea7b7d4cfb23

Play의 장점¶

개발 생산성 향상
- Hot reload를 통한 코드 리프레시
Non-blocking IO
- Spring은 blocking 처리 (I/O 할 때마다 쓰레드를 들고 있음 무쓸모하게)
- 요즘 앱들은 I/O가 병목 구간인데 말야
- Play는 Fully non-blocking! (MSA에 적합)
- 웹소켓, 스트리밍에 적합
FP
- Spring은 객체, 어노테이션, XML 등으로 구성
- Play는 FP Core
  - 값을 반환하는 함수, 타입시스템의 원활한 사용, 코드 쉬워짐, 디버깅도 쉬움 (이건 숙련도 차이일듯 근데)

Play가 Fully 비동기로 동작할 수 있는 이유¶

object ProxyController extends Controller {
    def proxy = Action {
        val responseFuture: Future[Response] = WS.url("https://example.com").get()
        val resultFuture: Future[Result] = responseFuture.map { resp => 
            Status(resp.status)(resp.body).as(resp.ahcResponse.getContentType)
        }
        Async(resultFuture)
    }
}

Play는 CPU 코어 만큼의 쓰레드 풀을 할당
T1이 proxy Action을 실행해 코드를 처음부터 읽어 내려가면서 실행
T1이 AsyncResult(Future[Result])를 반환하면 다른 요청 처리하러 감
나중에 "example.com" 으로 부터 응답이 오면, 다른 쓰레드 T2가 map 메서드 안에있는 함수들에 대해 실행
한번도 블락이 된적이 없었다!