크게 만들기

코드가 증가하고 어플리케이션의 규모가 커질 때 여러분에게 몇가지 선택사항이 있다.

소스코드를 읽어라.

플라스크는 이미 존재하고 잘 사용되는 도구인 벡자이크(WSGI)와 진자(템플릿 엔진) 의 상위에서 여러분 자신의 프레임워크를 만들기 위한 방법을 설명하기 위해 부분적으로 시작되었고, 개발되어오면서, 넓은 사용자층에게 유용해졌다. 여러분의 코드가 점점 커진다면, 플라스크를 사용하지 않아야 한다 – 그 이유를 이해해라. 소스를 읽어라. 플라스크의 소스는 읽혀지기 위해 쓰여진것이다; 그것은 공표된 문서이기에 여러분은 그것의 내부 API를 사용할 수 있다. 플라스크는 여러분의 프로젝트에 필요한 훅 포인트 (hook point)를 찾을 수 있도록 상위 라이브러리에 있는 문서화된 API를 고수하고 그것의 내부 유틸리티를 문서화한다.

훅(Hook)하고. 확장하라.

API 문서는 사용가능한 오버라이드, 훅 포인트, 시그널(Signals) 로 가득 차 있다. 여러분은 요청과 응답 객체와 같은 것에 대한 커스텀 클래스를 제공할 수 있다. 여러분이 사용하는 API에 대해 좀 더 깊게 파보고, 플라스크 릴리즈에 특별하게 사용가능한 커스터마이징된 것을 찾아봐라. 여러분의 프로젝트가 여러 유틸리티나 플라스크 확장으로 리팩토링될 수 있는 방식을 찾아봐라. 커뮤니티에 있는 여러 확장 을 살펴보고 , 여러분이 필요한 도구를 찾을 수 없다면 여러분 자신의 확장을 만들기 위한 패턴을 찾아봐라.

서브클래싱하라.

Flask 클래스는 서브클래싱에 대해 설계된 여러 메소드가 있다. 여러분은 Flask (연결된 메소드 문서를 살펴봐라) 를 서브클래싱하고 어플리케이션 클래스를 인스턴스화한 곳 어디서나 그 서브클래스를 사용하여 동작을 빠르게 추가하거나 커스터마이징할 수 있다. 이것은 어플리케이션 팩토리 과 함께 잘 동작한다.

미들웨어로 감싸라.

어플리케이션 디스패칭 장에서 미들웨어를 적용하는 방법에 대해 자세히 보여줬다. 여러분의 플라스크 인스턴스를 감싸기 위해 WSGI 미들웨어와 여러분의 어플리케이션 과 HTTP 서버 사이에 있는 계층에 수정과 변경을 소개할 수 있다. 벡자이크는 다수의 미들웨어 를 포함하고 있다.

분기하라.

위에서 언급한 선택사항 중 어느 것에도 해당되지 않는다면, 플라스크를 분기해라. 플라스크 코드의 다수는 벡자이크와 진자2 안에 있는 것이다. 이런 라이브러리가 그 동작의 대다수를 수행한다. 플라스크는 단지 그런 라이브러리를 잘 붙여논 풀같은 것이다. 모든 프로젝트에 대해 하부 프레임워크가 방해가 되는 점이 있다 (왜냐하면 원 개발자들의 가진 가정들 때문에). 이것은 자연스러운 것인데 왜냐하면 그런 경우가 아니라면, 그 프레임워크는 시작부터 굉장히 가파른 학습 곡선과 많은 개발자의 좌절감을 유발하는 매우 복잡한 시스템이 될것이기 때문이다.

이것은 플라스크에만 유일하게 적용되지 않는다. 많은 사람들이 그들이 사용하는 프레임워크의 단점에 대응하기 위해 패치되고 변경된 버전의 프레임워크를 사용한다. 이 방식 또한 플라스크의 라이선스에 반영돼있다. 여러분이 플라스크에 변경하기로 결정했더라도 그 어떤 변경에 대해서도 다시 기여하지 않아도 된다.

물론 분기하는 것에 단점은 플라스크 확장에 대부분 깨질것이라는 점인데 왜냐하면 새로운 프레임워크는 다른 임포트 명을 가질 것이기 때문이다. 더 나아가서 변경의 개수의 따라 상위 변경을 통합하는 것이 복합한 과정일 수 있다. 그런것 때문에 분기하는 것은 최후의 보루가 되어야 할 것이다.

프로페셔널처럼 규모를 조절하라.

많은 웹 어플리케이션에 대한 코드의 복잡도는 예상되는 사용자 수와 데이터 항목에 대한 규모를 조절하는것에 비하면 큰 이슈는 아니다. 플라스크 그 자체로는 여러분의 어플리케이션 코드, 사용하고자 하는 데이타 저장소 그리고 실행되는 파이썬 구현과 웹서버에 의한 규모 조절이라는 측면에서만 제한된다.

예를 자면 규모를 잘 조절한다는 것은 만약 여러분이 서버의 양을 두배로 했을 때 두배의 성능을 얻는다는 것을 의미한다. 규모 조절이 잘못됐다는 것은 여러분이 새로운 서버를 추가했을 때 어플리케이션이 더 좋은 성능을 내지 못하거나 심지어 대체되는 서버로 지원하지도 못하는 것을 의미한다.

문맥 로컬 프록시가 플라스크에서 규모 조절과 관련된 유일한 제한 요소이다. 그것들은 플라스크에 있는 쓰레드, 프로세스 혹은 그린렛으로 정의되는 문맥에 의존한다. 여러분의 서버가 쓰레드나 그린렛에 기반하지 않은 어떤 동시성의 기능을 사용한다면, 플라스크는 이와 같은 전역적인 프록시를 더 이상 제공할 수 없을 것이다. 하지만 서버의 다수는 기반에서 벡자이크 라이브러리에 의해 잘 지원되는 모든 메소드인 동시성을 수행하기 위해 쓰레드, 그린렛 또는 분리된 프로세스를 사용할 것이다.

커뮤니티와 논의해라.

플라스크 개발자들은 사용자들에게 크고 작은 코드를 가지고 그 프레임워크에 접근할 수 있도록 유지한다. 여러분의 방식에서 플라스크로 인한 어떤 걸림돌을 만난다면 메일링 리스트나 IRC 채널을 통해 플라스크 개발자들에게 연락하는 것에 망설이지 말도록 해라. 더 큰 어플리케이션에 대한 도구를 개선하기 위해 플라스크와 그 확장 을 개발하는 개발자들에게 가장 좋은 방법은 사용자들에게 피드백을 얻는 것이다.