Laravel 요청 수명주기

1 개요[ | ]

Request Lifecycle
요청 수명주기

2 소개[ | ]

"실제 세계"에서 어떤 도구를 사용할 때, 그 도구가 어떻게 작동하는지 이해하면 더 자신감이 생깁니다. 애플리케이션 개발도 다르지 않습니다. 개발 도구가 어떻게 작동하는지 이해하면, 이를 사용하는 데 더 편안하고 자신감이 생깁니다.

이 문서의 목표는 Laravel 프레임워크가 어떻게 작동하는지에 대해 높은 수준의 개요를 제공하는 것입니다. 전체 프레임워크를 더 잘 이해함으로써 모든 것이 덜 "마법적"으로 느껴지고 애플리케이션을 구축할 때 더 자신감을 가질 수 있을 것입니다. 모든 용어를 바로 이해하지 못하더라도 낙심하지 마세요! 기본적인 개념을 파악하려고 노력하고, 문서의 다른 섹션을 탐색하면서 지식이 성장할 것입니다.

3 수명주기 개요[ | ]

3.1 첫 단계[ | ]

Laravel 애플리케이션에 대한 모든 요청의 진입점은 public/index.php 파일입니다. 모든 요청은 웹 서버(Apache/Nginx) 설정에 의해 이 파일로 전달됩니다. index.php 파일 자체에는 많은 코드가 포함되어 있지 않습니다. 대신, 프레임워크의 나머지 부분을 로드하는 출발점입니다.

index.php 파일은 Composer가 생성한 오토로더 정의를 로드한 다음, bootstrap/app.php에서 Laravel 애플리케이션 인스턴스를 가져옵니다. Laravel 자체가 수행하는 첫 번째 작업은 애플리케이션/서비스 컨테이너 인스턴스를 생성하는 것입니다.

3.2 HTTP / 콘솔 커널[ | ]

다음으로, 들어오는 요청은 애플리케이션 인스턴스의 handleRequest 또는 handleCommand 메소드를 사용하여 HTTP 커널 또는 콘솔 커널로 보내집니다. 이는 애플리케이션에 들어오는 요청의 유형에 따라 다릅니다. 이 두 커널은 모든 요청이 흐르는 중심 위치 역할을 합니다. 이제 HTTP 커널에 집중해 보겠습니다. HTTP 커널은 Illuminate\Foundation\Http\Kernel의 인스턴스입니다.

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

HTTP 커널은 또한 요청을 애플리케이션의 미들웨어 스택을 통해 전달하는 역할을 합니다. 이러한 미들웨어는 HTTP 세션을 읽고 쓰는 작업, 애플리케이션이 유지 보수 모드에 있는지 여부 결정, CSRF 토큰 확인 등을 처리합니다. 이에 대해서는 곧 더 자세히 다룰 것입니다.

HTTP 커널의 handle 메소드의 메소드 시그니처는 매우 간단합니다: Request를 받아 Response를 반환합니다. 커널을 애플리케이션 전체를 대표하는 큰 블랙박스로 생각하세요. HTTP 요청을 입력하면 HTTP 응답을 반환합니다.

3.3 서비스 제공자[ | ]

가장 중요한 커널 부트스트래핑 작업 중 하나는 애플리케이션의 서비스 제공자를 로드하는 것입니다. 서비스 제공자는 데이터베이스, 큐, 유효성 검사 및 라우팅 구성 요소와 같은 프레임워크의 다양한 컴포넌트를 부트스트래핑하는 역할을 합니다.

Laravel은 이 제공자 목록을 순회하면서 각각의 제공자를 인스턴스화합니다. 제공자를 인스턴스화한 후에는 모든 제공자에 대해 register 메소드가 호출됩니다. 그런 다음, 모든 제공자가 등록되면 각 제공자에 대해 boot 메소드가 호출됩니다. 이는 모든 컨테이너 바인딩이 등록되고 boot 메소드가 실행될 때 사용가능하도록 하기 위함입니다.

사실상 Laravel에서 제공하는 거의 모든 주요 기능은 서비스 제공자에 의해 부트스트래핑되고 설정됩니다. 서비스 제공자는 프레임워크가 제공하는 많은 기능을 부트스트래핑하고 설정하기 때문에, 서비스 제공자는 전체 Laravel 부트스트래핑 과정에서 가장 중요한 측면입니다.

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

3.4 라우팅[ | ]

애플리케이션이 부트스트랩되고 모든 서비스 제공자가 등록되면, 요청(Request)은 라우터(router)로 전달되어 디스패치(dispatch)됩니다. 라우터는 요청을 라우트(route)나 컨트롤러(controller)로 디스패치하고, 라우트에 특정한 미들웨어(middleware)를 실행합니다.

미들웨어는 애플리케이션으로 들어오는 HTTP 요청을 필터링하거나 검사하는 편리한 메커니즘을 제공합니다. 예를 들어, Laravel에는 애플리케이션 사용자가 인증되었는지 확인하는 미들웨어가 포함되어 있습니다. 사용자가 인증되지 않은 경우, 미들웨어는 사용자를 로그인 화면으로 리디렉션합니다. 그러나 사용자가 인증된 경우, 미들웨어는 요청이 애플리케이션의 더 깊은 부분으로 진행되도록 허용합니다. PreventRequestsDuringMaintenance와 같이 애플리케이션의 모든 라우트에 할당되는 미들웨어도 있지만, 특정 라우트나 라우트 그룹에만 할당되는 미들웨어도 있습니다. 미들웨어에 대한 자세한 내용은 미들웨어 문서를 참조하세요.

요청이 모든 매칭된 라우트의 할당된 미들웨어를 통과하면, 라우트나 컨트롤러 메소드가 실행되고 그에 의해 반환된 응답이 라우트의 미들웨어 체인을 통해 다시 전송됩니다.

3.5 마무리[ | ]

라우트 또는 컨트롤러 메소드가 응답을 반환하면, 그 응답은 다시 라우트의 미들웨어를 통해 외부로 전송됩니다. 이를 통해 애플리케이션은 나가는 응답을 수정하거나 검사할 기회를 갖게 됩니다.

마지막으로, 응답이 미들웨어를 거쳐 다시 이동하면, HTTP 커널의 handle 메소드는 응답 객체를 애플리케이션 인스턴스의 handleRequest로 반환하고, 이 메소드는 반환된 응답의 send 메소드를 호출합니다. send 메소드는 응답 내용을 사용자의 웹 브라우저로 보냅니다. 이렇게 해서 Laravel 요청 라이프사이클 전체를 다루는 여정을 완료했습니다!

4 서비스 제공자에 집중하기[ | ]

서비스 제공자는 Laravel 애플리케이션을 부트스트래핑하는 데 매우 중요한 역할을 합니다. 애플리케이션 인스턴스가 생성되고, 서비스 제공자가 등록되며, 요청이 부트스트래핑된 애플리케이션에 전달됩니다. 정말 간단합니다!

Laravel 애플리케이션이 서비스 제공자를 통해 어떻게 빌드되고 부트스트래핑되는지에 대해 잘 이해하는 것은 매우 가치 있습니다. 사용자 정의 서비스 제공자는 app/Providers 디렉토리에 저장됩니다.

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