마이크로프레임워크는 들어오는 요청을 알아서 프로그램에 전달해주고, 처리가 완료되면 다시 자동으로 응답을 반환하는 접착제 코드(glue code)와 같다. 마이크로프레임워크는 프로젝트에 특정 패러다임을 적용할 것을 강요하지 않는다.
장고와 같은 battery-included 프레임워크는 데이터베이스 쿼리 결과와 객체를 연결하는 ORM을 비롯해 웹 애플리케이션을 개발하는 데 필요한 모든 것을 제공한다. 프레임워크는 ORM과 단단히 결합돼 있다.
장고의 목적이 하나의 완전한 시스템을 제공해서 개발자가 기능 구현에만 집중하게 하는 것이기 때문이다.
반면에 플라스트는 어떤 라이브러리를 사용해서 데이터를 다루는지 신경 쓰지 않는다. 프레임워크는 외부 라이브러리를 활용해 확장되며, 이런 방식으로 다양한 기능을 제공한다. 예를 들어 플라스크에서 SQLAlchemy를 사용하고 SQL 세션과 트랜젝션으로 필요한 작업을 수행하려면 프로젝트에 Flask-SQLAlchemy 같은 패키지를 추가하면 된다. 특정 라이브러리가 SQLAlchemy와 제대로 동작하지 않는다면 얼마든지 다른 것을 사용할 수 있다.
플라스트에서 요청 처리
프레임워크의 진입점은 flask.app 모듈의 Flask 클래스다. 플라스크 애플리케이션을 실행한다는 것 Flask 클래스의 단일 인스턴스를 띄워 외부에서 들어오는 WSGI 요청을 다루고, 이를 적절한 코드로 전달해서 처리한 후에 응답을 반환하는 것이다.
WSGI는 웹 서버와 파이썬 애플리케이션 사이의 인터페이스를 정의한 규약이다. 서버로 들어오는 요청은 고유하게 매핑되며, 플라스크 같은 해당 요청을 처리할 코드로 정확하게 라우팅한다.
Flask 클래스는 함수를 데코레이트하는 route 함수를 제공한다. route로 함수를 데코레이트하면 view가 되고 Werkzeug의 라우팅 시스템에 등록된다. 시스템은 들어오는 요청과 뷰를 연결해주는 규칙을 갖고 있다.
많은 웹 프레임워크가 명시적으로 request 객체를 코드로 전달하는 데 반해, 클라스트는 암시적으로 전역 request 변수를 사용한다. 전역 request 변수는 내부적으로 HTTP 요청을 WSGI 환경 변수 딕셔너리로 파싱해서 만든 Request 객체를 가리키고 있다.
흔히 전역 변수는 프로그램 전체에서 공유되지만, 플라스크의 request 전역 변수는 고유한 객체이며, 스레드에 안전하다. 여기에는 context local이라는 메커니즘이 사용된다.
플라스트 요청/응답 과정
라우팅: 플라스크가 Map 클래스를 생성
요청: 플라스크가 Request 객체를 뷰에 전달
응답: Response 객체에 필요한 내용을 채워서 응답을 보냄
라우팅
라우팅은 Werkzeug Map 클래스의 인스턴스인 app.url_map에서 일어남. 이 클래스는 정규 표현식을 사용해 클라이언트에서 호출한 엔드포인트와 일치하는 @app.route로 데코레이트된 함수를 찾음.
기본적으로 라우팅은 HTTP 메소드 중 HEAD, GET, OPTIONS만 받아 들임. 올바른 엔드포인트라도 지원하지 않는 HTTP 메소드를 사용했다면 405 Method Not Allowed가 반환됨.
다른 HTTP 메소드도 라우팅하고 싶다면 route 데코레이터에 전달되는 methods 인수에 필요한 HTTP 메소드를 추가하면 된다.
OPTIONS와 HEAD 메소드는 요청 핸들러가 자동으로 관리하므로, 모든 규칙에 암시적으로 추가된다. 이 동작을 비활성화하려면 provide_automatic_options 속성을 False로 설정한다. 여러 개의 Access-Control-Allow-* 헤더를 추가해야 하는 CORS를 다룰 때처럼 OPTIONS 헤더가 호출될 때 사용자 정의 헤더를 응답에 추가하고 싶다면 이 방법이 유용하다.
변수와 컨버터
라우팅 시스템이 제공하는 또 다른 기능은 변수다
<변수_이름>구문을 이용해서 변수를 사용할 수 있다.
플라스크가 데코레이트 함수를 호출할 때 URL에서 <변수_이름> 위치의 값을 변수_이름 인수로 변환해 준다