라이프사이클

 라라벨을 이해하기 위해서 우선 라이프 사이클부터 알아보자.

 

1. 시작지점

  모든 라라벨 애플리케이션은 아파치의 .htaccess 파일이나 엔진엑스의 서버 설정 같은 웹 서버 수준에서 특정한 형태의 설정을 가지고 있는데, 이 설정은 URL에 상관없이 모든 웹 요청을 가로채서 라라벨 애플리케이션의 public/index.php 파일로 전달한다. index.php는 초기화 작업을 진행하기 위한 코드가 포함되어 있다.

 

require __DIR__.'/../vendor/autoload.php';

위 코드를 통해 컴포저가 관리하는 모든 의존성을 등록해주는 컴포저 오토로드 파일을 불러온다.

 

$app = require_once __DIR__.'/../bootstrap/app.php';

그런 다음 애플리케이션 컨테이너[1]를 만들고, 핵심 서비스(커널 등..)를 등록하는 부트스트랩[2]을 실행한다.

[1] 인터페이스와 클래스의 인스턴스를 연결하고 의존성을 해결하는 데 사용할 수 있으며, 서로 연결된 의존성 네트워크를 관리하는 도구이다. 서비스컨테이너 혹은 제어의 역전(IoC) 컨테이너, 의존성 주입 컨테이너라고도 함.

[2] 컴퓨터 전원을 켜면 부팅이 되듯이 애플리케이션이 동작하기 위해서 부팅되는 것을 의미

---

$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);

$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

$response->send();

$kernel->terminate($request, $response);

커널 인스턴스를 만들고($app->make) 현재 사용자의 웹 요청을 반영하는 요청 객체의 인스턴스를 만들어(Request::capture()) 커널이 처리하도록 넘겨준다($kernel->handle). 커널은 index.php가 최종 사용자에게 반환할 일루미네이트 Response 객체를 클라이언트(=브라우저)에 반환하고 나서 페이지 요청을 종료.

 

2. 라라벨의 커널

커널은 라라벨 애플리케이션의 가장 핵심적인 로직이 동작하는 곳이다. 사용자의 요청을 받아 이를 미들웨어에 전달하고, 예외가 발생하면 알맞은 응답을 처리한다. 그 뒤에 라우터로 전달해 등록된 라우트와 연결된 로직을 처리한다. 그러고 나서 클로저나 컨트롤러에서 반환되는 최종 응답을 클라이언트에 전달한다.

라라벨에는 2개의 커널이 있지만 각각의 요청을 처리할 때에는 하나의 커널만 사용된다. HTTP 커널은 라우터를 사용해 웹 요청을 다루고, 콘솔 커널은 나머지 크론과 아티즌 같은 명령줄 요청을 다룬다.

HTTP커널 위주로 살펴보면, 요청을 실행하기 전에 처리되는 bootstrappers (시작코드[3])의 배열을 정의하고 있다. 또한 애플리케이션에서 요청이 처리되기 전에 통과해야하는 HTTP 미들웨어[4]의 목록을 정의하고 있다.

각 커널은 handle() 메서드를 가지는데 이는 요청(Request) 객체를 받고, 응답(Response) 객체를 반환한다.

[3] 에러 처리, 로그 설정, 애플리케이션 동작 환경의 감지 등 실제 요청이 처리되기 전에 수행해야 되는 작업들을 의미

[4] HTTP 세션을 읽고/쓰고, 애플리케이션이 유지 관리 모드인지 확인하고, CSRF 토큰을 확인하는 작업들을 처리

---

 

3. 서비스 프로바이더

커널 부팅(부트스트래핑) 과정의 가장 중요한 것 중의 하나는 애플리케이션의 서비스 프로바이더를 로딩하는 것이다. 애플리케이션의 모든 서비스 프로바이더는 config/app.php 파일의 providers 배열에 설정되어 있다. 먼저, 모든 서비스 프로바이더의 register 메소드가 호출되고, 이후에 등록 된 모든 서비스 프로바이더의 boot 메소드가 호출되어 진다.

서비스 프로바이더는 애플리케이션의 핵심 기능(=컴포넌트)을 부트스트랩하는데 필요한 로직을 캡슐화한 클래스다. 프레임워크가 제공하는 모든 기능을 초기화 하고 설정하는 것으로, 서비스 프로바이더는 라라벨의 부팅 과정에서 가장 중요한 기능이라고 할 수 있다.

예를 들어 AuthServiceProvider는 라라벨 인증 시스템에 필요한 부트스트래핑 작업을 처리하고, RouteServiceProvider는 라우팅 시스템이 필요한 부트스트래핑 작업을 담당한다. 또, 우리가 작성하는 기능이 컨테이너에 등록된 어떤 클래스를 필요로 하는 걸 알게 되면 해당 기능만을 위한 서비스 프로바이더(=GihubServiceProvider 등)를 만들게 된다.

기본 서비스 프로바이더는 app/Providers 디렉토리에 있으며, 기본적으로 AppServiceProvider는 거의 비어있다. 이 프로바이더는 고유의 부트스트래핑과 서비스 컨테이너 바인딩 코드를 추가하기 위한 곳이다. 보다 큰 애플리케이션의 경우 보다 세부적인 유형으로 구분된 종류별 서비스 프로바이더를 만들 수도 있다.

 

4. 요청 처리-디스패칭

애플리케이션이 부팅(부트스트래핑) 되고 모든 서비스 프로바이더가 등록된 후, Request는 라우터 처리를 위해서 전달될 것이다. 라우터는 라우팅 또는 컨트롤러로 요청(request)를 전달할 뿐만 아니라, 임의의 특정 라우트에 지정된 미들웨어도 실행한다.

 

 

애플리케이션의 인스턴스가 생성되고,
서비스 프로바이더가 등록된 후,
부트스트래핑 과정을 마친 프로그램이 요청을 처리한다!

 

 

---

참고 

1.  https://laravel.kr/docs/5.8/lifecycle

2.  https://dev.to/patelparixit07/laravel-request-lifecycle-195e

3.  https://stackhoarder.com/2019/08/04/laravel-%EA%B8%B0%EC%B4%88-3-request-lifecycle/

4.  책 : 처음부터 제대로 배우는 라라벨