요청 수명 주기

소개

‘현실 세계’ 에서 어떤 도구를 사용할 때， 그 도구가 어떻게 작동하는지 이해하면 더 자신감을 느낄 수 있습니다. 애플리케이션 개발도 다르지 않습니다. 개발 도구가 어떻게 작동되는지 이해하면， 그것들을 사용할 때 더 편안하고 자신감을 느낄 수 없습니다。

이 문서의 목표는 Laravel 프레임워크가 어떻게 작동하는지에 대한 좋은 고급 개요를 제공하는 것입니다. 전체 프레임워크에 대해 더 잘 알게 되면 모든 것이 덜 “마법적” 으로 느껴지고 애플리케이션을 구축할 때 더 자신감을 갖게 됩니다. 모든 용어를 즉시 이해하지 못한다고 해도 실망하지 마세요！ 무슨 일이 일어나고 있는지 기본적인 이해를 얻으려고 노력하세요. 문서의 다른 섹션을 탐색하면서 지식이 증가할 것입니다。

라이프사이클 개요

첫 단계

Laravel 애플리케이션에 대한 모든 요청의 진입점은 public/index.php 파일입니다. 모든 요청은 웹 서버 (Apache/Nginx) 구성에 의해 이 파일로 전달됩니다. index.php 파일에는 많은 코드가 포함되어 있지 않습니다. 오히려 이는 나머지 프레임워크를 로드하기 위한 시작점입니다。

index.php 파일은 Composer 가 생성한 자동 로더 정의를 로드한 다음， bootstrap/app.php 에서 Laravel 애플리케이션의 인스턴스를 검색합니다. Laravel 자체가 취하는 첫 번째 작업은 애플리케이션 / 서비스 컨테이너 의 인스턴스를 생성하는 것입니다。

HTTP/콘솔 커널

다음으로， 수신되는 요청은 애플리케이션에 입력되는 요청 유형에 따라 애플리케이션 인스턴스의 handleRequest 또는 handleCommand 메서드를 사용하여 HTTP 커널 또는 콘솔 커널로 전송됩니다. 이 두 커널은 모든 요청이 흐르는 중앙 위치 역할을 합니다. 지금은 Illuminate\Foundation\Http\Kernel 의 인스턴스인 HTTP 커널에만 초점을 맞추도록 하겠습니다。

HTTP 커널은 요청이 실행되기 전에 실행될 bootstrappers 의 배열을 정의합니다. 이러한 부트스트랩은 오류 처리를 구성하고， 로깅을 구성하고， 애플리케이션 환경 감지 를 구성하며， 요청이 실제로 처리되기 전에 수행해야 하는 기타 작업을 수행합니다. 일반적으로 이러한 클래스는 걱정할 필요가 없는 내부 Laravel 구성을 처리합니다。

HTTP 커널은 애플리케이션의 미들웨어 스택을 통해 요청을 전달하는 역할도 합니다. 이러한 미들웨어는 HTTP 세션 의 읽기 및 쓰기， 애플리케이션이 유지 관리 모드인지 여부 결정， CSRF 토큰 확인 등을 처리합니다. 이에 대해서는 곧 자세히 설명하겠습니다。

HTTP 커널의 handle 메서드에 대한 메서드 서명은 매우 간단합니다. Request 를 수신하고 Response 를 반환합니다. 커널을 애플리케이션 전체를 나타내는 큰 블랙박스로 생각하세요. HTTP 요청을 제공하면 HTTP 응답을 반환합니다。

서비스 제공업체

가장 중요한 커널 부트스트랩 작업 중 하나는 애플리케이션에 대한 서비스 제공자 를 로드하는 것입니다. 서비스 제공자는 데이터베이스， 대기열， 검증 및 라우팅 구성 요소와 같은 프레임워크의 모든 다양한 구성 요소를 부트스트랩할 책임이 있습니다。

Laravel 은 이 제공자 목록을 반복하여 각 제공자를 인스턴스화합니다. 제공자를 인스턴스화한 후， 모든 제공자에서 register 메서드가 호출됩니다. 그런 다음， 모든 제공자가 등록되면 각 제공자에서 boot 메서드가 호出됩니다. 이는 서비스 제공자가 boot 메서드가 실행될 때까지 등록되고 사용 가능한 모든 컨테이너 바인딩에 의존할 수 있도록 하기 위한 것입니다。

