요청/응답 라이프사이클
라라밸 애플리케이션이 처리하는 요청/응답 생명주기를 간단히 보면,
애플리케이션의 인스턴스가 생성되고,
서비스 프로바이더가 등록된 후,
부트스트래핑 과정을 마친 프로그램이 요청을 처리하는 사이클이다.
라라벨 애플리케이션이 어떻게 구성되어 있는지, 서비스 프로바이더를 통해 부트스트랩되는 과정을 구체적으로 이해하는 것은 매우 중요하다.
public/index.php - '인스턴스 생성'
라라벨 애플리케이션에서 모든 요청은 public/index.php파일에서 시작한다.
웹서버 (Apache / Nginx)의 설정에 따라 모든 요청은 이 파일에 전달된다.
프레임워크의 나머지 부분들을 로딩하기 위한 시작점이다.
이 파일의 역할은,
1. composer가 관리하는 모든 의존성을 등록해주는 composer 오토로더 파일을 불러온다.
2. bootstrap/app.php 에서 라라벨 애플리케이션의 인스턴스를 가져옵니다.
즉, 라라벨이 작동할 때 첫 번째 동작은 서비스 컨테이너(App) 인스턴스를 생성하는 것이다.
HTTP / Console 커널
애플리케이션이 시작된 유형에 따라 전송된 요청을 HTTP 커널이나 콘솔 커널 둘 중 하나로 보냅니다.
이 두가지의 커널은 모든 요청의 흐름 중심에서 작동하게 됩니다.
여기에서는 app/Http/Kernel.php 에있는 HTTP 커널에 초점을 맞춰 봅시다.
-
HTTP 커널
-
요청이 실행되기 전에 실행될 bootstrappers 배열을 정의하는 Illuminate\Foundation\Http\Kernel 클래스를 확장
- 이러한 부트스트래퍼는 오류 처리를 구성하고, 로깅을 구성하고, 애플리케이션 환경을 감지하고, 요청이 실제로 처리되기 전에 수행해야 하는 기타 작업을 수행합니다. 일반적으로 이러한 클래스는 신경 쓸 필요가 없는 라라벨 내부 설정을 처리합니다.
-
또한 모든 요청이 애플리케이션에서 처리되기 전에 통과해야 하는 HTTP 미들웨어 목록을 관리
- 이러한 미들웨어는 HTTP 세션 읽기 및 쓰기, 애플리케이션이 유지 관리 모드에 있는지 확인, CSRF 토큰 확인 등을 처리합니다. 이에 대해 곧 더 자세히 설명하겠습니다.
-
-
HTTP 커널의 handle 메서드에 대한 메서드 사용법
- Request를 수신하고 Response를 반환합니다.
- 커널을 전체 애플리케이션을 나타내는 큰 블랙박스로 생각하십시오.
- HTTP 요청을 제공하면 HTTP 응답을 반환합니다.
서비스 프로바이더
서비스 프로바이더는 라라벨 애플리케이션의 부팅(부트스트래핑) 단계의 주요한 핵심이다
가장 중요한 커널 부트스트랩 작업 중 하나는 애플리케이션에 대한 서비스 프로바이더를 로드하는 것
애플리케이션의 모든 서비스 프로바이더는 config/app.php 설정 파일의 providers 배열에서 관리됩니다.
라라벨은 이 서비스 프로바이더 목록을 각각 인스턴스화합니다. 서비스 프로바이더를 인스턴스화한 후 모든 프로바이더에서 register 메서드가 호출됩니다. 그런 다음 모든 프로바이더가 등록되면 각 프로바이더에서 boot 메서드가 호출됩니다. 이는 서비스 프로바이더가 boot 메소드가 실행될 때, 등록되고 사용 가능한 모든 컨테이너 바인딩에 의존할 수 있기 때문입니다.
서비스 프로바이더는 데이터베이스, 대기열, 유효성 검사 및 라우팅 구성 요소와 같은 프레임워크의 다양한 구성 요소를 모두 부트스트랩해야 합니다. 본질적으로 라라벨이 제공하는 모든 주요 기능은 서비스 프로바이더에서 부트스트랩 및 구성합니다. 프레임워크에서 제공하는 많은 기능을 부트스트랩하고 구성하기 때문에 서비스 프로바이더는 전체 라라벨 부트스트랩 프로세스에서 가장 중요한 곳 입니다.
애플리케이션을 위한 기본 서비스 프로바이더는 app/Providers 디렉토리에 있다.
기본적으로 AppServiceProvider 는 거의 빈채로 만들어져 있습니다. 이 프로바이더는 여러분의 고유한 부트스트래핑과 서비스 컨테이너 바인딩 코드를 추가하기 위한 곳입니다. 대규모 애플리케이션의 경우, 애플리케이션에서 사용하는 특정 서비스에 대해 더 세분화된 부트스트래핑을 관리하는 여러개의 서비스 공급자를 만들 수 있습니다.
라우팅-Routing
모든 라라벨의 라우트는 route 디렉토리 안에 들어 있는 라우트 파일에 정의되어 있습니다.
이 파일은 애플리케이션의 App\Providers\RouteServiceProvider에 의해서 자동으로 로드됩니다.
routes/web.php 파일은 웹 인터페이스를 위한 라우트들을 정의합니다.
이 라우트들에는 세션 상태와 CSRF 보호와 같은 기능을 제공하는 web 미들웨어 그룹이 할당되어 있습니다.
routes/api.php 안에 들어 있는 라우트들은 stateless 하고 api 미들웨어 그룹이 할당되어 있습니다.
애플리케이션에서 가장 중요한 서비스 프로바이더 중 하나는 App\Providers\RouteServiceProvider 이다.
이 서비스 프로바이더는 애플리케이션의 routes 디렉토리에 포함된 경로-route 파일을 로드합니다. 계속해서 RouteServiceProvider 코드를 열고 작동 방식을 살펴보세요!
애플리케이션이 부트스트랩되고 모든 서비스 프로바이더가 등록되면 Request가 실행을 위해 라우터로 전달됩니다. 라우터는 request를 라우트나 컨트롤러로 디스패치하고 라우트별 미들웨어를 실행합니다.
미들웨어는 애플리케이션에 들어오는 HTTP 요청을 필터링하거나 검사하기 위한 편리한 메커니즘을 제공합니다. 예를 들어, 라라벨에는 애플리케이션 사용자가 인증되었는지 확인하는 미들웨어가 포함되어 있습니다. 사용자가 인증되지 않은 경우 미들웨어는 사용자를 로그인 화면으로 리디렉션합니다. 그러나 사용자가 인증되면 미들웨어는 요청이 애플리케이션으로 더 진행되도록 허용해줍니다. 일부 미들웨어는 HTTP 커널의 middleware 속성에 정의된 것과 같이 애플리케이션 내의 모든 경로에 할당되는 반면 일부는 특정 경로 또는 경로 그룹에만 할당됩니다. 전체 미들웨어 문서를 읽으면 미들웨어에 대해 자세히 알아볼 수 있습니다.
요청이 일치하는 경로에 할당된 모든 미들웨어를 통과하면 경로 또는 컨트롤러 메서드가 실행되고 경로 또는 컨트롤러 메서드에서 반환된 응답은 경로의 미들웨어 체인을 통해 다시 전송됩니다.
마무리
경로 또는 컨트롤러 메서드가 응답을 반환하면, 응답은 경로의 미들웨어를 통해 외부로 다시 이동하여 애플리케이션이 나가는 응답을 수정하거나 검사할 수 있는 기회를 제공합니다.
마지막으로 응답이 미들웨어를 통해 다시 이동하면 HTTP 커널의 handle 메서드가 응답 개체를 반환하고 index.php 파일이 반환된 응답에 대해 send 메서드를 호출합니다. send 메소드는 응답 내용을 사용자의 웹 브라우저로 보냅니다. 전체 라라벨 요청 수명 주기를 통한 여정을 마쳤습니다!