기본적으로 Laravel 에서 제공하는 모든 주요 기능은 서비스 제공자에 의해 부트스트랩되고 구성됩니다. 프레임워크에서 제공하는 많은 기능을 부트스트랩하고 구성하기 때문에， 서비스 제공자는 Laravel 부트스트랩 프로세스 전체에서 가장 중요한 측면입니다。

프레임워크는 내부적으로 수십 개의 서비스 제공자를 사용하지만， 자체 서비스 제공자를 생성할 수도 있습니다. 애플리케이션에서 사용하는 사용자 정의 서비스 제공자 또는 타사 서비스 제공자 목록은 bootstrap/providers.php 파일에서 찾을 수 있습니다。

라우팅

애플리케이션이 부트스트랩되고 모든 서비스 제공자가 등록되면 Request 가 전송을 위해 라우터에 전달됩니다. 라우터는 경로 또는 컨트롤러로 요청을 전송하고 경로별 미들웨어를 실행합니다。

미들웨어는 애플리케이션에 들어오는 HTTP 요청을 필터링하거나 검사하기 위한 편리한 메커니즘을 제공합니다. 예를 들어， Laravel 에는 애플리케이션의 사용자가 인증되었는지 확인하는 미들웨어가 포함되어 있습니다. 사용자가 인증되지 않은 경우， 미들웨어는 사용자를 로그인 화면으로 리디렉션합니다. 그러나 사용자가 인증되었다면， 미들웨어는 요청이 애플리케이션 내에서 더 깊이 진행되도록 허용합니다. PreventRequestsDuringMaintenance 와 같은 일부 미들웨어는 앱 내의 모든 경로에 할당되고， 일부는 특정 경로 또는 경로 그룹에만 할당됩니다. 전체 미들웨어 설명서 를 읽어 미들웨어에 대해 자세히 알아볼 수 있습니다。

요청이 일치하는 경로의 모든 할당된 미들웨어를 통과하면 경로 또는 컨트롤러 메서드가 실행되고 경로 또는 컨트롤러에서 반환된 응답이 경로의 미들웨어 체인을 통해 다시 전송됩니다。

마무리

경로 또는 컨트롤러 메서드가 응답을 반환하면， 응답은 경로의 미들웨어를 통해 다시 외부로 이동하여 애플리케이션이 아웃바운드 응답을 수정하거나 검사할 수 있는 기회를 제공합니다。

마지막으로， 응답이 미들웨어를 통해 다시 이동하면 HTTP 커널의 handle 메서드가 응답 객체를 애플리케이션 인스턴스의 handleRequest 로 반환하며， 이 메서드는 반환된 응답에서 send 메서드를 호출합니다. send 메서드는 응답 콘텐츠를 사용자의 웹 브라우저로 전송합니다. 이제 Laravel 요청 수명 주기 전체를 통한 여정이 완료되었습니다！

서비스 제공업체에 집중

서비스 제공자는 Laravel 애플리케이션을 부트스트랩하는 데 정말 중요합니다. 애플리케이션 인스턴스가 생성되고， 서비스 제공자가 등록되며， 부트스트랩된 애플리케이션에 요청이 전달됩니다. 정말 간단합니다！

서비스 제공자를 통해 Laravel 애플리케이션이 구축되고 부트스트랩되는 방법을 확실히 이해하는 것은 매우 가치 있습니다. 애플리케이션의 사용자 정의 서비스 제공자는 app/Providers 디렉토리에 저장됩니다。

기본적으로, AppServiceProvider는 상당히 비어 있습니다. 이 제공자는 애플리케이션의 자체 부트스트래핑과 서비스 컨테이너 바인딩을 추가하기에 좋은 장소입니다. 대규모 애플리케이션의 경우, 각 서비스에 대해 보다 세분화된 부트스트래핑을 가진 여러 서비스 제공자를 생성하는 것이 좋을 수 있습니다.

서브목차